Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1997-08-21
2001-06-12
Banankhah, Majid (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
Reexamination Certificate
active
06247068
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates to a hardware accelerator that accomplishes Winsock protocol acceleration. More particularly, the invention relates to hardware that provides scalable acceleration for processes that call the Winsock data link library (DLL), in which the hardware is detected by the operating system and application program interfaces are routed to hardware acceleration.
2. Background of the Invention
Computer systems require protocol software to communicate with other computers or devices. The protocol software sends information in a particular format, and also receives data in a particular format. Protocols that are commonly used in conventional computer systems include TCP/IP and APPLETALK, as well as many others. The protocol software is typically part of the operating system of the computer.
Operating systems in most computers support multiprogramming, in which multiple application programs are executed simultaneously. Typically, these application programs are run in a time division multiple access structure, in which each application program obtains the entire computer resources for its particular time frame. When executed, an application program runs a particular application, such as “time of day.”
An important feature of computer systems is the interface between protocol software and the application programs resident in the computer. Currently, there do not exist standards specifying how application programs interact with protocol software. Since protocol software resides in the operating system of the computer, the interface with application programs depends on the operating system being used (i.e., DOS, OS/2, Windows).
A Winsock interface has been developed, which provides socket functionality for Microsoft Windows. The Winsock interface permits application programs that make socket calls to run Microsoft Windows.
Another important aspect of computer systems is the client-server function. The term “server” applies to any program that offers a service that can be reached over a network. The server accepts the request, typically via a socket assigned to the server. The server then services the request, and transmits the results back to the client. The server then awaits another request.
The term “client” refers to the device that made the request. For example, an executing application program becomes a client when it sends a request to a server and awaits the response. An example of a server is a file server, which receives requests to perform operations that store or retrieve data from a file. The file server performs the requested store/retrieve function, sends the data to the requesting party (the client), and waits for the next request.
A conventional interface between TCP/IP protocol software and application programs running on a UNIX operating system is presented herein. In the UNIX operating system, an application program interacts with the operating system by making system calls. System calls look like other procedure calls from a programmer's perspective, in that they take arguments and return one or more results. Arguments can be binary values or pointers to objects in the application program.
The UNIX input/output (I/O) system uses the “open-read-write-close” paradigm. In this paradigm, a user process calls “open” to specify the file or device to be used and obtains permission to use the file or device. The call to “open” returns a file descriptor, which is an integer value that the process uses when performing I/O operations on the opened file or device.
Once the object is opened, the user process makes one or more calls to “read” or “write” to transfer data to/from the file or device. “Read” transfers data to the user process from the file or device, and “write” transfers data to the file or device from the user process. After all I/O operations are completed, the user process calls “close” to notify the operating system that it has finished using the object.
For input/output operations through a network of devices, the UNIX system utilizes the concept of a “socket.” The socket can either be part of the operating system or it can be a library routine that provides a socket interface. The term “socket” provides an endpoint for communication to another device. As with file access, an application program makes a request to the operating system for a socket, and the operating system creates a socket for use by the requesting application program. The operating system returns an integer value that the application program uses to reference the newly created socket.
The main difference between file descriptors and socket descriptors is that the operating system binds a file descriptor to a specific file or device when the application program calls “open”, but the operating system can create a socket without binding the socket to a specific destination address. That way, the application program can either supply a destination address each time it uses the socket (i.e., each time it sends a packet of data), or it can bind the destination address to the socket to avoid repeatedly having to specify the destination for data transfers over the same socket.
Like file and device I/O data transfers, data transfers over a socket use operations like read and write. When an application program creates a socket and creates a TCP connection from the socket to a foreign destination, the application program can use “write” to send data across the connection, and the application program at the other end can use “read” to receive the data. In order to allows primitives like “read” and “write” to be used for files, devices and sockets, the operating system allocates socket descriptors and file descriptors from the same set of integer values, so that a particular integer value is either a socket descriptor or a file descriptor, but not both.
In the UNIX operating system, an application program can request a socket on demand. Based on this socket request, the operating system returns a result which includes a first argument specifying the protocol family to be used for the newly created socket (e.g., TCP/IP, PUP internet, APPLETALK), a second argument specifying the type of communications desired (e.g., reliable stream delivery service, connectionless datagram delivery service), and a third argument specifying the specific protocol within the protocol family that is to be used.
At any particular time when the computer is running, there may be various sockets that are open and being used by application programs that are currently being executed. In order to start a new application program, a separate copy of the currently executing application program (or programs) is created, and the new copy replaces itself with the desired application program. The newly created copy then has access to all open sockets as well as all open files. The operating system keeps a reference count associated with each socket, so that it knows how many application programs have access to each socket.
Since both old and new processes have the same access rights to existing sockets, the programmer must ensure that the two processes use the shared sockets without affecting each other. When a process finishes using a socket, it calls “close”, and the socket is then no longer usable. When a process terminates for any reason, the operating system closes all sockets accessible by that process.
Initially, a socket is created without it being associated with a local address or a destination address. For TCP/IP protocols, this means that a local protocol port number has not been assigned and a destination port or IP address has not been specified. In many cases, an application program does not care about the local address that it uses, and it is willing to allow the protocol software to choose an address for it. However, a server process that operates on a specified port must be able to specify that port, since that is the only way clients know where to access the server. Once a socket has been created, the server uses the “bind” system call in UNIX to esta
Advanced Micro Devices , Inc.
Banankhah Majid
Foley & Lardner
Lao Sue
LandOfFree
Winsock-data link library transcoder does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Winsock-data link library transcoder, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Winsock-data link library transcoder will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2453755