Abstract:
A method, computer program product, and data processing system for performing efficient communication between software entities residing in the same operating system using conventional network communications APIs are disclosed. According to a preferred embodiment, when a software entity (e.g., a process) attempts to communicate through a networking API, the operating system determines whether the other end of the communication refers to the same hardware node. If so, the operating system replaces the network protocol connection (socket connection) with a direct interprocess communication construct. The operating system provides additional code to simulate the appearance of an actual network (socket) connection at the API level while performing all actual I/O using the interprocess communication construct.

Description:
BACKGROUND OF THE INVENTION 
       [0001]    1. Technical Field 
         [0002]    The present invention relates generally to networked computer programming, and specifically to the improvement of execution performance of network applications communicating with each other in a single operating system. 
         [0003]    2. Description of the Related Art 
         [0004]    Modern telecommunications depends on networks. A network is a set of interconnected machines (network elements) that allow data to be relayed across the set of machines from a source to a destination. Networks may be classified according to the geographic area they occupy. A local area network (LAN) is usually defined as a network that is physically limited to a relatively small area, such as a building or group of buildings. A wide area network (WAN) is a general term for a network of larger size. 
         [0005]    Networking protocols, which define the rules for communication between network elements, are typically designed to work in layers, where each layer performs a slightly different role in data transmission. TCP/IP (Transmission Control Protocol/Internet Protocol) is a collection of protocols (called a protocol suite) that forms the basis for the Internet and many other networks. TCP/IP is generally considered to follow a four-layer protocol model. 
         [0006]    An application programmer needing to write networking-enabled software typically uses an application programming interface (API) that allows the programmer to program network communications in an abstract way without explicitly addressing the specifics of each protocol layer. Perhaps the most widely utilized of such APIs is the “sockets” API commonly provided in UNIX/POSIX-based operating systems; similar “sockets” and “sockets”-like APIs are provided in other operating systems and programming environments, such as the JAVA programming environment, for example. The “sockets” approach to network communication is to model a connection between two network entities as a stream or abstract file, which is called a “socket.” In the usual POSIX “sockets” library for use in programming in the C programming language, opening a socket generates a “socket descriptor” number, which is analogous to a file descriptor. Subsequent input/output (I/O) from/to the socket is performed by passing the “socket descriptor” to I/O routines, just as in the case of a file descriptor. 
         [0007]    Although it is arguable that the ultimate aim of network programming is to allow various computers in a network to communicate with one another, it often occurs that two communicating network applications will actually reside on the same computer and same operating system instance. For example, an application server process may communicate with a database server process on the same operating system instance. In such cases, a modern operating system will generally avoid using the computer&#39;s networking hardware to enable the communication, but will still process the communication through the usual protocol layers (e.g., the layers of the TCP/IP protocol suite). The usefulness of the processing performed by these layers, however, is of less value for communication between software entities on the same system. For instance, encryption of data being transmitted between two processes on the same system is superfluous. 
         [0008]    In existing technology, however, there is no way to bypass this additional network processing without including additional (non-standard) code in each application to enable this type of bypass when applicable. Moreover, this type of bypass cannot be used in a partitioned system, i.e., a system that is divided into two or more software partitions. Software partitions are virtual operating system instances residing on the same physical system and sharing the same operating system (kernel) code. A software partition cannot see certain aspects the global environment and other software partitions (including network-related information), except as they would be visible from a physically separate system. Thus, in the event that communicating applications resided in separate software partitions on one global system, the applications would not be capable of determining that they existed on the same system and would therefore not be able to bypass the full network protocol processing using the technique described above. 
         [0009]    What is needed, therefore, is a method of bypassing full protocol stack processing for communications between two processes residing on the same system, even in the event that the two processes reside in different software partitions or under other circumstances that prevent the applications themselves from determining whether they reside on the same system. The present invention provides a solution to this and other problems, and offers other advantages over previous solutions. 
       SUMMARY OF THE INVENTION 
       [0010]    Accordingly, the present invention provides a method, computer program product, and data processing system for performing efficient communication between software entities residing in the same operating system using conventional network communications APIs. According to a preferred embodiment, when a software entity (e.g., a process) attempts to communicate through a networking API, the operating system determines whether the other end of the communication refers to the same hardware node. If so, the operating system replaces the network protocol connection (socket connection) with a direct interprocess communication construct. The operating system provides additional code to simulate the appearance of an actual network (socket) connection at the API level while performing all actual I/O using the interprocess communication construct. 
         [0011]    The foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0012]    The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings, wherein: 
           [0013]      FIG. 1  is a flowchart representation of a process of opening a network connection in an operating system in accordance with a preferred embodiment of the present invention; 
           [0014]      FIG. 2  is a diagram of a socket descriptor/IPC construct descriptor mapping table in accordance with a preferred embodiment of the present invention; 
           [0015]      FIG. 3  is a diagram of a process of reading from, writing to, querying, or destroying a network connection in accordance with a preferred embodiment of the present invention; and 
           [0016]      FIG. 4  is a block diagram of a data processing system in which a preferred embodiment of the present invention may be implemented. 
       
    
    
     DETAILED DESCRIPTION 
       [0017]    The following is intended to provide a detailed description of an example of the invention and should not be taken to be limiting of the invention itself. Rather, any number of variations may fall within the scope of the invention, which is defined in the claims following the description. 
         [0018]      FIG. 1  is a flowchart representation of a process of opening a network connection in an operating system in accordance with a preferred embodiment of the present invention. The process begins with the operating system receiving a request to open a network connection (via a call to the appropriate routine in the sockets API or other suitable networking API-one skilled in the art will recognize that the example provided in  FIG. 1  utilizes the sockets API, but other similar APIs, such as the X/Open Transport Interface or “XTI,” may be used without limitation) (block  100 ). In response to this call, the operating system first naively complies with the request by opening a normal network connection (e.g., a socket connection) (block  102 ). 
         [0019]    Next, however, a determination is made as to whether the address on the other end of the connection (the “destination node”) is actually a local address (i.e., that the connection is to a software entity residing in the same operating system on the same hardware node) (block  103 ). This determination is made by consulting the operating system&#39;s internal routing table, which indicates which network interface is used to transmit packets to the destination node. If the destination node is a local address, a physical network interface is not used transmit/receive packets to/from the destination node; rather a fictitious or “virtual” interface, known as the “loopback interface,” is used instead. The loopback interface is a software-defined construct that simply sends packets to itself, rather than through a hardware network adapter. In a typical TCP/IP networking system, the loopback interface is assigned the IP address 127.0.0.1 by convention. 
         [0020]    In a preferred embodiment of the present invention, the operating system kernel provides a service for determining the route taken by packets through a given network connection and returning that route to the calling routine. Thus, the destination node for a given network connection is determined to be local by first querying this route lookup kernel service, then determining if the returned route is a route through the loopback interface. If the route goes through the loopback interface, then the destination node is a local address. 
         [0021]    If the destination node is not local (block  103 :No), then the process of opening the connection simply terminates. If the destination node is local, however (block  103 :Yes), then the operating system generates an interprocess communication (IPC) construct to replace the conventional network connection (socket connection) (block  104 ). 
         [0022]    It should be noted that in this context, the terms “interprocess communication” and “IPC” are used in a broad sense to incorporate any of a number of different operating system constructs used for facilitating communication between software entities (e.g., processes and threads) in a multitasking operating system, notwithstanding the fact that some operating systems (most notably, UNIX System V and related operating systems) use the term IPC to refer to a specific type of interprocess communication construct. The terms “interprocess communication” and “IPC,” as used here, encompass other types of operating system constructs, such as pipes, FIFOs (First-In-First-Out), and the like. Indeed, these other types of constructs, many of which follow a stream-like model input/output, are actually preferred over the messaging and shared memory communications constructs provided by “System V IPC.” 
         [0023]    In particular a preferred embodiment of the present invention replaces the local network connection with a stream-like interprocess communication construct. A number of such constructs are widely known in the art. POSIX-compliant operating systems define a bidirectional “FIFO” construct, which provides stream-based I/O between processes. POSIX-based operating systems also provide a feature called “pipes,” which provide similar stream-based I/O. The POSIX standard defines only half-duplex pipes, however, so it is necessary in some operating systems to utilize a pair of pipes for full-duplex communications (although some operating systems, such as UNIX System V Release 4, support bidirectional pipes or, as in the case of the open-source Linux operating system, paired half-duplex pipes). 
         [0024]    Another form of interprocess communication construct that may be utilized is that of “operating system-domain sockets” or “local domain sockets” (commonly referred to as “UNIX domain sockets” in the UNIX/POSIX community). These are interprocess communication constructs (i.e., they do not allow for communication over a network interface) that utilize the same API as network sockets, but that are bound to a pathname (i.e., filename) rather than to a network address. 
         [0025]    Once the interprocess communication construct has been created, an entry is made in a mapping table to denote a mapping from the original network connection to the new interprocess communication construct (block  106 ). In a preferred embodiment implemented in a POSIX-like operating system, both network sockets and stream-based IPC constructs are assigned to numerical “descriptor values,” which function like file descriptors. Thus, a mapping table to map network connections to associated IPC constructs may be constructed in the form of table  200  in  FIG. 2 , where numerical socket descriptors (sockfd) are mapped into IPC construct descriptors, which in this example are bidirectional FIFOs (fifofd). Once this mapping is complete, all input/output can be performed through the IPC construct in the manner shown in  FIG. 3 . At this point, it is actually possible to close or destroy the original network connection (generated at block  102 ), as long as this is done in a manner that is undetectable by the applications on either end of the connection. In any case, the process of responding to the connection request is complete and control may be returned to the calling application. 
         [0026]    One skilled in the art will recognize that in an alternative embodiment of the present invention, the original socket connection need not actually be established before creating the interprocess communication construct. If it can be determined initially that the destination node is local without creating a socket connection, then the interprocess communication construct can be created to begin with, without opening a socket connection at all. 
         [0027]      FIG. 3  is a diagram of a process of reading from, writing to, querying, or destroying a network connection in accordance with a preferred embodiment of the present invention. A call is received by the operating system to read, write, query, or close a connection made in accordance with the process shown in  FIG. 1  (block  300 ). The operating system then determines if the socket descriptor (or other form of handle used to identify the connection) can be found in the mapping table (table  200  in  FIG. 2 ). If, so, then whatever operation would have been performed on that connection&#39;s socket (reading, writing, querying status, closing, etc.) is performed instead on the IPC construct associated with the socket descriptor in the mapping table (block  304 ). The result of this operation is then placed in the usual form of output for the API in which the call was initially received and this result is returned through that API (block  305 ). In some instances, it may be necessary to generate spurious information to return through the API to maintain compatibility with the original API specification, where the information normally returned API is not applicable to the IPC construct. At this point, control returns to the calling application. 
         [0028]    As can be seen, the processes of  FIGS. 1 and 3  provide an application-independent method of improving the performance of network applications in a single operating system that must communicate with one another. This method is completely transparent to the applications, as it is performed by the operating system through normal network system calls. 
         [0029]      FIG. 4  illustrates information handling system  401  which is a simplified example of a computer system/data processing system capable of performing the computing operations described herein with respect to a preferred embodiment of the present invention. Computer system  401  includes processor  400  which is coupled to host bus  402 . A level two (L 2 ) cache memory  404  is also coupled to host bus  402 . Host-to-PCI bridge  406  is coupled to main memory  408 , includes cache memory and main memory control functions, and provides bus control to handle transfers among PCI bus  410 , processor  400 , L 2  cache  404 , main memory  408 , and host bus  402 . Main memory  408  is coupled to Host-to-PCI bridge  406  as well as host bus  402 . Devices used solely by host processor(s)  400 , such as LAN card  430 , are coupled to PCI bus  410 . Service Processor Interface and ISA Access Pass-through  412  provides an interface between PCI bus  410  and PCI bus  414 . In this manner, PCI bus  414  is insulated from PCI bus  410 . Devices, such as flash memory  418 , are coupled to PCI bus  414 . In one implementation, flash memory  418  includes BIOS code that incorporates the necessary processor executable code for a variety of low-level system functions and system boot functions. 
         [0030]    PCI bus  414  provides an interface for a variety of devices that are shared by host processor(s)  400  and Service Processor  416  including, for example, flash memory  418 . PCI-to-ISA bridge  435  provides bus control to handle transfers between PCI bus  414  and ISA bus  440 , universal serial bus (USB) functionality  445 , power management functionality  455 , and can include other functional elements not shown, such as a real-time clock (RTC), DMA control, interrupt support, and system management bus support. Nonvolatile RAM  420  is attached to ISA Bus  440 . Service Processor  416  includes JTAG and I 2 C buses  422  for communication with processor(s)  400  during initialization steps. JTAG/I 2 C buses  422  are also coupled to L 2  cache  404 , Host-to-PCI bridge  406 , and main memory  408  providing a communications path between the processor, the Service Processor, the L 2  cache, the Host-to-PCI bridge, and the main memory. Service Processor  416  also has access to system power resources for powering down information handling device  401 . 
         [0031]    Peripheral devices and input/output (I/O) devices can be attached to various interfaces (e.g., parallel interface  462 , serial interface  464 , keyboard interface  468 , and mouse interface  470  coupled to ISA bus  440 . Alternatively, many I/O devices can be accommodated by a super I/O controller (not shown) attached to ISA bus  440 . 
         [0032]    In order to attach computer system  401  to another computer system to copy files over a network, LAN card  430  is coupled to PCI bus  410 . Similarly, to connect computer system  401  to an ISP to connect to the Internet using a telephone line connection, modem  475  is connected to serial port  464  and PCI-to-ISA Bridge  435 . 
         [0033]    While the computer system described in  FIG. 4  is capable of executing the processes described herein, this computer system is simply one example of a computer system. Those skilled in the art will appreciate that many other computer system designs are capable of performing the processes described herein. 
         [0034]    One of the preferred implementations of the invention is a client application, namely, a set of instructions (program code) or other functional descriptive material in a code module that may, for example, be resident in the random access memory of the computer. Until required by the computer, the set of instructions may be stored in another computer memory, for example, in a hard disk drive, or in a removable memory such as an optical disk (for eventual use in a CD ROM) or floppy disk (for eventual use in a floppy disk drive), or downloaded via the Internet or other computer network. Thus, the present invention may be implemented as a computer program product for use in a computer. In addition, although the various methods described are conveniently implemented in a general purpose computer selectively activated or reconfigured by software, one of ordinary skill in the art would also recognize that such methods may be carried out in hardware, in firmware, or in more specialized apparatus constructed to perform the required method steps. Functional descriptive material is information that imparts functionality to a machine. Functional descriptive material includes, but is not limited to, computer programs, instructions, rules, facts, definitions of computable functions, objects, and data structures. 
         [0035]    While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that, based upon the teachings herein, changes and modifications may be made without departing from this invention and its broader aspects. Therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of this invention. Furthermore, it is to be understood that the invention is solely defined by the appended claims. It will be understood by those with skill in the art that if a specific number of an introduced claim element is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such limitation is present. For non-limiting example, as an aid to understanding, the following appended claims contain usage of the introductory phrases “at least one” and “one or more” to introduce claim elements. However, the use of such phrases should not be construed to imply that the introduction of a claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an;” the same holds true for the use in the claims of definite articles. Where the word “or” is used in the claims, it is used in an inclusive sense (i.e., “A and/or B,” as opposed to “either A or B”).