Electrical computers and digital processing systems: multicomput – Computer-to-computer session/connection establishing
Reexamination Certificate
1998-08-24
2002-12-03
Rinehart, Mark H. (Department: 2152)
Electrical computers and digital processing systems: multicomput
Computer-to-computer session/connection establishing
C709S222000, C709S231000, C709S238000, C709S250000, C709S241000
Reexamination Certificate
active
06490623
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to computer communications, and deals more particularly with a technique, system, and computer program for providing a lightweight, system-independent and language-independent communications object model for use with TCP/IP communications. This model encapsulates low-level socket functions, and provides support for both synchronous and asynchronous input/output.
2. Description of the Related Art
The TCP/IP protocol (Transmission Control Protocol/Internet Protocol) is the de facto standard method of transmitting data over networks, and is widely used in Internet transmissions. TCP/IP uses the concept of a connection between two “sockets” for exchanging data between two computers, where a socket is comprised of an address identifying one of the computers, and a port number that identifies a particular service, or process, on that computer. The process identified by the port number is the process that will receive the incoming data for that socket. A socket is typically implemented as a queue by each of the two computers using the connection, whereby the computer sending data on the connection queues the data it creates for transmission, and the computer receiving data on the connection queues arriving data prior to processing that data.
TCP/IP is typically used in a client-server model of computing, where the machine at which the user requests information is referred to as the client, and the computer that locates the information and returns it to the client is the server. In the World Wide Web environment, the server is commonly referred to as a “Web server”. The client-server model may be extended to what is referred to as a “three-tier architecture”. This architecture places the Web server in the middle tier, where the added tier typically represents databases of information that may be accessed by the Web server as part of the task of processing the client's request. This three-tiered architecture recognizes the fact that many client requests are not simply for the location and return of static data, but require an application program to perform processing of the client's request in order to dynamically create the data to be returned. In this architecture, the Web server may equivalently be referred to as an “application server”.
In order to exchange data across a network or Internet, a computer may act as a client, a server, or both, depending on the application running on the computer. Some communication functions are used only for the client role, other functions are used only for the server role, and yet others are used in both roles.
Establishing and maintaining end-to-end communications through one or more networks is an extremely complicated process. To insulate a programmer writing application software that will run in this environment from the underlying communication details, a number of vendors have developed prepackaged communications software with an interface that is accessible to an application program. These packages may alternatively be referred to as “libraries”. An example is Windows Sockets, or “Winsock”, from Microsoft Corporation. Winsock contains functionality to implement socket-based communications using TCP/IP on a computer running a Windows operating system. These communications functions are made available to the programmer through an Application Programming Interface (“API”). The programmer then invokes selected functionality from this package by coding a reference to the corresponding API in his application program. For a computer running the UNIX operating system, the Berkeley Software Distribution (“BSD”) sockets programming interface is commonly used. In the object-oriented environment, a communications package referred to as “java.net” has been produced by Sun Microsystems for use with the Java programming language. (“Java” is a trademark of Sun Microsystems, Inc.) “java.net” is a class of communications methods for use with sockets-based connections.
These packages of communications functionality have been developed for specific operating systems, and for use with specific programming languages. “java.net”, for example, is only usable from application programs written in the Java language. The commands (that is, the syntax with which a programmer requests communication functionality) in the Winsock API differ from the commands available in the BSD API. This difference is due (at least in part) to tailoring the implementations to run on particular operating systems. For example, while the BSD API includes a “close” command, the corresponding Winsock API command is “closesocket”. Further, the differences between the BSD and Winsock API support for asynchronous input/output (“I/O”) function significantly impacts the design of applications utilizing this function, such that a restructuring of the application is required in order to port from one operating system to another. Java itself does not provide support for asynchronous I/O. With the proliferation of low-end handheld and embedded devices, the cost of porting application designs to varied devices becomes more and more expensive.
In addition, the data structures used in the various libraries are not consistent, so that an application program compiled for one library cannot be executed on a machine where the underlying function is supplied by a different library implementation. The particular programming model around which an operating system is designed is also a factor in differing implementations within libraries. For example, in addition to the differences in asynchronous I/O discussed above, some versions of the Windows operating system use non-preemptive scheduling, while other operating systems use preemptive scheduling. The details of this distinction are beyond the scope of this discussion, but the significance of the distinction is that server functionality ( for example, the “blocking receive” function) must be implemented differently to properly accommodate each approach. Furthermore, some libraries provide rich functionality, while others are limited to basic requirements.
Further, an “all-or-nothing” approach to using a specific library is required. As devices capable of communicating over networks become smaller and smaller, the need for efficient and compact communications software becomes increasingly important. Handheld computers and other embedded devices, such as the PalmPilot, have limited memory and storage capacity, and may use specialized or device-specific operating systems for which no library of communications functionality is readily available. Such computers need access to a library providing basic communications functionality, without the overhead associated with advanced communications. (“PalmPilot” is a trademark of 3Com Corporation.)
For an application programmer, these operating system and programming language dependencies and differences mean that either one version of his application will be created, for a particular operating system or language (restricting the market for his software), or that he must implement different executable versions of the application for each operating system and programming language environment (with a corresponding increase in the cost and effort required for development and support).
Accordingly, a need exists for a technique by which these disadvantages in the current implementations of socket functionality can be overcome. The proposed technique defines a lightweight uniform communications model to encapsulate this functionality. The model is system and language-independent, and supports both synchronous and asynchronous I/O. The functionality included in this model is based on the common denominator of functions provided in modem operating systems, which provide the capability for basic sockets support as well as support for threads.
SUMMARY OF THE INVENTION
An object of the present invention is to provide a technique for encapsulating low-level socket functionality.
Another object of the present invention is to provide a techni
Doubet Marcia L.
Kang Paul
Ray-Yarletts Jeanine S.
Rinehart Mark H.
LandOfFree
System, method and computer readable code for encapsulating... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System, method and computer readable code for encapsulating..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System, method and computer readable code for encapsulating... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2966006