Browse Prior Art Database

Socket Access on Native Internal Packet Exchange/Sequenced Packet Exchange Protocols

IP.com Disclosure Number: IPCOM000114914D
Original Publication Date: 1995-Feb-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 2 page(s) / 97K

Publishing Venue

IBM

Related People

Crane, MA: AUTHOR [+3]

Abstract

This disclosure describes a method for accessing the native Netware* Internetwork Packet Exchange* (IPX)/Sequenced Packet Exchange* (SPX) protocols using the Berkley SOCKETS Application Programming Interface (API) thereby utilizing the rich knowledge base associated with the sockets to be used over the IPX/SPX protocols. Presently, communication with the native IPX/SPX protocols is carried out using the Netware APIs for IPX and SPX in addition to the Netware TLI APIs. In these native APIs, flow control problems are dealt with by the applications and are clearly transport specific APIs. The use of socket API all alleviates these problems, facilitates transport independence and transport level control flow.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Socket Access on Native Internal Packet Exchange/Sequenced Packet
Exchange Protocols

      This disclosure describes a method for accessing the native
Netware* Internetwork Packet Exchange* (IPX)/Sequenced Packet
Exchange* (SPX) protocols using the Berkley SOCKETS Application
Programming Interface (API) thereby utilizing the rich knowledge base
associated with the sockets to be used over the IPX/SPX protocols.
Presently, communication with the native IPX/SPX protocols is carried
out using the Netware APIs for IPX and SPX in addition to the Netware
TLI APIs.  In these native APIs, flow control problems are dealt with
by the applications and are clearly transport specific APIs.  The use
of socket API all alleviates these problems, facilitates transport
independence and transport level control flow.

      Sockets creates a transport endpoint for a given address family
such as either AF_INET to access the internet protocols, e.g., TCP,
UDP and AF_NetBIOS to access the NetBIOS protocol.  We define a new
address family viz AF_NETWARE with which a socket user can create a
transport endpoint that utilizes the Netware IPX and SPX protocols
via the socket API.  The socket abstraction layer will select the
appropriate protocol based on the address family of the endpoint, for
either connection-oriented communications using the SPX protocol or
connectionless communications using the IPX protocol.

      The transport level flow control is effected by setting aside
and upper limit for the send and receive paths for the endpoint.
This information is maintained in the control block for the endpoint
and the sender is not allowed to send more than the "send window"
specified by the upper limit.  When data is received by the intended
recipient, the sender's "window" is opened, thus enabling the sender
to continue sending, if any.  The user of the native Netware IPX/SPX
APIs has no such control and a native user can flood the network with
any amount of data.  This could cause network congestion and
undesirable resource consumption at the endpoint.

      The socket API serves as a transport independent API and is
independent of various communications platforms.  As a result, an
application written using socket API for AF_NETWARE is easily
portable to function on other protocol domains such as AF_INET.
Also, there is a clear-cut distinction of user addresses from the
resource names which are often used interchangeably while using the
native Netware API.

      Socket API access on the n...