US20050071857A1 - Accelerating a distributed component architecture over a network using a direct marshaling - Google Patents
Accelerating a distributed component architecture over a network using a direct marshaling Download PDFInfo
- Publication number
- US20050071857A1 US20050071857A1 US10/966,508 US96650804A US2005071857A1 US 20050071857 A1 US20050071857 A1 US 20050071857A1 US 96650804 A US96650804 A US 96650804A US 2005071857 A1 US2005071857 A1 US 2005071857A1
- Authority
- US
- United States
- Prior art keywords
- computer
- data
- rpc
- server
- buffer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
A method for improving the performance of a distributed object model over a network is disclosed. A client computer contains a client object which can call an interface on a server object located on a server computer. Rather than copying all of the call parameters into an RPC buffer for transmission across the network, a network interface card with scatter-gather capability can be used. The RPC data can contain only a list of pointers into the client memory and a size of each parameter. The network interface card can then grab the parameters directly from the client memory using the list in the RPC buffer without the need to copy the data itself. At the server side, the network interface card can place the parameters into an RPC buffer, or if the size is known beforehand, directly into the server memory. The server can also access the parameters directly from the RPC buffer. On the return, the server can use a callback function to indicate when its network interface card has finished sending the response data so that the server does not clear its memory prematurely. At the client side, if the size of the response is not known, and the data is placed into the RPC buffers, it can be copied from the RPC buffer into the client memory.
Description
- This application is a continuation of prior U.S. patent application Ser. No. 09/458,139, filed Dec. 9, 1999, (allowed on Aug. 16, 2004) which claims the benefit of U.S. Provisional Application Ser. No. 60/111,788 filed Dec. 11, 1998, both of which are incorporated herein by reference.
- This invention relates generally to software communication over a network and, more particularly, relates to acceleration of the interaction of objects over a network.
- A component object model defines the interactions between computer software components. The advantage of component programming is that it facilitates the use of reusable sections of code. Programs will often provide similar functionality. For example, many modern software applications provide pull-down menu functionality. Computer code that allows a user to pull down a menu on the computer screen can be found in some form in each of these applications. A component providing the same functionality, however, would only need to be written once, and then simply reused by each succeeding application. The time required to create an application, therefore, can be significantly reduced by reusing preexisting components.
- For object-based component programming to be successful, a standard method of interactions between objects must be defined. One such standard is the Component Object Model, or COM. COM mandates that all objects interact through interfaces. Each interface is a collection of functions that the object can perform. The object is said to have “exposed” the methods contained in its interfaces, which can then be “called”, or used, by another object. Another standard, based on COM is the Distributed Component Object Model, or DCOM. DCOM defines a standard method of interaction between objects that may be located on remote computers connected through a network. DCOM uses a Remote Procedure Call (RPC) model to define a method of communication between objects across a network. The RPC model is independent of the underlying network structure or protocols.
- As can be expected, calling an object located on the same computer is faster than calling an object located on a remote computer. This speed difference can be due to a number of factors. The network cables are significantly longer than the leads between the processor and the memory on the local machine. Therefore, the electrical signals simply take longer to reach the remote computer than to reach the object resident in memory on the local machine. A significantly larger factor is the overhead caused by the network protocol. Each data transmission over a network must be encapsulated, and additional information must be added to the packet so that it may be transferred across the network with error correcting capabilities, and so that it may properly be decoded on the remote machine. Furthermore, each packet sent over a network may be accompanied by a flurry of additional network packets performing necessary buffer management and receipt acknowledge functions. These further packets, which comprise the network flow control, also add to the time required to send an object call over a network to a remote computer.
- An additional factor contributing to the speed difference between a call to an object resident on the same machine and one resident on a remote machine is the overhead created by DCOM and the RPC model. RPC marshals pointers and data to be transmitted across the network by reading them from the program memory and packaging them for transportation across the network. Marshaling introduces delay because it copies from program memory into an RPC buffer the element that is to be transmitted across the network. Another aspect of the overhead of DCOM and RPC are the runtime layers. The RPC and DCOM runtime layers bridge together the client and server so that the client can make remote calls to the server. This process of bridging the client and server together is known as binding. Binding information can include the Internet Protocol (IP) address, the port number, and the interface identifier (IID).
- The combined effects of the marshaling, the additional packets of flow control, and the activities of the runtime layers result in a dramatic decrease in the performance of DCOM over a network. In fact, compared to a raw network application which directly sends data across the network, the DCOM overhead can decrease performance by a factor of three or more.
- Accordingly, the present invention provides a method for increasing the efficiency of calling remote objects over a network using DCOM.
- The present invention also provides a more efficient method of marshaling DCOM application data.
- The invention additionally provides a method for maximizing the efficiency of RPC flow control.
- The invention also provides for a more efficient binding between the client and the server.
- An object model, such as DCOM, can allow communication across a network by making the network communication transparent to the client and server objects. DCOM uses a “proxy” on the client process and a “stub” on the server process to achieve such transparency. The proxy acts as a local version of the server object which the client can call, and the stub acts as a local client object on the server. The proxy and stub then communicate with one another across the network. To perform this communication, the proxy marshals the call parameters into an RPC buffer, from which they are transferred across the network to the stub. The stub unmarshals the call parameters, and calls the server object directly. Similarly, on the return, the stub marshals the call results into an RPC buffer for transmission across the network to the proxy, which unmarshals the results and returns them to the client process.
- The present invention allows DCOM systems using a network interface card (NIC) with “scatter-gather” ability to gather elements from various memory locations to avoid copying the call parameters into the RPC buffer. Instead, the proxy or stub simply create a pointer list in the buffer, which is then accessed by the NIC, which can collect the elements from memory and is responsible for sending the data across the network. To indicate that the RPC buffer contains only a list and not the actual values themselves, the proxy or stub can set a flag, which is understood by the NIC or RPC runtime. On the server side, the stub code can hold onto the buffer and not clear it until the NIC has finished sending the data. In such a case, a callback function can be used by the NIC to indicate that it has completed sending the data.
- Another method of improving the network performance of an object model such as DCOM is to make more efficient the communication between a client and a server through the RPC layer. DCOM was designed to take advantage of the existing architecture of RPC, provides a mechanism for making calls to remote computers connected by a network. When a local RPC object seeks to call a remote RPC interface, the call can specify the IP address, the port number and the RPC IID. DCOM takes advantage of the RPC structure, except that DCOM uses an interface pointer identifier (IPID) to uniquely specify the COM interface to which the call is being made. In order to use the RPC structure, the DCOM client object must send an RPC IID to the RPC runtime layer and an IPID to the DCOM runtime layer. Because the IPID is more specific than the RPC IID, the RPC IID is redundant and the additional computation performed by the RPC layer is wasted.
- The present invention removes the additional computation and communication performed by RPC and allows the DCOM client to send only an IPID. The RPC dispatching layer on the server side is removed from the critical path. All incoming DCOM calls are forwarded to the DCOM dispatching layer directly. The client side can then be modified, so that the calling DCOM object only needs to send an IPID. The removal of the RPC dispatching allows DCOM communication to proceed without a duplication of effort, and therefore more efficiently.
- Yet another method of improving DCOM performance involves modifying the flow control performed by the software protocol stacks. When transmitting data, a buffer on the receiving side must be made available before each packet of data can be sent. Furthermore, the sender must know that the receiver has made a buffer available, using some form of flow control, before sending a message. With traditional transport layers, the sender waited for an explicit “OK TO SEND” flow-control message, thereby insuring that the receiver had sufficient resources to accept the data the sender was waiting to transmit. In the worst case, which can be typical for RPC and DCOM communication, the sending of each data packet requires the sending of one flow control packet, flow control packets account for one half of the network traffic. More importantly, the waiting computer does no useful work while waiting for the “OK TO SEND” flow control message. Such idle time reduces the efficiency of the overall system.
- The present invention modifies the RPC transport layer to use an implicit flow control. Implicit flow control does not require an explicit communication from the receiver indicating it is ready to receive; such as an “OK TO SEND” message. Rather, implicit flow control insures that the receiver is ready to receive by implicitly associating flow control messages with regular application messages. The present invention allows a sending computer to pre-post a receive buffer prior to sending out any data that may cause a response message to be sent from the receiving computer. Therefore, when the receiving computer receives the data from the sending computer, it is an implicit acknowledgement that the sending computer is ready to receive. By pre-posting the receive buffer prior to sending any data, the sending of data becomes an indication that the next receive buffer is ready. Thus, the regular application messages can be considered flow control messages. Such a system eliminates the overhead due to the standard flow control by relying on the request/reply semantics of RPC communication. Additionally, the flow control of the present invention minimizes the idle time of the sending and receiving computers. By removing the explicit flow control messages, the present invention allows computers to reorganize their send and receive cycles to minimize idle time, and thereby maximize efficiency. Note that the present invention is more efficient than prior systems, such as the standard TCP protocol, which piggyback explicit flow-control messages on outgoing application messages as often as possible. For example, the TCP heuristics to piggyback explicit flow control-messages fail to optimize flow-control in request-reply traffic between client and server, which is exactly the traffic for RPC, DCOM, and HTTP.
- Additional features and advantages of the invention will be made apparent from the following detailed description of illustrative embodiments which proceeds with reference to the accompanying figures.
- While the appended claims set forth the features of the present invention with particularity, the invention, together with its objects and advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings of which:
-
FIG. 1 is a block diagram generally illustrating an exemplary computer system on which the present invention resides; -
FIG. 2 is a block diagram generally illustrating the operation of DCOM over an exemplary network and computers; -
FIG. 3A is a block diagram generally illustrating the layers of DCOM on a client and the transfer of data from a client to a server; -
FIG. 3B is a block diagram generally illustrating the layers of DCOM on a server and the transfer of data from a client to a server; -
FIG. 4A is a block diagram generally illustrating the layers of DCOM on a client and the transfer of data from a client to a server according to one aspect of the present invention; -
FIG. 4B is a block diagram generally illustrating the layers of DCOM on a server and the transfer of data from a client to a server according to one aspect of the present invention; -
FIG. 5A is a flow chart generally illustrating the layers of DCOM on a client and the transfer of data from a server to a client according to one aspect of the present invention; -
FIG. 5B is a flow chart generally illustrating the layers of DCOM on a server and the transfer of data from a server to a client according to one aspect of the present invention; -
FIG. 6 is a block diagram generally illustrating the operation of RPC dispatching and DCOM dispatching; -
FIG. 7 is a communication flow diagram generally illustrating explicit flow control; -
FIG. 8 is a communication flow diagram generally illustrating implicit flow control according to one aspect of the present invention; and -
FIG. 9 is a communication flow diagram generally illustrating implicit flow control according to another aspect of the present invention. - Turning to the drawings, wherein like reference numerals refer to like elements, the invention is illustrated as being implemented in a suitable computing environment. Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by a personal computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including hand-held devices, multi-processor systems, microprocessor based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
- With reference to
FIG. 1 , an exemplary system for implementing the invention includes a general purpose computing device in the form of a conventionalpersonal computer 20, including aprocessing unit 21, asystem memory 22, and asystem bus 23 that couples various system components including the system memory to theprocessing unit 21. Thesystem bus 23 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read only memory (ROM) 24 and random access memory (RAM) 25. A basic input/output system (BIOS) 26, containing the basic routines that help to transfer information between elements within thepersonal computer 20, such as during start-up, is stored inROM 24. Thepersonal computer 20 further includes ahard disk drive 27 for reading from and writing to ahard disk 60, amagnetic disk drive 28 for reading from or writing to a removablemagnetic disk 29, and anoptical disk drive 30 for reading from or writing to a removableoptical disk 31 such as a CD ROM or other optical media. - The
hard disk drive 27,magnetic disk drive 28, andoptical disk drive 30 are connected to thesystem bus 23 by a harddisk drive interface 32, a magneticdisk drive interface 33, and an opticaldisk drive interface 34, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for thepersonal computer 20. Although the exemplary environment described herein employs ahard disk 60, a removablemagnetic disk 29, and a removableoptical disk 31, it will be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories, read only memories, and the like may also be used in the exemplary operating environment. - A number of program modules may be stored on the
hard disk 60,magnetic disk 29,optical disk 31,ROM 24 orRAM 25, including anoperating system 35, one ormore application programs 36,other program modules 37, andprogram data 38. A user may enter commands and information into thepersonal computer 20 through input devices such as akeyboard 40 and apointing device 42. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to theprocessing unit 21 through aserial port interface 46 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or a universal serial bus (USB). Amonitor 47 or other type of display device is also connected to thesystem bus 23 via an interface, such as avideo adapter 48. In addition to the monitor, personal computers typically include other peripheral output devices, not shown, such as speakers and printers. - The
personal computer 20 may operate in a networked environment using logical connections to one or more remote computers, such as aremote computer 49. Theremote computer 49 may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to thepersonal computer 20, although only amemory storage device 50 has been illustrated inFIG. 1 . The logical connections depicted inFIG. 1 include a local area network (LAN) 51, a wide area network (WAN) 52, and a high-speed system area network (SAN) 56. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet. - When used in a LAN networking environment, the
personal computer 20 is connected to thelocal network 51 through a network interface oradapter 53. When used in a WAN networking environment, theperson computer 20 typically includes amodem 54 or other means for establishing communications over theWAN 52. Themodem 54, which may be internal or external, is connected to thesystem bus 23 via theserial port interface 46. When connected to a SAN, thepersonal computer 20 is connected via a high-speed network interface 55. In a networked environment, program modules depicted relative to thepersonal computer 20, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used. - In the description that follows, the invention will be described with reference to acts and symbolic representations of operations that are performed by one or more computers, unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processing unit of the computer of electrical signals representing data in a structured form. This manipulation transforms the data or maintains it at locations in the memory system of the computer, which reconfigures or otherwise alters the operation of the computer in a manner well understood by those skilled in the art. The data structures where data is maintained are physical locations of the memory that have particular properties defined by the format of the data. However, while the invention is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that various of the acts and operation described hereinafter may also be implemented in hardware.
- In accordance with the invention, the interactions of a distributed object model are shown in
FIG. 2 . An object model can define a standard set of rules governing the interaction of “objects”, such asobjects - An object model, such as the Component Object Model (COM) from Microsoft Corporation, seeks to define a set of standards so that objects written by one individual can be used by all, without any changes to the object, and even without understanding how the object is implemented internally. To accomplish this, object models can require objects to implement interfaces. As will be known by one of skill in the art, an interface, such as
interface 82 ofobject 76, is a set of functions provided by the object which a client of the object can request. A client of an object can only interact with an object through that object's interfaces. Therefore, if an object is capable of performing a certain task, a function for that task will exist in one of the object's interfaces. To request that the object perform a task, the client of the object can select an interface and make a call to the appropriate function. Because clients can only interact with an object through its interfaces, the specific structure and internal workings of the object are irrelevant. - Due to the increasing popularity of networked computing, it is desirable that objects can interact with one another over a network. To maintain compatibility, and not require rewriting, an object model which seeks to allow implementation across a network can provide some mechanism for transparent network communication. As seen from the client's perspective, there should be no difference between calling an object on a local computer and an object on a remote, networked computer. One such object model, the Distributed Component Object Model (DCOM) from Microsoft Corporation, uses a “proxy” in the client process and a “stub” in the server process to achieve such transparency.
- Turning again to
FIG. 2 , aninterface 82 is shown exposed byserver object 76. As can be seen,server object 76 resides onserver computer 72.Server computer 72 andclient computer 70 are connected through anetwork connection 90, which can be aSAN 56. In order to allowclient object 74, resident onclient computer 70, to callinterface 82 of theserver object 76, DCOM creates aproxy 78 on the client computer and astub 80 on the server computer. Theproxy 78 on theclient computer 70 acts as the client-side representative of theserver object 76 by exposing aninterface 84 analogous to interface 82 exposed by the server object. Theclient object 74 can therefore callinterface 84 in exactly the same manner it would call any local interface. Once theclient object 74calls interface 84, theproxy 78 transfers the call across thenetwork connection 90 to thestub 80. It is thestub 80 which then calls theactual interface 82 of theserver object 76. Theserver object 76 can respond in an analogous manner by sending the reply data to thestub 80 and having the stub transfer it across thenetwork connection 90 to theproxy 78, which then presents the data to theclient object 74. Therefore, because theproxy 78 and thestub 80 are both located on the same machine as the objects with which they communicate, they allow those objects to make calls and return data in exactly the same manner as they did in a local context. Theproxy 78 andstub 80 then package the calls and data and send them across the network, allowing for a distributed object system. Theproxy 78 andstub 80, therefore, make the network transparent toclient object 74 andserver object 76. - A known layered architecture of DCOM is shown in
FIGS. 3A & 3B . As shown inFIG. 3A , when theDCOM client 120 makes a remote call, themarshaling layer 122 prepares the call for transmission across the network. The proxy 78 acts as themarshaling layer 122 on theclient 70 and thestub 80 acts as themarshaling layer 140 on theserver 72. Marshaling, as will be explained in more detail below, is the packaging of the call for transmission across thenetwork connection 90. After themarshaling layer 122 marshals the call, the DCOM run-time layer 124 transmits the call over the network. The DCOM run-time layer 124 transmits the call by invoking the functionality of the Remote Procedure Call (RPC) run-time layer 126. DCOM's structure allows it to take advantage of the existing structure of RPC, as will be explained below. Theloadable transport layer 128 allows the systems above it to run on any number of different protocols, which are implemented in the protocol stacks 130. The protocol stacks 130 then create the packets sent out over thenetwork connection 90. On the server side, shown inFIG. 3B , the protocol stacks 132 receive the packets, translate them, and pass them to theloadable transport layer 134, which further translates the data into a form which the RPC run-time layer 136 can accept. The RPC run-time layer 136 then accepts the communication, and creates a binding if the call is the first call to an interface. The DCOM run-time layer 138 accepts the communication from the RPC run-time layer 136 and passes it to thestub 80 at themarshaling layer 140. Thestub 80 unmarshals the parameters of the call and initiates the call to theDCOM server object 142. - The present invention provides for a number of improvements in this layered architecture; removing overhead, and increasing the speed of DCOM over the
network connection 90. One such improvement can be made at the marshaling layers 122 and 140. Marshaling is the process of arranging the data provided by theDCOM client 120 when it calls theDCOM server object 142 into a proper form for transmission across thenetwork connection 90. Simple data types such as characters and integers are not difficult to marshal. However, DCOM often passes more complex parameters, such as arrays of information. RPC can use a standard format called the Network Data Representation (NDR) to marshal the data. DCOM, since it is built on top of RPC, as shown inFIGS. 3A & 3B , can leverage RPC's functionality, such as the use of the NDR standard format. As is known by those of skill in the art, the NDR standard is a “receiver makes right” standard. Should any translation of the data be necessary for a client computer and a server computer to communicate, it is the receiver's responsibility to convert the data into the format it requires. Thus, it is the receiver which makes the data format “right” for itself. The sender, therefore, need not perform any conversion on the data. - With reference again to
FIGS. 3A & 3B , themarshalling layer 122, inFIG. 3A , using the NDR standard,marshals data 144 by reading parameters, such as pointers to arrays, or pointers to integers, placed by theDCOM client 120 onto thememory stack 121 of theclient computer 70. As is known by those skilled in the art, a call to a function passes parameters including immediate data values, such as integers or floating-point numbers, and pointers to additional data, such as pointers to arrays of data, pointers to text strings, or pointers to complex data structures. Therefore, when theDCOM client 120 makes a call to theDCOM server 142, it places onto the stack 121 aparameter set 125 include immediate data and pointers for the current call. The pointers in the parameter set 125 on thestack 121 point to thedata 144 which is in theclient computer memory 145. Themarshalling layer 122 first determines the required size of the RPC buffer for holding all marshaled data and the DCOM header, and requests such abuffer 123. Then it copies any immediate data in the parameter set 125 into the buffer. It also traverses all of the pointers in the parameter set 125 to retrieve all thedata 144 and copies them into the RPC buffer so that the call can be properly unmarshaled by themarshaling layer 140, inFIG. 3B . The DCOM run-time layer 124 adds the DCOM header and passes the buffer to the RPC run-time layer, requesting that the data be sent across the network. As will be known by one skilled in the art, anadditional copy 129 may be made by the operating system and placed into a protected-mode socket buffer 131 for transmission acrossnetwork connection 90. At the server side, shown inFIG. 3B , the transmitteddata 135 may be delivered into a protected-mode socket buffer 133 and from there into theRPC buffer 141. Themarshaling layer 140 unmarshals the marshaleddata 137 fromRPC buffer 141 into the parameter set 139 and theserver memory 147 on theserver computer 72. After the pointers in the parameter set 139 on thestack 143 have been recreated, the call made by theDCOM client 120 can then be made by thestub 140 to theDCOM server 142. - As described above, to perform marshaling, the proxy 122 copies immediate data from the parameter set 125 and
additional data 144 to anRPC buffer 123 for transmission. This buffer holds aduplicate 127 of the parameter set 125 and data, since the parameter set is still resident in thestack 121 and the data is still resident in thememory 144 from which it was copied. The present invention contemplates a direct marshaling which stores only a list of pointers to the memory locations of the data (either in the parameter set 125 or additional data 144) in the RPC buffer, rather than duplicating the data itself. As is known by those of skill in the art, a pointer is generally of much smaller memory size than the data it points to, especially in the case of pointers to large data arrays. Therefore, the speed at which theproxy 122 and thestub 140 could marshal and unmarshal the parameters would be increased by copying only pointers into the RPC buffer. - Certain network interface cards (NICs) provide for the ability to perform scatter-gather operations. One example of a network which can use the scatter-gather functionality of such a NIC is a network based on the Virtual Interface Architecture (VIA), which is an instance of a SAN. VIA allows network user-mode applications to directly request a scatter-gather mode of transmission without incurring the extra cost of a copy into a protected-mode buffer. The gathering and the sending of the data is performed directly by the NIC and requires no intervention by the host processor, thereby eliminating the kernel-mode protocol stacks 130 and 132. Furthermore, the request to send and receive data is presented by the user-mode application directly to the NIC without transitioning into the operating system kernel and associated device drivers.
- In accordance with the invention, and turning to
FIGS. 4A & 4B , a modifiedproxy 198 marshals a list ofpointers 125 into theRPC buffer 123. An RPC flag can be added to the modifiedproxy 198 andstub 199, described in more detail below, to allow them to inform the RPC run-time layers proxy 198 andstub 199. The larger data structure can accommodate the flag set by the modifiedproxy 198 andstub 199. If the flag is set, the RPC run-time layers data FIG. 4A , the RPC run-time layer 126 adds RPC headers to thelist 152 and passes it to theloadable transport layer 128. Theloadable transport layer 128 then passes the list to theuser mode stack 148, which implements the implicit flow control, described in more detail below. Theuser mode stack 148 stores thelist 153 in alist buffer 151. The NIC, at the VIAnetwork connection layer 150, gathers the immediate data from the parameter set 125 andadditional data 144, both pointed to by thelist 153, out of thestack 121 and theclient memory 145 and transmits it across the network. - On the receiving side, shown in
FIG. 4B , since the servers-side RPC runtime may receive calls on any methods supported by the server process, it is in general not possible to specify a receive scatter list for any arbitrary method in advance. However, since the receiving RPC buffer is dedicated to the on-going RPC call for its entire duration, the stub code and the server object can use the data in the RPC buffer directly without first copying the data into thedata 146 inserver memory 147, unless data format conversion is required. - Turning to
FIGS. 5A & 5B , a response from theDCOM server object 142 to theDCOM client 120 is shown. As shown inFIG. 5B , a modifiedstub 199 marshals a list ofpointers 157 into anRPC buffer 141. The list ofpointers 157 contains entries for any immediate return data in the return parameter set 139 and anyadditional data 146 inserver memory 147. An RPC flag can be added to the modifiedproxy 198 andstub 199, as described above, to allow them to inform the RPC run-time layers FIGS. 4A & 4B , the DCOM run-time layer 138 can add a DCOM header to the list. The RPC run-time layer 136 can then add RPC headers to thelist 157 and pass it to theloadable transport layer 134. Theloadable transport layer 134 then passes the list to theuser mode stack 149, which implements the implicit flow control, described in more detail below. Theuser mode stack 149 stores thelist 158 in alist buffer 153. The NIC, at the VIAnetwork connection layer 150, gathers all the data pointed to by thelist 158 and transmits it across the network. - Because the NIC performs the gather and send operation directly from the
server memory 147, theDCOM server 142 should delay clearing thememory 147 until after the NIC has finished gathering and transmitting the data. If theDCOM server object 142 were to clear the memory prior to the completion of the send operation, the NIC would not be able to gather theappropriate data 146 pointed to by thepointers 158. To insure that theDCOM server object 142 does not prematurelyclear data 146 but can still reclaim the memory after its usage, a callback function can be implemented at themarshaling layer 199 to be invoked by theloadable transport layer 134. Initially, when the modifiedstub 199 intends to use the direct marshalling, it passes down to the loadable transport layer 134 a context pointer and a function pointer to the callback function. Theloadable transport layer 134 then calls the callback function by supplying the context pointer as a parameter to indicate that the sending of thedata 146 has completed. - On the receiving side, shown in
FIG. 5A , if the client knows the size of each piece of the returning data when it makes the call, it can pass down a list of pointers for scattering in 159. In this case, when the NIC receives the transmitted data, it can scatter it directly intodata 144 inclient memory 145, as instructed by the list ofpointers 159. If the size of the returning data cannot be determined beforehand, the incoming data needs to be received by theRPC buffer 123 first. Unlike the server side, it is undesirable for the client to use the data frombuffer 123 directly because the client may need to hold on to the data beyond the end of current call. Therefore, thedata 160 inbuffer 123 needs to be copied todata 144 inclient memory 145 so that theRPC buffer 123 can be released. - The
proxy 78 andstub 80 shown inFIG. 2 implement standard marshaling. Should a user choose to do so, they could write a modifiedproxy 198 andstub 199 to perform the direct marshaling of the present invention, as disclosed above. One method for doing so is to manually replace the copy marshalling code with code which constructs a scatter-gather list and to move the buffer release code into an added callback function. The pointer to the buffer, the context pointer, and the pointer to the callback function, as described above, are passed to the RPC run-time layer and loadable transport layers. Those layers, as also described above, can then invoke the callback function by supplying the context pointer as a parameter when the buffer can be released. An alternative method for generating a modifiedproxy 198 andstub 199 to perform the direct marshaling of the present invention would be to use an IDL compiler. An interface can be described by the Interface Definition Language (IDL). As is known by those skilled in the art, once an interface is defined in IDL, an IDL compiler can create the code for both a proxy and a stub capable of marshaling the defined interface. One such IDL compiler is the Microsoft IDL (MIDL) compiler from Microsoft Corporation. The IDL compiler could be modified to automatically produce a proxy and stub capable of providing such direct marshaling. Alternatively, a command-line flag could be provided to indicate that direct marshalling is requested. - As can be seen, the present invention reduces the number of copies on the client side when calling an interface by marshaling only a list of pointers into the
RPC buffer 123 and allowing the network to access the data directly. On the server side, the received data can be retained in theRPC buffer 141, without copying tomemory 147. Additionally, such lists of pointers can be used to eliminate a copy on the server side when sending a response from theDCOM server 142, and when receiving the response on the client side. The elimination of these copies results in a more efficient transfer process from theDCOM client 120 to theDCOM server 142 and from the server to the client. - An additional optimization contemplated by the present invention is the removal of dispatching redundancies between the DCOM run-
time layers time layers server computer 72. Generally dispatching identifies an interface with succeeding levels of specificity. Turning toFIG. 6 , RPC dispatching and DCOM dispatching on theserver computer 72 are illustrated. In order for a call from an RPC client to arrive at thecorrect server computer 72, the call can specify the Internet Protocol (IP) address of the server to which it is making the call. Each server can then have multiple port address on which a call can be made, and a port address can be specified in the call. The call can also specify the interface identifier (IID) of the RPC interface to which the call is made. Multiple interfaces can be called through a single port. Thus, as shown inFIG. 6 , theserver 72 first checks the IP address atstep 170. If the IP address corresponds to theserver 72, the server checks which port address is specified in the call atstep 168. Once the port address is determined, the server can pass the call to the appropriate RPC dispatching atstep 166 which, depending on whether IID1 or IID2 was called can direct the call to interface IID1 atstep 162 or interface IID2 atstep 164. - DCOM dispatching is performed in a similar manner, since DCOM is layered on top of RPC, as can be seen from
FIGS. 3A, 3B , 4A, 4B, 5A, and 5B. As shown inFIG. 6 , theserver 72 first checks the IP address atstep 184. If the IP address corresponds to theserver 72, the server checks which port address is specified in the call atstep 182. Once the port address is determined, the server can pass the call to the appropriate DCOM dispatching element atstep 180. Unlike RPC, however, a single DCOM object, such asobject 76 inFIG. 2 can have multiple interfaces, such asinterface 82. Because each interface has a unique interface identifier (IID) only within the object providing that interface, it is possible for two interfaces of two separate DCOM objects to have an identical IIDs. Furthermore, because multiple DCOM objects can be called through a single port, it is possible for two interfaces of two separate DCOM objects, each of which can be called through the same port, to have an identical IIDs. Therefore, to uniquely identify an interface in such an environment, DCOM can use an interface pointer identifier (IPID). The IPID is a combination of the IID of the interface, and the object identifier (OID) of the object providing the interface. In such a manner, the IPID can uniquely identify the interface by referencing both the IID and the OID. - Therefore, in
FIG. 6 , when theserver 72 passes the call to the DCOM dispatching element atstep 180, the DCOM dispatching element determines the appropriate IPID to which the call is directed. The DCOM dispatching element atstep 180 is also known as the stub manager, because it directs the call to the appropriate stub, such asstub 80 inFIG. 2 , based on the IPID. Thus, inFIG. 6 , if the call was directed to interface IPID1, the stub manager atstep 180 can pass the call to stub1 atstep 176 to call the interface. Alternatively, if the call was directed to interface IPID2, the stub manager atstep 180 can pass the call to stub2 atstep 178 to call the interface. As is known by those skilled in the art, a single stub can access multiple interfaces. Thus, it is not required that the stub manager atstep 180 invoke a different stub for each call to a different interface. - As can be seen, DCOM relies on an IPID, a combination of an IID and an OID to perform dispatching, while RPC relies only on the IID. Nevertheless, because of the similarities between the two systems, DCOM can be implemented to take advantage of RPC dispatching. The RPC run-
time layer 136 implements an RPC dispatching 186 layer, as shown inFIG. 6 , and anadditional layer 188 to handle further RPC duties. The RPC run-time layer 126 does not implement thedispatching layer 186, as a client computer does not dispatch a call.RPC layer 188 can include RPC security, RPC thread management, RPC socket connection management, and RPC association management. The DCOM run-time layer 138, which implements the DCOM dispatching 190, can be thought of as built on top of the RPC dispatching 186 and theRPC layer 188, as shown inFIG. 6 . The DCOM run-time layer 124 on theclient computer 70 does not implement dispatching, but can provide DCOM security. To ensure that the RPC run-time layer time layer 124 can still specify an IID to which the call is directed. In such a way the RPC dispatching 186 on theserver 72 can handle a DCOM call as it would an RPC call. However, the DCOM dispatching 190 can use an IPID to uniquely specify the interface to which the call is directed. The RPC IID is therefore redundant, and used solely for the purpose of utilizing theRPC layer 188. Furthermore, when the RPC dispatching 186 receives the IID, it performs additional functions, such as setting up a communication dictionary, which are redundant in light of the DCOM dispatching 190. The redundancy is significant because the functions performed to enable RPC dispatching sometimes require a network communication from theclient computer 70 to theserver computer 72 and a return communication from the server to the client. As is known by those skilled in the art, communications across a network connection require significantly more time than communications local to theclient computer 70. - The present invention, therefore, contemplates removing the use of the RPC IID and the attendant inefficiencies while maintaining the useful RPC security, thread management, socket connection management, and association management. One method for doing so is to remove the RPC dispatching 186 and allow the DCOM run-
time layer 124 to specify only an IPID. On theserver computer 72, when the RPC run-time layer 136 completes the steps required by theRPC utility layer 188, such as confirming the authenticity of theclient computer 70, it performs the RPC dispatching inlayer 186. However, as described above, the processing of theRPC dispatching layer 186 is inefficient, as theDCOM dispatching layer 190 will perform its own dispatching when the RPC dispatching is finished. Furthermore, theRPC dispatching layer 186 will only provide a pointer into theDCOM dispatching layer 190. Therefore, the present invention contemplates providing the pointer to theDCOM dispatching layer 190 directly to theRPC utility layer 188. In such a manner, when theRPC utility layer 188 completes its tasks, it can pass the call directly to theDCOM dispatching layer 190. - An additional modification which can be made as a result of the change to the RPC run-
time layer 136 described above, is to remove those API calls to the RPC dispatching 186 from the DCOM run-time layer 138. An example of the APIs affected is shown in Table 1 below. As can be seen from the table, the API calls that can be removed are those that perform functions attendant with RPC dispatching.TABLE 1 RPC_STATUS RPC_ENTRY RpcServerInqIf( RPC_STATUS RPC_ENTRY RpcServerRegisterIf( RPC_STATUS RPC_ENTRY RpcServerRegisterIfEx( RPC_STATUS RPC_ENTRY RpcServerUnregisterIf( RPC_STATUS RPC_ENTRY RpcServerUseAllProtseqsIf( RPC_STATUS RPC_ENTRY RpcServerUseAllProtseqsIfEx( RPC_STATUS RPC_ENTRY RpcServerUseProtseqIf( RPC_STATUS RPC_ENTRY RpcServerUseProtseqIfEx( - On the
client computer 70, the DCOM run-time layer 124 can be modified by removing the code that sends the IID together with the IPID. Because theserver 72 no longer performs RPC dispatching prior to DCOM dispatching, there is no longer a need for the IID. As was described above, the IPID uniquely identifies the interface called, and is (conceptually) composed of a combination of the IID and the OID. Therefore, efficiencies are achieved due to the elimination of repeated tasks between the DCOM run-time layer 138 the RPC run-time layer 136 on the server machine; most notably the RPC run-time layer 136 no longer performs a round-trip network communication when the call is first initiated. - Another improvement to the speed at which DCOM runs over a network can be achieved through a modification of the RPC flow control. Flow control ensures that each packet sent across a network is being expected by the intended recipient.
FIG. 7 illustrates a known flow control scheme, which uses an explicit flow control. With such an explicit flow control, the sender must wait until the receiver signals it is ready to receive prior to sending a packet across the network. Thus, inFIG. 7 , theclient computer 70 waits atstep 204 for theserver computer 72 to indicate that it is ready to receive. An OK TO SEND message can be one such indication that the computer is ready to receive. Atstep 200 theserver computer 72 can post a receive buffer. By posting the receive buffer, theserver computer 72 is setting aside memory in which to receive whatever data theclient computer 70 will send. Meanwhile, atstep 204, theclient computer 70 is idling, waiting for permission to send the data. Once theserver computer 72 has posted the receive buffer atstep 200, it can send an OK TO SENDmessage 202. When theclient computer 70 receives the OK TO SENDmessage 202, it can then proceed, atstep 206 to send its request to theserver computer 72. The request is sent asdata 208, which is received by the server computer and placed in the receive buffer atstep 210. Once the request has been received, the server can perform whatever work is required by the request atstep 212. When theserver computer 72 has finished the work which was requested by the client, it idles, atstep 214, waiting for the client to signal that it is ready to receive. The client computer can post its receive buffer atstep 216, and can then send an OK TO SENDmessage 218. When the server receives the OK TO SENDmessage 218, it can send its response to the client's request atstep 220. Theresponse data 222 is received by the client and can be placed in the receive buffer atstep 224. - As can be seen from
FIG. 7 , the known flow control protocol results in two OK TO SEND messages for each client request and server response. The flow control messages thus account for 50% of the message traffic. Furthermore, the efficiency of the system is reduced when the client and server computers wait for one another to send explicit flow control messages, not performing any useful work in the interim. The present invention contemplates removing the overhead and the inefficiency of the known system by implementing an implicit flow control at theloadable transport layers user mode stack FIG. 8 . As can be seen, neither of the OK TO SEND explicit flow control transmissions ofFIG. 7 are present. The explicit flow control messages can be eliminated because, prior to sending any data, each computer can first pre-post a receive buffer. Therefore, the very act of sending a message is an indication to the other computer that the receive buffer is already posted and the computer is ready to receive. Thus, the other computer need not wait for an explicit flow control message; rather the receipt of any message is an implicit OK TO SEND. This implicit flow control, as will be described in more detail with reference toFIG. 8 , allows for the removal of the flow control messages. Furthermore, as will be described in more detail with reference toFIG. 9 , the implicit flow control of the present invention can increase the efficiency of the overall system by reducing the unproductive computer time spent waiting for explicit flow control messages to be sent. - The implicit flow control of the present invention requires the size of the pre-posted buffer to be sufficiently large so that it may accept whatever data was sent. Generally a default size can be chosen, such as the Maximum Transfer Unit (MTU) of the network. An overflow of the pre-posted buffer will result in an error and a request to resend the data, delaying processing of the data. As an alternative, a default size smaller than the MTU could be chosen, decreasing the amount of resources used, but increasing the number of overflows and resend requests, and thereby decreasing the overall speed of the system.
- In an RPC context, there can exist non-RPC communication. A non-RPC communication is a communication in which at least one of the two parties has no receive operation following its send operation. In such a case, the optimized flow control may not be applicable, because the total number of messages is not an even number. One example of such a non-RPC communication is an authentication between a client and a server. Authentication can be of the form: request by client, challenge with counter-challenge by server, and response by client. This sequence of three messages can be made to maintain RPC semantics by simply adding a fourth message back to the client from the server. Alternatively, the client's first method call can be combined with the third authentication message, the response by the client, so that one message accomplishes both functions, and an even number of messages is maintained.
-
FIG. 8 illustrates a steady-state situation in the implicit flow control case. Initially, theserver computer 72 can post a receive buffer so that it may be able to receive a message from theclient computer 70. InFIG. 8 , it is assumed that the receive buffer used atstep 236 was posted in a prior sequence. Therefore, beginning withstep 230, theclient computer 70 pre-posts a receive buffer. Once theclient computer 70 has posted the receive buffer, it can send its request to the server. Thus, atstep 232, the client sendsdata 234 to the server. The server, atstep 236, places thedata 234 into the receive buffer that was posted during an earlier cycle, as described above. Atstep 238, theserver computer 72 can perform the work requested by the client. Atstep 240, prior to sending the response to the client, the server can pre-post a receive buffer. Once the receive buffer is posted, atstep 242 theserver computer 72 can send to theclient computer 70data 244, which can be placed by the client in the receive buffer atstep 246. The receive buffer into which the response is placed atstep 246 is the receive buffer which was posted atstep 230. The sending ofdata 234 to the server was an implicit OK TO SEND from the client to the server. Thus, atstep 242, the server could send theresponse data 244 without waiting for an explicit OK TO SEND. - As explained above, an explicit flow control system reduces the efficiency of the overall system by requiring each computer to idle while waiting for an explicit OK TO SEND flow control message. The implicit flow control of the present invention can improve the system efficiency by reducing the amount of time each computer idles waiting for explicit flow control messages. As can be seen with reference to
FIG. 8 , when theserver computer 72 has finished its computations atstep 238, it is ready to send theresponse data 244 to theclient computer 70. Theserver 72 need not wait for an explicit flow control message. Rather, it can senddata 244 as soon as it has pre-posted the receivebuffer 240. Thus, the amount of time between the completion of work atstep 238 and the sending of the response atstep 242 is minimized. Theclient computer 70, therefore, receives a result from theserver 72 in less time than in the known explicit flow control environment. - As will be known by those skilled in the art, in addition to posting receive buffers, each computer can clear those buffers once the data stored therein is no longer needed by the computer. In such a manner the same physical memory of a computer can be reused, ensuring that communication can continue indefinitely. Furthermore, as is also known by those of skill in the art, the sending of data from one computer to another, such as the send operations in
steps FIG. 8 , requires that thedata - In the known explicit flow control, the client and the server could clear the buffers while waiting for an explicit OK TO SEND message. The present invention, however, provides greater flexibility with respect to the timing of the clear send buffer and clear receive buffer operations. Those operations can be delayed so that a computer can receive a request, perform work, and return a result in the least amount of time, thereby increasing the overall efficiency of the system.
FIG. 9 illustrates the sequence of the buffer clearing operations, as contemplated by the present invention. As withFIG. 8 ,FIG. 9 illustrates a steady-state system. The index shown inFIG. 9 indicates the round of communication between the client and server computers. BecauseFIG. 9 illustrates a steady-state system, which can exist at any time, the index n is used to indicate any integer. Thus, the receive buffer posted atstep 250 will receive the nth response from the server computer. As will be described later, atstep 268 the client computer pre-posts a receive buffer which will receive the next response from the server, or the n+1th response. - As described in detail above, the implicit flow control of the present invention contemplates that the receive buffers can be posted prior to the sending of any data, so that the sending of the data itself is the implicit OK TO SEND message to the other computer. Thus, prior to sending the nth request at
step 252, theclient computer 70 pre-posts the receive buffer atstep 250 to accept the response to the nth request: the nth response. Atstep 251 theclient 70 performs the work which necessitates the request to theserver 72. The client can then send the request atstep 252 asdata 254. Atstep 256, theserver computer 72 receives thedata 254 into a receive buffer which was posted during an earlier cycle, not shown. As can be seen from the figure, prior to the receipt of the nth request from the client atstep 256, the server computer cleared, atstep 253, the receive buffer from the request prior to the nth request, the n−1th request. Similarly, atstep 255, theserver computer 72 cleared the send buffer from the n−1th reply. Therefore, the buffers which are cleared are those from the round of communication prior to the current round. - At
step 258, the server does work on the request, and atstep 260, the server pre-posts the receive buffer for the coming request, the n+1th request. Atstep 262 the server sends the response to the request of the current round, the nth round, and that is received by the client atstep 266 into the receive buffer which was posted atstep 250. While theserver computer 72 was performing work atstep 258, theclient computer 70 cleared the receive buffer from the prior round, the n−1th round instep 261 and cleared the send buffer from the prior round instep 263, as shown inFIG. 9 . Similarly, after theserver 72 sent the response atstep 262, it cleared the receive buffer atstep 267 and the send buffer atstep 274. The send buffer cleared instep 274 was the buffer used to send the response instep 262. - The cycle of pre-post receive buffer, perform work, send request or reply, clean up receive, clean up send, and receive reply or request repeats itself for each request and response cycle. A second cycle is illustrated in
FIG. 9 , assteps 268 through 285. The second cycle reveals that the clean up operations are interleaved with the send and receive operations, and trail by one round. For example, the buffer pre-posted atstep 250 by the client receives data atstep 266 and is cleared atstep 279. Similarly, the send buffer used by the client atstep 252 is cleaned up atstep 281. On the server side, the buffer into which data was received atstep 256 is cleared instep 267. Also on the server, the receive buffer that was pre-posted instep 260 received data instep 276, and the send operation instep 262 was cleaned up instep 274. - Because the implicit flow control of the present invention allows the clean up operations to be flexibly timed, they can be scheduled to take place during the time in which the computer is waiting for a response. For example, when the
client computer 70 sends the request atstep 252, it may not be able to do substantive work until it receives a reply atstep 266. Therefore, scheduling buffer clearing operations, such as those atsteps step server 72 can decrease the time the client may be waiting for a response by decreasing the time betweenstep 256 when it receives a request, and step 262 when it sends the response. Thus, in the interim, theserver 72 only performs the work requested by the client, atstep 258, and preposts the receive buffer atstep 260, as contemplated by the implicit flow control of the present invention. Theserver 72 can then clear its buffers afterstep 262 when the client may no longer be waiting for it to respond to the client's request. As can be seen, by scheduling the clearing of the send and receive buffers outside of the receive operation and the responding send operation cycle, the overall efficiency of the system can be increased by decreasing the time each computer waits for the other to respond. - The present invention provides three mechanisms for enhancing the speed of DCOM over a network. At the application level, copying is reduced by using an array of pointers rather than the values themselves and taking advantage of the network interface card's ability to do scatter-gather. The duplication of effort between the RPC runtime and the DCOM runtime is eliminated by removing the dispatching of the RPC runtime layer. Finally, at the transport level, the flow control is accelerated by switching to an implicit flow control, and scheduling the clear buffers commands outside of the critical time to reduce idle. Each of the three mechanisms can be used by themselves or in any combination to achieve a speed increase over the prior art.
- All of the references cited herein, including patents, patent applications, and publications, are hereby incorporated in their entireties by reference.
- In view of the many possible embodiments to which the principles of this invention may be applied, it should be recognized that the embodiment described herein with respect to the drawing figures is meant to be illustrative only and should not be taken as limiting the scope of invention. For example, those of skill in the art will recognize that the elements of the illustrated embodiment shown in software may be implemented in hardware and vice versa or that the illustrated embodiment can be modified in arrangement and detail without departing from the spirit of the invention. Therefore, the invention as described herein contemplates all such embodiments as may come within the scope of the following claims and equivalents thereof.
Claims (20)
1. A method of communication between a first object located on a first computer and a second object located on a second computer, the second computer having a memory storage location and a buffer, the first and second computers connected by a network, accessed by the second computer through a network interface card on the second computer, the method comprising:
receiving a call from the first object on an interface of the second object;
receiving, by the network interface card, a parameter of the call from the first object;
storing the parameter in a memory location; and
accessing, by the second object, the parameter.
2. The method of claim 1 wherein the memory location is the buffer.
3. The method of claim 2 wherein the accessing the parameter is performed in the buffer.
4. The method of claim 2 further comprising copying the parameter from the buffer into the memory storage location, wherein the accessing the parameter is performed in the memory storage location.
5. The method of claim 1 wherein the memory location is the memory storage location, and wherein the accessing the parameter is performed in the memory storage location.
6. The method of claim 1 wherein the receiving comprises: storing, on the second computer, a second data into a first receive buffer, wherein the first receive buffer is posted prior to sending a first data to the first computer.
7. The method of claim 6 wherein the first data to the first computer is sent prior to receiving the second data from the first computer.
8. The method of claim 6 wherein the receiving further comprises: cleaning up, on the second computer, a send buffer after sending the first data to the first computer and prior to receiving the second data from the first computer.
9. The method of claim 8 wherein the send buffer is used to send the first data to the first computer.
10. The method of claim 6 wherein the receiving further comprises: cleaning up, on the second computer, a second receive buffer after sending the first data to the first computer and prior to receiving the second data from the first computer.
11. A computer-readable medium having computer-executable instructions for performing steps for communicating between a first object located on a first computer and a second object located on a second computer, the second computer having a memory storage location and a buffer, the first and second computers connected by a network, accessed by the second computer through a network interface card on the second computer, the steps comprising:
receiving a call from the first object on an interface of the second object;
receiving, by the network interface card, a parameter of the call from the first object;
storing the parameter in a memory location; and
accessing, by the second object, the parameter.
12. The computer-readable medium of claim 11 wherein the memory location is the buffer.
13. The computer-readable medium of claim 12 wherein the accessing the parameter is performed in the buffer.
14. The computer-readable medium of claim 12 having further computer-executable instructions for performing steps comprising: copying the parameter from the buffer into the memory storage location, wherein the accessing the parameter is performed in the memory storage location.
15. The computer-readable medium of claim 11 wherein the memory location is the memory storage location, and wherein the accessing the parameter is performed in the memory storage location.
16. The computer-readable medium of claim 11 wherein the receiving comprises: storing, on the second computer, a second data into a first receive buffer, wherein the first receive buffer was posted prior to sending a first data to the first computer.
17. The computer-readable medium of claim 16 wherein the first data to the first computer is sent prior to receiving the second data from the first computer.
18. The computer-readable medium of claim 16 wherein the receiving further comprises: cleaning up, on the second computer, a send buffer after sending the first data to the first computer and prior to receiving the second data from the first computer.
19. The computer-readable medium of claim 18 wherein the send buffer is used to send the first data to the first computer.
20. The computer-readable medium of claim 20 wherein the receiving further comprises: cleaning up, on the second computer, a second receive buffer after sending the first data to the first computer and prior to receiving the second data from the first computer.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/966,508 US20050071857A1 (en) | 1998-12-11 | 2004-10-14 | Accelerating a distributed component architecture over a network using a direct marshaling |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11178898P | 1998-12-11 | 1998-12-11 | |
US09/458,139 US6826763B1 (en) | 1998-12-11 | 1999-12-09 | Accelerating a distributed component architecture over a network using a direct marshaling |
US10/966,508 US20050071857A1 (en) | 1998-12-11 | 2004-10-14 | Accelerating a distributed component architecture over a network using a direct marshaling |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/458,139 Continuation US6826763B1 (en) | 1998-12-11 | 1999-12-09 | Accelerating a distributed component architecture over a network using a direct marshaling |
Publications (1)
Publication Number | Publication Date |
---|---|
US20050071857A1 true US20050071857A1 (en) | 2005-03-31 |
Family
ID=22340460
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/458,139 Expired - Lifetime US6826763B1 (en) | 1998-12-11 | 1999-12-09 | Accelerating a distributed component architecture over a network using a direct marshaling |
US09/458,138 Expired - Lifetime US6708223B1 (en) | 1998-12-11 | 1999-12-09 | Accelerating a distributed component architecture over a network using a modified RPC communication |
US10/762,804 Expired - Fee Related US7624398B2 (en) | 1998-12-11 | 2004-01-22 | Accelerating a distributed component architecture over a network using a modified RPC communication |
US10/966,508 Abandoned US20050071857A1 (en) | 1998-12-11 | 2004-10-14 | Accelerating a distributed component architecture over a network using a direct marshaling |
Family Applications Before (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/458,139 Expired - Lifetime US6826763B1 (en) | 1998-12-11 | 1999-12-09 | Accelerating a distributed component architecture over a network using a direct marshaling |
US09/458,138 Expired - Lifetime US6708223B1 (en) | 1998-12-11 | 1999-12-09 | Accelerating a distributed component architecture over a network using a modified RPC communication |
US10/762,804 Expired - Fee Related US7624398B2 (en) | 1998-12-11 | 2004-01-22 | Accelerating a distributed component architecture over a network using a modified RPC communication |
Country Status (3)
Country | Link |
---|---|
US (4) | US6826763B1 (en) |
AU (3) | AU3115600A (en) |
WO (3) | WO2000034883A2 (en) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050240696A1 (en) * | 2004-01-22 | 2005-10-27 | Seiko Epson Corporation | Data transfer control device and electronic instrument |
US20060029036A1 (en) * | 2004-05-21 | 2006-02-09 | Paul Gassoway | Method and apparatus for remote management |
US20090064207A1 (en) * | 2007-08-31 | 2009-03-05 | Ron Sigal | Multiplex transport |
US8555297B1 (en) * | 2008-09-29 | 2013-10-08 | Emc Corporation | Techniques for performing a remote procedure call using remote procedure call configuration information |
Families Citing this family (87)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7266725B2 (en) | 2001-09-03 | 2007-09-04 | Pact Xpp Technologies Ag | Method for debugging reconfigurable architectures |
US6542998B1 (en) | 1997-02-08 | 2003-04-01 | Pact Gmbh | Method of self-synchronization of configurable elements of a programmable module |
US8686549B2 (en) * | 2001-09-03 | 2014-04-01 | Martin Vorbach | Reconfigurable elements |
DE19861088A1 (en) | 1997-12-22 | 2000-02-10 | Pact Inf Tech Gmbh | Repairing integrated circuits by replacing subassemblies with substitutes |
AU3115600A (en) * | 1998-12-11 | 2000-06-26 | Microsoft Corporation | Accelerating a distributed component architecture over a network using a direct marshaling |
US7003660B2 (en) | 2000-06-13 | 2006-02-21 | Pact Xpp Technologies Ag | Pipeline configuration unit protocols and communication |
DE10081643D2 (en) * | 1999-06-10 | 2002-05-29 | Pact Inf Tech Gmbh | Sequence partitioning on cell structures |
US9785140B2 (en) | 2000-02-01 | 2017-10-10 | Peer Intellectual Property Inc. | Multi-protocol multi-client equipment server |
US8028049B1 (en) | 2000-02-01 | 2011-09-27 | Peer Intellectual Property Inc. | Apparatus and method for web-based tool management |
US7403984B2 (en) * | 2000-02-01 | 2008-07-22 | Asyst Technologies, Inc. | Automated tool management in a multi-protocol environment |
US7873428B2 (en) * | 2005-04-15 | 2011-01-18 | PEER Intellectual Property, Inc. | Automated job management |
DE10038562B4 (en) * | 2000-08-03 | 2005-12-15 | Siemens Ag | System and method for transmitting data over data networks with data conversion by a COM car sounder |
US7207046B1 (en) * | 2000-08-23 | 2007-04-17 | Agilent Technologies, Inc. | Method and system for providing string-over-socket scripting language access to distributed object model interfaces |
DE10134228B4 (en) * | 2000-08-25 | 2007-12-13 | International Business Machines Corp. | Method and system for improving remote function calls |
US6944827B2 (en) * | 2000-09-11 | 2005-09-13 | Appeon Corporation | System and method of data transmission for computer networks utilizing HTTP |
US8058899B2 (en) | 2000-10-06 | 2011-11-15 | Martin Vorbach | Logic cell array and bus system |
US7197565B2 (en) * | 2001-01-22 | 2007-03-27 | Sun Microsystems, Inc. | System and method of using a pipe advertisement for a peer-to-peer network entity in peer-to-peer presence detection |
WO2002057917A2 (en) * | 2001-01-22 | 2002-07-25 | Sun Microsystems, Inc. | Peer-to-peer network computing platform |
US7165107B2 (en) * | 2001-01-22 | 2007-01-16 | Sun Microsystems, Inc. | System and method for dynamic, transparent migration of services |
US7024479B2 (en) * | 2001-01-22 | 2006-04-04 | Intel Corporation | Filtering calls in system area networks |
US6944643B1 (en) | 2001-01-30 | 2005-09-13 | Sprint Communications Company L.P. | Method for deployment modification of transactional behavior in corba OTS |
US7444531B2 (en) | 2001-03-05 | 2008-10-28 | Pact Xpp Technologies Ag | Methods and devices for treating and processing data |
US6986147B2 (en) * | 2001-03-28 | 2006-01-10 | International Business Machines Corporation | Method for transparent, location-independent, remote procedure calls in a heterogeneous network environment |
US7028313B2 (en) * | 2001-03-28 | 2006-04-11 | International Business Machines Corporation | Method for transmitting function parameters to a remote node for execution of the function thereon |
US7319979B2 (en) * | 2001-03-29 | 2008-01-15 | Intel Corporation | Dynamically interacting with an internet service using a client-specified communication proxy and protocol |
WO2002084499A1 (en) * | 2001-04-11 | 2002-10-24 | Chelsio Communications, Inc. | Multi-purpose switching network interface controller |
US7272636B2 (en) * | 2001-04-24 | 2007-09-18 | Sun Microsystems, Inc. | Peer group name server |
US20020174169A1 (en) * | 2001-05-21 | 2002-11-21 | Schmid Hans Albrecht | Process for operating a distributed computer network comprising several distributed computers |
US7756963B2 (en) * | 2001-07-05 | 2010-07-13 | PEER Intellectual Property, Inc. | Automated tool management in a multi-protocol environment |
US7996827B2 (en) | 2001-08-16 | 2011-08-09 | Martin Vorbach | Method for the translation of programs for reconfigurable architectures |
US8686475B2 (en) * | 2001-09-19 | 2014-04-01 | Pact Xpp Technologies Ag | Reconfigurable elements |
EP1483682A2 (en) | 2002-01-19 | 2004-12-08 | PACT XPP Technologies AG | Reconfigurable processor |
ATE402446T1 (en) * | 2002-02-18 | 2008-08-15 | Pact Xpp Technologies Ag | BUS SYSTEMS AND RECONFIGURATION PROCEDURES |
US20110161977A1 (en) * | 2002-03-21 | 2011-06-30 | Martin Vorbach | Method and device for data processing |
US8914590B2 (en) | 2002-08-07 | 2014-12-16 | Pact Xpp Technologies Ag | Data processing method and device |
US7035845B2 (en) * | 2002-05-15 | 2006-04-25 | Microsoft Corporation | Generic proxy for representing search engine partner |
US20030217191A1 (en) * | 2002-05-20 | 2003-11-20 | Yang Gao | System and method for converting the UI logic of a windows software application to run within a web browser |
US7234137B2 (en) * | 2002-07-25 | 2007-06-19 | Sun Microsystems, Inc. | Method, system, and program for processing objects in a distributed computing environment |
US7657861B2 (en) | 2002-08-07 | 2010-02-02 | Pact Xpp Technologies Ag | Method and device for processing data |
US7849140B2 (en) * | 2002-08-29 | 2010-12-07 | Oracle America, Inc. | Peer-to-peer email messaging |
US7263560B2 (en) * | 2002-08-30 | 2007-08-28 | Sun Microsystems, Inc. | Decentralized peer-to-peer advertisement |
AU2003289844A1 (en) | 2002-09-06 | 2004-05-13 | Pact Xpp Technologies Ag | Reconfigurable sequencer structure |
US7353521B1 (en) * | 2002-10-19 | 2008-04-01 | Borland Software Corporation | Object oriented distributed software system with methodology for piggybacked reflective callbacks |
US7911994B2 (en) * | 2003-02-28 | 2011-03-22 | Openwave Systems Inc. | Confirmation of delivery of content to an HTTP/TCP device |
US7200676B2 (en) | 2003-03-26 | 2007-04-03 | Microsoft Corporation | Transmitting and receiving messages through a customizable communication channel and programming model |
EP1611528A2 (en) * | 2003-04-04 | 2006-01-04 | PACT XPP Technologies AG | Method and device for data processing |
US7937694B2 (en) * | 2004-02-13 | 2011-05-03 | Microsoft Corporation | Fast flattening of nested streams |
US7694335B1 (en) * | 2004-03-09 | 2010-04-06 | Cisco Technology, Inc. | Server preventing attacks by generating a challenge having a computational request and a secure cookie for processing by a client |
US7945705B1 (en) * | 2004-05-25 | 2011-05-17 | Chelsio Communications, Inc. | Method for using a protocol language to avoid separate channels for control messages involving encapsulated payload data messages |
US20060070067A1 (en) * | 2004-06-03 | 2006-03-30 | Dell Products L.P. | Method of using scavenger grids in a network of virtualized computers |
US7640346B2 (en) * | 2005-02-01 | 2009-12-29 | Microsoft Corporation | Dispatching network connections in user-mode |
US7882236B2 (en) | 2005-02-04 | 2011-02-01 | Microsoft Corporation | Communication channel model |
US20060282523A1 (en) * | 2005-06-09 | 2006-12-14 | Frank Earl | System and method for non-obtrusive monitoring and control of remote services and control gateways |
US7660306B1 (en) | 2006-01-12 | 2010-02-09 | Chelsio Communications, Inc. | Virtualizing the operation of intelligent network interface circuitry |
US7724658B1 (en) | 2005-08-31 | 2010-05-25 | Chelsio Communications, Inc. | Protocol offload transmit traffic management |
US7715436B1 (en) | 2005-11-18 | 2010-05-11 | Chelsio Communications, Inc. | Method for UDP transmit protocol offload processing with traffic management |
US7616563B1 (en) | 2005-08-31 | 2009-11-10 | Chelsio Communications, Inc. | Method to implement an L4-L7 switch using split connections and an offloading NIC |
US7660264B1 (en) | 2005-12-19 | 2010-02-09 | Chelsio Communications, Inc. | Method for traffic schedulign in intelligent network interface circuitry |
US7760733B1 (en) | 2005-10-13 | 2010-07-20 | Chelsio Communications, Inc. | Filtering ingress packets in network interface circuitry |
US7676811B2 (en) | 2006-03-23 | 2010-03-09 | Microsoft Corporation | Ensuring thread affinity for interprocess communication in a managed code environment |
US8332866B2 (en) * | 2006-11-29 | 2012-12-11 | Qualcomm Incorporated | Methods, systems, and apparatus for object invocation across protection domain boundaries |
US7706266B2 (en) | 2007-03-12 | 2010-04-27 | Citrix Systems, Inc. | Systems and methods of providing proxy-based quality of service |
US8935406B1 (en) | 2007-04-16 | 2015-01-13 | Chelsio Communications, Inc. | Network adaptor configured for connection establishment offload |
US8035401B2 (en) | 2007-04-18 | 2011-10-11 | Cypress Semiconductor Corporation | Self-calibrating driver for charging a capacitive load to a desired voltage |
US7826350B1 (en) | 2007-05-11 | 2010-11-02 | Chelsio Communications, Inc. | Intelligent network adaptor with adaptive direct data placement scheme |
US8589587B1 (en) | 2007-05-11 | 2013-11-19 | Chelsio Communications, Inc. | Protocol offload in intelligent network adaptor, including application level signalling |
US8060644B1 (en) | 2007-05-11 | 2011-11-15 | Chelsio Communications, Inc. | Intelligent network adaptor with end-to-end flow control |
US7831720B1 (en) | 2007-05-17 | 2010-11-09 | Chelsio Communications, Inc. | Full offload of stateful connections, with partial connection offload |
WO2009062496A1 (en) * | 2007-11-17 | 2009-05-22 | Pact Xpp Technologies Ag | Reconfigurable floating-point and bit level data processing unit |
US20110173596A1 (en) * | 2007-11-28 | 2011-07-14 | Martin Vorbach | Method for facilitating compilation of high-level code for varying architectures |
US20110119657A1 (en) * | 2007-12-07 | 2011-05-19 | Martin Vorbach | Using function calls as compiler directives |
CN101609416B (en) * | 2009-07-13 | 2012-11-14 | 清华大学 | Method for improving performance tuning speed of distributed system |
US8359588B2 (en) * | 2009-11-25 | 2013-01-22 | Arm Limited | Reducing inter-task latency in a multiprocessor system |
US9021510B2 (en) * | 2009-12-04 | 2015-04-28 | International Business Machines Corporation | Remote procedure call (RPC) bind service with physical interface query and selection |
US9003377B2 (en) * | 2010-01-07 | 2015-04-07 | Microsoft Technology Licensing, Llc | Efficient resumption of co-routines on a linear stack |
US8495601B2 (en) * | 2010-06-09 | 2013-07-23 | Lear Corporation | Shared memory architecture |
US9131011B1 (en) | 2011-08-04 | 2015-09-08 | Wyse Technology L.L.C. | Method and apparatus for communication via fixed-format packet frame |
US8701130B2 (en) * | 2012-06-26 | 2014-04-15 | Teradyne, Inc. | Implementing remote procedure calls |
US9092281B2 (en) | 2012-10-02 | 2015-07-28 | Qualcomm Incorporated | Fast remote procedure call |
US9338193B2 (en) | 2013-05-31 | 2016-05-10 | International Business Machines Corporation | Remote procedure call with call-by-reference semantics using remote direct memory access |
US9602329B1 (en) * | 2013-08-30 | 2017-03-21 | Instantcal, Inc. | Dynamic remote procedure call |
US9680918B2 (en) * | 2014-06-30 | 2017-06-13 | Fortinet, Inc. | Socket application program interface (API) for efficient data transactions |
CN106254888B (en) * | 2015-06-09 | 2020-06-02 | 同济大学 | Image encoding and decoding method and image processing equipment |
US11025752B1 (en) | 2015-07-20 | 2021-06-01 | Chelsio Communications, Inc. | Method to integrate co-processors with a protocol processing pipeline |
CN110768928B (en) * | 2018-07-25 | 2022-01-25 | 北京嘀嘀无限科技发展有限公司 | Communication method and communication device, computer equipment and readable storage medium |
CN109683991B (en) * | 2018-12-28 | 2022-05-27 | 广东亿迅科技有限公司 | Method and device for rapidly acquiring large amount of equipment information through multiple strategies |
US10880331B2 (en) * | 2019-11-15 | 2020-12-29 | Cheman Shaik | Defeating solution to phishing attacks through counter challenge authentication |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5386566A (en) * | 1991-03-20 | 1995-01-31 | Hitachi, Ltd. | Inter-processor communication method for transmitting data and processor dependent information predetermined for a receiving process of another processor |
US5724588A (en) * | 1992-11-13 | 1998-03-03 | Microsoft Corporation | Method and system for network marshalling of interface pointers for remote procedure calls |
US6044409A (en) * | 1996-06-26 | 2000-03-28 | Sun Microsystems, Inc. | Framework for marshaling and unmarshaling argument object references |
US6131126A (en) * | 1994-07-22 | 2000-10-10 | Sun Microsystems, Inc. | Method and apparatus for space-efficient inter-process communication |
US6708223B1 (en) * | 1998-12-11 | 2004-03-16 | Microsoft Corporation | Accelerating a distributed component architecture over a network using a modified RPC communication |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3473975B2 (en) | 1993-09-08 | 2003-12-08 | 株式会社日立製作所 | Network system and communication method in network |
US5954794A (en) * | 1995-12-20 | 1999-09-21 | Tandem Computers Incorporated | Computer system data I/O by reference among I/O devices and multiple memory units |
-
1999
- 1999-12-09 AU AU31156/00A patent/AU3115600A/en not_active Abandoned
- 1999-12-09 US US09/458,139 patent/US6826763B1/en not_active Expired - Lifetime
- 1999-12-09 WO PCT/US1999/029238 patent/WO2000034883A2/en active Application Filing
- 1999-12-09 US US09/458,138 patent/US6708223B1/en not_active Expired - Lifetime
- 1999-12-09 AU AU18433/00A patent/AU1843300A/en not_active Abandoned
- 1999-12-09 WO PCT/US1999/029158 patent/WO2000034857A2/en active Application Filing
- 1999-12-09 WO PCT/US1999/029223 patent/WO2000034858A2/en active Application Filing
- 1999-12-09 AU AU31163/00A patent/AU3116300A/en not_active Abandoned
-
2004
- 2004-01-22 US US10/762,804 patent/US7624398B2/en not_active Expired - Fee Related
- 2004-10-14 US US10/966,508 patent/US20050071857A1/en not_active Abandoned
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5386566A (en) * | 1991-03-20 | 1995-01-31 | Hitachi, Ltd. | Inter-processor communication method for transmitting data and processor dependent information predetermined for a receiving process of another processor |
US5724588A (en) * | 1992-11-13 | 1998-03-03 | Microsoft Corporation | Method and system for network marshalling of interface pointers for remote procedure calls |
US6131126A (en) * | 1994-07-22 | 2000-10-10 | Sun Microsystems, Inc. | Method and apparatus for space-efficient inter-process communication |
US6044409A (en) * | 1996-06-26 | 2000-03-28 | Sun Microsystems, Inc. | Framework for marshaling and unmarshaling argument object references |
US6708223B1 (en) * | 1998-12-11 | 2004-03-16 | Microsoft Corporation | Accelerating a distributed component architecture over a network using a modified RPC communication |
US20040154028A1 (en) * | 1998-12-11 | 2004-08-05 | Microsoft Corporation | Accelerating a distributed component architecture over a network using a modified RPC communication |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050240696A1 (en) * | 2004-01-22 | 2005-10-27 | Seiko Epson Corporation | Data transfer control device and electronic instrument |
US20060029036A1 (en) * | 2004-05-21 | 2006-02-09 | Paul Gassoway | Method and apparatus for remote management |
US7895344B2 (en) * | 2004-05-21 | 2011-02-22 | Computer Associates Think, Inc. | Method and apparatus for remote management |
US20090064207A1 (en) * | 2007-08-31 | 2009-03-05 | Ron Sigal | Multiplex transport |
US8260934B2 (en) * | 2007-08-31 | 2012-09-04 | Red Hat, Inc. | Multiplex transport |
US8555297B1 (en) * | 2008-09-29 | 2013-10-08 | Emc Corporation | Techniques for performing a remote procedure call using remote procedure call configuration information |
Also Published As
Publication number | Publication date |
---|---|
AU3115600A (en) | 2000-06-26 |
US6826763B1 (en) | 2004-11-30 |
US6708223B1 (en) | 2004-03-16 |
US20040154028A1 (en) | 2004-08-05 |
WO2000034857A2 (en) | 2000-06-15 |
WO2000034858A3 (en) | 2000-09-08 |
AU3116300A (en) | 2000-06-26 |
WO2000034858A2 (en) | 2000-06-15 |
WO2000034883A3 (en) | 2000-08-10 |
WO2000034883A2 (en) | 2000-06-15 |
AU1843300A (en) | 2000-06-26 |
WO2000034857A3 (en) | 2000-08-10 |
US7624398B2 (en) | 2009-11-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6826763B1 (en) | Accelerating a distributed component architecture over a network using a direct marshaling | |
Johnson et al. | The Peregrine high‐performance RPC system | |
Watson et al. | Gaining efficiency in transport services by appropriate design and implementation choices | |
Birrell et al. | Implementing remote procedure calls | |
US8205007B2 (en) | Native format tunneling | |
Ritchie | The UNIX System: A Stream Input‐Output System | |
US7028091B1 (en) | Web server in-kernel interface to data transport system and cache manager | |
US8839267B2 (en) | Method and middleware for efficient messaging on clusters of multi-core processors | |
US5805823A (en) | System and method for optimal multiplexed message aggregation between client applications in client-server networks | |
US20030097401A1 (en) | Method for determining on demand right size buffering within a socket server implementation | |
US6163812A (en) | Adaptive fast path architecture for commercial operating systems and information server applications | |
US20050071316A1 (en) | Method and apparatus for creating, sending, and using self-descriptive objects as messages over a message queuing network | |
US6993769B2 (en) | System and method for replacing underlying connection-based communication mechanisms in real time systems at run-time | |
JP2000020490A (en) | Computer having remote procedure calling mechanism or object request broker mechanism, data transfer method and transfer method storage medium | |
US7536468B2 (en) | Interface method, system, and program product for facilitating layering of a data communications protocol over an active message layer protocol | |
Seth et al. | TCP/IP architecture, design, and implementation in Linux | |
Hayton et al. | Flexinet open orb framework | |
Cooper | An argument for soft layering of protocols | |
US6718399B1 (en) | Communications on a network | |
Brightwell et al. | The Portals 4.3 Network Programming Interface | |
Tanenbaum et al. | The Amoeba Microkennel | |
Hong | Communication abstractions for distributed systems | |
Deering | Multi-process structuring of X. 25 software | |
Lewandowski | Interprocess communication in UNIX and Windows NT | |
Stoess | Porting LibRIPC to iWARP |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034766/0001 Effective date: 20141014 |