Electrical computers and digital processing systems: multicomput – Computer-to-computer protocol implementing
Reexamination Certificate
1993-06-30
2001-06-19
Geckil, Mehmet B. (Department: 2152)
Electrical computers and digital processing systems: multicomput
Computer-to-computer protocol implementing
C709S229000
Reexamination Certificate
active
06249818
ABSTRACT:
BACKGROUND OF THE INVENTION
This invention relates to network transport driver interfacing.
Referring to
FIG. 1
, in a typical computer network
10
, a network communication medium (e.g., cabling)
12
carries information among computers attached to the medium, e.g., computers
14
a,
14
b,
and
14
c.
The physical connection of each computer to the medium is made via a network interface card
16
which plugs into the motherboard of the computer. The computer includes the usual monitor, keyboard, mouse, CPU, memory, and disk storage (not shown) as well as software
18
.
The software includes an operating system
20
(e.g., DOS, UNIX, DOS/Windows, or VMS, which manages the basic operation of the computer), portions
22
of a distributed network operating system, and at least one application
24
.
Portions
22
of the distributed network operating system (e.g., Netware, LAN Manager, Pathworks, or Vines) cooperate with other portions of the network operating system located in other computers on the network to provide network services which enable the computers to cooperate with one another via the network medium. In addition to providing basic network communication services for applications, the network operating system may provide additional services such as implementation of remote procedure calls (RPCs) and network management functions.
An application
24
(e.g., a user application or a protocol engine such as KERMIT) communicates with the network operating system via an application interface
26
. Data link software
28
controls, and communicates on the network via, the network interface card. A transport stack/driver
30
sits between the application interface and the data link.
The delivery of information on the network medium must comply with defined protocols which typically have several levels. Each transport stack/driver is typically designed to comply with a particular protocol, for example, TCP/IP, Serial Comm, CTERM, TELnet, or DECnet.
A variety of approaches have been taken in implementing application interfaces as part of network operating systems. They include socket interfaces, XTI, BSD Socket, TLI, and Microsoft's Transport Driver Interface (TDI), which is used for kernel level applications, for example for a redirector.
In the socket interface approach (e.g., Berkeley Sockets described in 4.3 BSD, available from the Regents of the University of California) when an application needs to read from or write to a remote node on the network, it opens a socket. The socket is like a virtual circuit between the local and remote computers (also called nodes). A socket is given a unique identifying number and may be closed when no longer needed. Once the socket is opened, the local node may perform read and write operations via the socket using the unique identifying number. When a read or write operation is initiated, the local node generally cannot proceed with its own further operations until it receives a confirmation that the read or write operation has been executed at the remote node. Thus the reads and writes (or other calls) are said to be performed synchronously and in a locally polled manner.
For an application to be able to make use of a transport stack/driver for a particular network protocol, the application (or an associated application interface) must be designed to communicate properly with the transport stack/driver. Thus, for example, an application that is designed to implement a KERMIT communication protocol may be written to interface correctly with a TCP/IP transport stack/driver offered by a particular vendor. The application (or the associated application interface) would have to be modified or rewritten if it were to be used with a different, say, DECnet transport stack/driver. A similar need for modification or rewriting would arise if the transport stack/driver were to be used with other than the operating system for which it was designed.
Another socket interface, WinSock, contemplates porting from UNIX to a Windows platform and between Windows environments; it supports a TCP/IP transport stack/driver. WinSock Version 1.0 provides for use of the Windows API in conjunction with the Internet Protocol Suite (IPS, also called TCP/IP). WinSock permits loading of vectors (jump addresses) of TCP/IP stacks of different vendors.
SUMMARY OF THE INVENTION
The invention enables applications to link to multiple transport stack/drivers by attaching and detaching vectors of the transport stack/drivers (jump addresses, i.e., entry points to the functions provided) dynamically. Multiple transport stack/drivers may be added to a system without requiring any change in the calling conventions at the application level. Thus transport stack/drivers can easily be added or removed from a system. The invention provides for notify callbacks from the transport stack/driver which allows asynchronous operation without requiring the application to wait for the transport stack/driver to confirm a network transport operation. The invention can be implemented on a variety of operating system platforms and provides uniform transport services across all of them. Network management functions are made easier.
Thus, in general, in one aspect, the invention features a computer-based method for permitting application programs running on a computer to obtain transport services from a set of transport service providers (e.g., transport stack/drivers) also running on the computer, thus enabling the application programs to communicate on a network to which the computer is coupled. Each transport service provider is configured to respond to transport service requests which conform to a prespecified format associated with the transport service provider. Original service requests are received from an application program. For each received original service request, a corresponding transport service request conforming to the appropriate prespecified format is delivered to the selected one of the transport service providers.
In embodiments of the invention an application program can dynamically cause inclusion of new transport service providers in the set of transport service providers running on the computer, e.g., by having the application register vectors representing jump addresses of the function entry points to said transport service provider.
Each original service request complies with a common data structure which applies to application programs and to transport service providers. The original service requests are directed to the transport service providers by storing data in a global memory and triggering global memory accesses by the transport service providers.
In some embodiments, each of the transport service providers has a native prespecified format and each original service request is directed to an appropriate mapper for mapping the request to a transport service request in an appropriate prespecified format.
In some embodiments, all of the transport service providers are adapted to accept transport service requests in a prespecified format which is the same as a common format to which the original service requests conform.
In general, in another aspect, the invention features a computer-based method for providing transport services to an application program running on a computer. In the method, an original service request is received from the application program; a corresponding transport service request is delivered to a transport service provider running on the computer; a call back is delivered to the application program to indicate completion of the requested service; and in the period after the receipt of the original service request and prior to the delivery of the call back, the application program is free to engage in activities other than waiting for completion of the requested service.
Other advantages and features of the invention will become apparent from the following description and from the claims.
REFERENCES:
patent: 4614841 (1986-09-01), Babecki et al.
patent: 5224098 (1993-06-01), Bird et al.
patent: 5261051 (1993-11-01), Masden et al.
patent: 52
Cesari and McKenna LLP
Compaq Computer Corporation
Geckil Mehmet B.
Johnston A. Sidney
LandOfFree
Network transport driver interfacing does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Network transport driver interfacing, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Network transport driver interfacing will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2456167