WO1994001832A1 - Appareil et procede permettant la communication inter-processus a base de messages et axee sur le service dans un systeme informatique en reseau - Google Patents

Appareil et procede permettant la communication inter-processus a base de messages et axee sur le service dans un systeme informatique en reseau Download PDF

Info

Publication number
WO1994001832A1
WO1994001832A1 PCT/US1993/006398 US9306398W WO9401832A1 WO 1994001832 A1 WO1994001832 A1 WO 1994001832A1 US 9306398 W US9306398 W US 9306398W WO 9401832 A1 WO9401832 A1 WO 9401832A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
connection
vreturncode
server
vfd
Prior art date
Application number
PCT/US1993/006398
Other languages
English (en)
Inventor
Steven Schwell
Original Assignee
Systems Strategies, Inc.
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Systems Strategies, Inc. filed Critical Systems Strategies, Inc.
Priority to AU46673/93A priority Critical patent/AU4667393A/en
Publication of WO1994001832A1 publication Critical patent/WO1994001832A1/fr

Links

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/546—Message passing systems or structures, e.g. queues

Definitions

  • the invention involves an apparatus and method for providing message-based interprocess communication resources in such networks wherein such resources are provided independently of whether they involve intra-machine or inter-machine data communication.
  • workstations thereby allowing workstation users to access and/or modify data created by other users on other workstations.
  • networked computing systems realize substantially better price/performance ratios than conventional, time-shared computing systems.
  • a drawback with networked systems is that application software which interacts with multiple users and/or workstations is substantially more difficult to create and maintain. In order to share data and/or
  • an application program executing in a networked system as a process on one host must communi.cate wi.th multi.ple other processes executing independently on other hosts.
  • a standard model for interprocess communication in a computer network is the so-called client-server model.
  • client and server are both processes running either on the same machine or on different machines within the network.
  • the server process once initiated, lays dormant waiting for communication from some client process requesting it to perform some service.
  • Client processes typically in response to some user-initiated event, engage the appropriate intra-machine or inter-machine
  • interprocess communication resources to send a message to a designated server process so as to request that the server process provide a particular service.
  • Such services might include, for example, reading or writing a file on the server's host system, providing a log in to the server's host system or executing a command for the client on the server's system.
  • the client process must be aware of the existence of the server and the particular services that it provides.
  • the client must initially contact the server to inquire about the availability of the desired service.
  • the server must contact the client confirming its willingness to provide the requested service.
  • Each layer may define a peer-to-peer protocol by which communications between entities at that layer operate.
  • transport level represents the lowest level in the OSI model which can provide an error-free communications path.
  • the layers up through and including the transport layer are often provided by the host's operating system, such as UNIX System V.
  • An application program executing as a process on a host workstation in a network will generally need to communicate both with processes executing on other hosts as well as other processes running on the same host workstation.
  • Data communications between two processes on the same host typically employ the interprocess communications facilities provided by the operating system of the host.
  • a STREAM is a essentially a linked list of modules, one end of which is designated the head and provides the user-kernel interface according to a desired protocol, and the other end of which is designated the driver and provides functionality essentially similar to traditional device drivers.
  • STREAM provides a bidirectional data connection between its head and driver.
  • Modules linked between the head and driver perform intermediate processing of data as it flows upstream (from driver to head) or downstream (from head to driver) .
  • These intermediate modules may be used, for example, to implement
  • STREAMS modules are
  • STREAMS modules consist of a "read” side to handle messages travelling upstream and a "write” side to handle messages travelling downstream. Each side may have a put procedure, which performs simple
  • transformations of the message then either passes the message on by executing the put procedure of the next side in the direction of traffic, or links the message onto its own queue for later processing.
  • a side may "reply" to a message by giving it to its other side for transmission in the opposite direction.
  • Each side may also have a service (or srv) procedure, which goes through a message queue of stored messages (usually those stored by its put procedure) and either passes them on or restores them.
  • the put procedure of a side is executed by the
  • previous side i.e., previous module in the STREAM
  • the service procedure of a side is executed by the STREAMS
  • a byte-based protocol data is transferred in units of bytes. If, as is typical, the data being sent involves more than a single byte, a byte-based communication protocol must send the data as a successive stream of individual bytes.
  • a message may be any length (constrained by some maximum length) and is sent and received as a block.
  • message-based protocols provide a higher level of functionality, particularly in situations where the message data includes multiple-byte data types such as
  • Transmitting multiple-byte data types across a byte-based data link requires that the multiple-byte data units be fractured into a stream of individual bytes.
  • a conformance problem may arise when such data is exchanged between different computers on a network because different computers order the bytes within multiple-byte words differently (e.g., big endien and little endien).
  • Simply fracturing multiple-byte data types and sending the message using a byte-based protocol will result in identical byte orderings on both machines, which may not be the desired result if the machines use different byte orderings.
  • TCP/IP, XNS and SNA are generally byte-based.
  • an application program would typically employ a message-based protocol to communicate with local operating system resources, it would generally be required to use a completely different byte-based protocol in order to communicate with resources at other locations in the network. This is undesirable.
  • the X11 system provides a graphical window service whereby a process may request that a window be opened on any particular workstation in a network; the process may then request that particular graphical information be displayed in any of its opened windows.
  • the advantage of the object oriented design in X11 is that it allows the application program to employ identical procedure calls (resources) to open windows and write graphical data to windows regardless of whether the window is displayed on the screen of the host workstation or that of another workstation in the network.
  • the X11 system and other similar systems in existence provide only a limited variety of resources. In X11, the resources provided relate to graphical user interfaces.
  • One object of the present invention is a
  • networked computing system capable of providing a wide variety of services in an object oriented manner.
  • Another object of the invention involves a method for providing a wide variety of services within a computer network in accordance with a client-server model.
  • Still anther object of the invention is a networked computing system wherein an applications programmer may specify communications tasks to be performed by an application program independently of whether such tasks involve local user-space to kernel-space communication, local user-space to user-space communication, remote user-space to kernel-space communication or remote user-space to user-space communication.
  • the present invention relates to a networked computing system wherein message-based data
  • the invention includes means for advertising the services provided by server processes and a means for connecting advertised services to client
  • the invention also relates to a method for constructing portable application programs for use in a networked environment.
  • the method involves
  • IPMC Inter-Process Message Communication
  • the object-oriented IPMC toolkit comprises multiple layers. Each layer employs the resources provided by the layer(s) below it.
  • the top (most abstract) layer in the IPMC toolkit is a service oriented layer. At this level, means are provided whereby a client process may request
  • connection to a particular service without specifying or identifying the server process which renders such service.
  • a database for, among other things, identifying the particular server process that provides a client requested service.
  • the database may also include various information about the nature of the service provided and, if necessary, the protocols used to engage such service.
  • routines associated with the service oriented layer are realized using
  • inter/intra-machine layer At this layer, a client process wishing to connect to a particular server must identify not only the desired server, but also the location (which host in the network) of the server process. Associated with the inter/ intra-machine level, each host in the network includes a persistent
  • IPMC agent process which may assist in establishing connections between client and server processes on different hosts.
  • the inter/intra-machine level provides means whereby a client process may request connection to a server process in a manner independent of whether the client and server processes are executing on the same workstation.
  • inter-machine layer routines are used by the inter/intra-machine layer to connect client and server processes on different workstations.
  • One important function of the inter-machine layer is to provide message-based data transfer between hosts. Since network protocols are frequently byte-based, providing message-based data transfer may involve an enveloping and de-enveloping step. Means are further provided at the inter-machine level for assuring conformance among the messages transferred between different machines without the necessity to impose a network-standard byte order.
  • the intra-machine level of the IPMC toolkit includes facilities for providing message-based communication between client and server processes executing on the same workstation.
  • processes are generally user-space processes, while the server processes can be either user-space
  • kernel-space processes such as device drivers.
  • Fig. 1 is a general diagram of a networked computing system operable in accordance with the present invention
  • Fig. 2 is a diagram illustrating various possible data connections between exemplary client and server processes in accordance with the invention
  • Fig. 3a shows the various means provided to a server process for performing data communication in accordance with the present invention
  • Fig. 3b shows the various means provided to a client process for performing data communication in accordance with the present invention
  • Fig. 4 shows a data format for messages sent in accordance with a preferred embodiment of the present invention
  • Fig. 5 shows the hierarchical, object-oriented organization a preferred embodiment, the IPMC toolkit, of the present invention
  • Fig. 6 is a diagram showing exemplary intra-machine connections of the type which can be
  • Fig. 7 is a flowchart depicting the operation of p-level advertising means 70;
  • Fig. 8 is a flowchart depicting the operation of p-level connection request means 80;
  • Fig. 9 is a flowchart depicting the operation of p-level connection acceptance means 90;
  • Fig. 10 is a flowchart depicting the operation of p-level connection rejection means 100;
  • Fig. 11 is a diagram showing exemplary inter-machine connections of the type which can be
  • Fig. 12 is a flowchart depicting the operation of t-level advertising means 120;
  • Fig. 13 is a flowchart depicting the operation of t-level connection request means 130;
  • Fig. 14 is a flowchart depicting the operation of t-level connection acceptance means 140;
  • Fig. 15 is a flowchart depicting the operation of t-level connection rejection means 150;
  • Fig. 16 is diagram showing exemplary inter-machine and intra-machine connections of the type which can be established employing the i-level
  • Fig. 17 is a flowchart depicting the operation of i-level advertising means 170.
  • Fig. 18 is a flowchart depicting the operation of i-level connection request means 180;
  • Fig. 19 is a flowchart depicting the operation of i-level connection acceptance means 190;
  • Fig. 20 is a flowchart depicting the operation of i-level connection rejection means 200;
  • Fig. 21 is a diagram showing exemplary inter-machine and intra-machine connections of the type which can be established employing the service oriented v-level resources of the IPMC toolkit;
  • Fig. 22 is a flowchart depicting the operation of v-level advertising means 220;
  • Fig. 23 is a flowchart depicting the operation of v-level connection request means 230;
  • Fig. 24 is a flowchart depicting the operation of v-level connection acceptance means 240;
  • Fig. 25 is a flowchart depicting the operation of v-level connection rejection means 250;
  • Fig. 26 is a flowchart depicting the operation of v-level, i-level, t-level and p-level connection closing means 260;
  • Combined Figs. 27a-c are a flowchart depicting the operation of the connection agent process 22;
  • Fi.g. 28 i.s a di.agram showing the structure of
  • STREAMS modules including envelope and conformance modules, in an exemplary inter-machine connection
  • Fig. 29 is a diagram showing the operation of the
  • FIG. 1 depicts an exemplary networked computing system of the type which could be used to practice the invention.
  • Processes executing within domain 11 may communicate in
  • Domain 11 includes a plurality of host workstations 12, each of which includes local connections 14 to a network 10, and a database 13, also linked to network 10 via a local connection 14. Domain 11 may be linked to other domains via internetwork connections 15.
  • a client process executing on any host 12 may request connection to any service provided by a process executing on any other host 12 within the domain.
  • Database 13 provides the location and identity of the server process which supplies a particular requested service.
  • the extent of domain 11 within a particular computer network essentially corresponds to that set of hosts 12 which may access the information provided by database 13. Access to such information is necessary to establish the
  • database 13 corresponds to a separate physical object, as depicted in Fig. 1. It is only necessary that similar database service be available to all hosts 12 within the domain 11. Therefore, database 13 may in fact be implemented as a process running on one of the hosts 12 or as several processes concurrently running on various hosts 12 within domain 11.
  • FIG. 2 shows how connections between client and server processes within a domain 11 may be achieved in accordance with the invention.
  • the figure shows two hosts 12 on which a variety of server processes 20 and client processes 21 are executing.
  • Intra-machine connections 23 are used to establish message-based data links between a client process 21 and a server process 20, both of which are executing on the same host 12.
  • Data transfer over such intra-machine connections typically employs the message-based communication facilities provided by the operating system of the workstation 12.
  • such data transfer employs the STREAMS mechanism of the UNIX operating system.
  • connections 24 between a client process 21 and a server process 20 executing on different hosts 12 employ the resources of a local agent process 22 on the destination host machine to establish the
  • An agent process 22 is associated with each host 12. Each agent process is used, when necessary, to help establish inter-machine
  • a preferred embodiment of the present invention uses STREAMS, as previously mentioned, for intra-machine connections and TCP/IP for inter-machine connections 24 between different UNIX hosts 12.
  • Establishing an inter-machine connection 24 from a client process 21 to a server process 20 involves the agent 22 on the destination (server's) workstation 12.
  • Agent 22 responsive to a communications request from the client, assembles a STREAM 23 between the
  • the STREAM provided by agent 22 includes, if necessary, STREAMS modules for performing conformance and/or enveloping, as will be described later.
  • Figs. 3a and 3b depict the various functions provided to client (Fig. 3a) and server (Fig. 3b) processes in accordance with the present invention.
  • Both server processes 20 and client processes 21 may employ message sending means
  • connection closing means 34 For use by server processes 20, the invention additionally provides advertising means 31, connection acceptance means 32 and connection rejection means 33.
  • a server process 20 may advertise its availability to perform a particular service by invoking advertising means 31, which will cause database 13 to maintain information reflecting the availability of the server process 20 to provide the designated service.
  • Such information will generally include the host workstation 12 on which server process 20 is executing and the formats of various data messages which may be exchanged if the service is invoked.
  • a client process 21 may invoke connection request means 37 to request establishment of a connection for message-based communication to a designated service.
  • the invention provides means for identifying the requested service and establishing the connection therewith.
  • connection request means 37 from the service-oriented application layer requires only identification of the desired service and not its provider (the server process) or its location, mode of delivery, etc. Calls to connection request means 37 from other layers may require specification of such additional information.
  • server process 20 may invoke connection acceptance means 32 to establish the connection and confirm such establishment to the client process 21 or connection rejection means 33 to refuse the connection and notify client process 21 of such refusal.
  • connection acceptance means 32 to establish the connection and confirm such establishment to the client process 21
  • connection rejection means 33 to refuse the connection and notify client process 21 of such refusal.
  • either the client 21 or the server 20 process may close the connection by invoking connection closing means 34.
  • connection closing means 34 receives the file
  • both client process 21 and service process 20 may employ message sending means 35 and message receiving means 36 to perform message-based data communication. Since connections are bidirectional, both message sending means 35 and message receiving means 36 utilize the same token to identify the connection.
  • a message 40 comprises a data part 41 and a protocol part 42. Both fields are of variable length.
  • Data part 41 comprises DataLength bytes of storage, organized as a string-of-bytes.
  • Data part 41 consists of only a single variable length data field 44.
  • Protocol part 42 comprises a fixed length type field 45 and a plurality of variable length data fields 46a-k.
  • the total length of protocol part 42 is ProtoLength bytes.
  • Type field 45 need not begin protocol part 42, but merely be associated therewith (i.e., field 45 can be offset from the beginning of protocol part 42).
  • type field 45 determines the boundaries and types of data fields
  • IPMC toolkit 50 is organized into three hierarchical levels.
  • the service oriented v-level 51 rests atop the hierarchy, providing the most abstract interface
  • Inter/ intra-machine connection oriented i-level 52 occupies the next position in the hierarchy and provides facilities, in the form of encapsulated procedures, to v-level 51 via interface 57.
  • the final level in the hierarchy comprises inter-machine connection oriented t-level 53 and intra-machine connection oriented p-level 54, both of which provide facilities, in the form of
  • Each level in the IPMC toolkit 50 provides a similar interface, in the form of set of encapsulated procedures, to the level above it. While the previous description of Figs. 3a-b concentrated on resources provided by the v-level 51 to applications programs, similar interfaces link i-level 52 with v-level 51, and t-level 53 and p-level 54 with i-level 52. That is, each of these interfaces provides the following resources: advertising means 31, connection
  • connection rejection means 33 connection rejection means 33
  • connection closing means 34 message sending means 35
  • message receiving means 36 connection requesting means 37.
  • interface 56 between the v-level 51 and the application program 55 only requires that the name of a particular service be designated in order to request a connection using connection request means 37.
  • a similar request issued to the i-level 52 via interface 57 would also require designation of the server process and the host on which the process executes.
  • such a request issued to the t-level 53 via interface 58 would imply that the designated server was not executing on the same host while issuing such a request to the p-level 54 via interface 59 would imply that both processes were, indeed, executing on the same host.
  • IPMC toolkit 50 Another aspect of the hierarchical organization of IPMC toolkit 50 is that the implementation of various features necessary to provide the
  • functionality of a particular interface may be encapsulated within the level providing such
  • resources which invoke the UNIX STREAMS mechanism are encapsulated largely within the intra-machine
  • connection oriented p-level 54 As another example, the code which provides for interaction with an agent process 22 in order to establish an inter-machine connection 24 is associated with the inter-machine connection oriented t-level 53.
  • IPMC resources depends on and utilizes the resources below.
  • the detai.led i.mplementati.on of all resources described, as well as others not described in detail, can be found in the annexed source code appendix.
  • FIG. 6 depicts exemplary connections which may be established
  • the p-level may be used to establish intra-machine connections 23 between client 21 and server 20 processes executing on the same host 12.
  • the p-level of the IPMC toolkit relies on UNIX STREAMS to provide resources for implementing the message-based connections 23 in accordance with a client- server model.
  • Resources provided by the p-level include: an advertising means 70 for advertising the availability of a server for intra-machine STREAMS connection thereto; a connection request means 80 for requesting a intra-machine STREAMS connection to an advertised server; a connection acceptance means 90 for establishing a requested bi-directional STREAMS connection to a server; and a connection rejection means 100 for allowing a server to refuse a requested intra-machine connection.
  • FIG. 7 depicts the operation of p-level advertising means 70.
  • Advertising means 70 corresponds to the C language function pAdvertise(pPathName) in the annexed source code appendix.
  • the readiness of a server to provide service to clients is advertised by the presence of a STREAM to the server attached to a designated file in the file system of the host 12. Accordingly, advertising means 70 is provided with the file (the pathname 71) to which the server's STREAM will be connected.
  • step 73 it is determined whether an appropriate file exists at pathname 71 and if not, such file is created in step 74.
  • Step 75 allocates a new STREAM which, of course, has two ends.
  • Advertising means 70 terminates by providing, to the invoking server process, the other end 72 of the allocated STREAM.
  • FIG. 8 depicts the operation of p-level connection request means 80.
  • Connection request means 80 corresponds to the C language function pConnect (pPathName) in the annexed source code appendix.
  • pConnect pPathName
  • connection request means 80 with the pathname 71 for the file at which the service has been advertised.
  • connection request means 80 opens the STREAMS pipe attached (in previous step 76) to pathname 71.
  • a new STREAMS pipe is allocated in step 83. This new pipe will provide the requested connection, if accepted.
  • One end of the newly allocated STREAMS pipe is sent to the server via the existing pipe (opened in step 82) in step 84.
  • Connection request means 80 terminates at step 85 by providing the other end of the newly allocated STREAMS pipe 81 to the client process.
  • FIG. 9 depicts the operation of p-level connection acceptance means 90.
  • Connection acceptance means 90 corresponds to the C language procedure pAccept (vServerFd) in the source code appendix.
  • server process 20 provides connection acceptance means 90 with the server end of the STREAMS pipe 72, the other end of which was previously attached to the file at pathname 71.
  • connection acceptance means 90 returns the file descriptor 91 for the server end of the newly accepted STREAMS connection between server 20 and client 21.
  • a server process 20 invokes connection rejection means 100 to flush and ignore the file descriptor previously sent in step 84 designating the
  • connection request means 80 to provide an additional request for connection, if desired.
  • FIG. 11 depicts an exemplary inter-machine connection 24 which may be established between a client process 21 and a server process 20 on different hosts 12 utilizing the t-level resources of the IPMC toolkit.
  • the t-level resources uti.li.ze TCP/IP to establish inter-machine, byte-based data connections.
  • a particular service is identified both by its name and by the host
  • TCP/IP (as well as most other internetwork protocols which might be used in accordance with alternative embodiments of the invention) is a byte- based protocol. "Enveloping" is required in order to preserve the message boundaries in the TCP/IP byte stream.
  • STREAMS envelope modules associated with both server 20 and client 21, in order to encapsulate and re-assemble messages sent across byte-based inter-machine connection 24.
  • the byte-based nature of TCP/IP inter-machine connections also gives rise to a conformance problem between unlike machines .
  • the invention further provides for STREAMS conformance modules at both ends of the byte-based inter-machine connection. Exemplary embodiments of STREAMS conformance and enveloping modules are discussed later. This section
  • IPMC toolkit The t-level resources discussed below include, as with the p-level, an advertising means 120
  • FIG. 12 a connection request means 130 (Fig. 13), a connection acceptance means 140 (Fig. 14), and a connection rejection means 150 (Fig. 15).
  • a server 20 advertises its readiness to serve clients by t_binding to its well-known address.
  • "ssicom” is the name of the TCP/IP service used by the i-level routines of the IPMC toolkit. This service name must be listed in the /etc/services file on each host 12 in domain 11.
  • a client 21 connects to a server by t_connecting to the server's well-known address.
  • the host name supplied to the t-level connection request means 130 represents the host 12 on which the server 20 resides.
  • a server retrieves the new client file descriptor via t_listen and t_accept. (Routines provided by the UNIX TLI library, see previously cited references). Server and client are connected by a unique non-multiplexed TCP connection. A server may reject a new client file descriptor if it wishes to.
  • Tables for driving the STREAMS conformance modules are compiled into the UNIX kernel for all possible message sets.
  • the client process specifies which table to use by specifying its name.
  • Fig. 12 depicts the operation of t-level advertising means 120.
  • the C language implementation of advertising means 120 is the routine tAdvertise(pServiceName) in the source code appendix.
  • Advertising means 120 receives the name 121 of the service to be advertised.
  • Step 123 involves retrieving various information associated with the service, including the name of the server's host 12, its internet address, and the port number for the service.
  • advertising means 120 allocates a new transport endpoint for the server.
  • Step 125 allocates the necessary socket data
  • Step 126 binds the previously allocated transport endpoint to the socket data structure so as to leave the server 20 in a state in which it may receive TCP/IP connection requests.
  • Advertising means 120 returns the file descriptor of the server's transport endpoint 122 to the server.
  • Connection requests means 130 corresponds to the C language procedure tConnect (pHostName, pServiceName, pTable) in the annexed source code appendix.
  • Connection request means 130 is provided with three parameters 130a, including the name of the host 12 providing the service, the name of the service 121, and the name of the conformance table for the service, which is derived from the database 13. Steps 132 and
  • Step 133 are essentially analogous to the previously described steps 123-124 except, of course, steps 132- 133 involve the creation of transport endpoint on the client's host 12.
  • Step 134 involves allocating and filling in the necessary t_call data structure in orier to facilitate a connection request to the server.
  • Step 135 uses the t_connect function to issue such a TCP/IP connection request to the desired server. If such connection request is successful and acknowledged (by the server invoking connection acceptance means 140, described below) connection request means 130 proceeds to steps 136, 137 and 138 in which it pushes a TCP/IP read/write STREAMS interface module, a STREAMS envelope module and a STREAMS conformance module.
  • Step 139 configures the conformance module by designating the previously supplied conformance table 130a.
  • Connection request means 130 returns to the client process a file descriptor 131 representing the STREAMS connection to the server.
  • Fig. 14 depicts the operation of t-level connection acceptance means
  • Connection acceptance means 140 corresponds to the C language procedure tAccept (vServerFd) in the annexed source code appendix.
  • Server process 20 provides connection acceptance means 140 with the file descriptor of the server's transport endpoint 122.
  • Connection acceptance means 140 allocates the
  • step 144 Upon receiving a connection request transmitted by connection request means 130, step 144 creates and initializes the new transport endpoint and step 145 accepts the requested connection on the new transport endpoint.
  • the final steps in accepting the connection involve attaching a
  • read/write STREAMS interface module to the new transport endpoint (step 146), adding a STREAMS enveloping module onto the STREAM (step 147) and adding a STREAMS conformance module onto the STREAM
  • connection acceptance means 140 terminates by providing to the server a file
  • client 21 and server 20 can perform by directional, message-based STREAMS communication via STREAMS 131 and 141 using the ordinary STREAMS message sending and receiving
  • message-based STREAMS connections can be extended across machine boundaries.
  • Fig. 15 depicts the operation of t-level connection rejection means
  • Connection rejection means 150 corresponds to the C language function tReject (vServerFd) in the annexed source code appendix. Like the previously described connection acceptance means 140, connection rejection means 150 receives the file descriptor of the server's transport endpoint 122. Steps 152 and 153 are analogous to steps 142 and 143 in connection acceptance means 140. Once a connection request is received at step 153, step 154 issues a t_snddis call to reject the connection. The previously allocated call data structure is freed, and connection reject means 150 terminates at step 155.
  • Fig. 16 shows exemplary inter-machine 24 and intra-machine 23 connections that can be established utilizing the i-level resources of the IPMC toolkit.
  • the inter/intra- machine level IPMC resources may be used to establish a connection to a server in many ways, for example: (1) via a STREAMS pipe to a user-space server on the local host machine; (2) via TCP/IP to a user-space server on a remote host; (3) via STREAMS to a kernel-space server on the local host; (4) via TCP/IP and
  • interface 57 to i-level 52 is based on a client-server model and provides an advertising means 170 (Fig. 17), connection request means 180 (Fig. 18), connection acceptance means 190 (Fig. 19) and
  • Intra-machine connections 23 employ p-level IPMC resources while inter-machine connections 24 are established by the cooperation of the requesting client 21 and the communications agent 22 on the destination machine 12, which intercepts TCP/IP connection requests and converts them to STREAMS pipe connection requests for the server.
  • Communications agent 22 is realized as
  • I-level advertising means 170 corresponds to the C language function iAdvertise(pPathName) in the annexed source code appendix. I-level advertising means 170 is essentially analogous to p-level advertising means
  • advertising means 170 Since advertising must be on the local host 12, advertising means 170 simply receives the pathname of the service to be advertised 71 and invokes p-level advertising means 70 to advertise the service. I-level advertising means 170 returns to the server process a file descriptor 72 for the other end of a
  • Connection request means 180 corresponds to the C language function iConnect (pHostName, pPathName, pTableName) in the annexed source code appendix.
  • a client process 21 provides connection request means 180 with the same information 130a that would be provided to the previously described t-level
  • connection request means 130 The name of the client host 12 is retrieved in step 182 and compared in step
  • step 183 with the name of the host providing the desired service. If the host names match, the desired service is available on the local host and the process proceeds to step 185, at which it is ascertained whether the desired service is a local STREAMS pipe or driver. If the service is a local STREAMS pipe, step
  • the local service is provided by a
  • step 187 opens a connection to the STREAMS driver.
  • Steps 187 and 188 will both terminate by providing to the client process a file descriptor 181a for the local STREAMS
  • connection request means 180 terminates by providing a file descriptor to the client end of a STREAMS connection, regardless of whether the connection is local 181a or remote 181b.
  • Fig. 19 depicts the operation of i-level connection acceptance means
  • Connection acceptance means 190 corresponds to the C language function iAccept (vServerFd) in the annexed source code appendix, and is essentially analogous to (and actually invokes) p-level connection acceptance means 90.
  • i-level connection acceptance means 190 can rely on p-level connection acceptance means 90 to establish the communication path,
  • Connection acceptance means 90 returns a file
  • Fig. 20 depicts the operation of i-level connection rejection means
  • Connection rejection means 200 corresponds to the C language procedure iReject (vServerFd) in the source code appendix. Like connection acceptance means 190 above, i-level connection rejection means 200 is analogous to its p-level equivalent 100 and will not be redundantly described.
  • FIG. 21 depicts exemplary inter-machine 24 and intra-machine 23
  • Service providers 210 should not be equated with servers. The distinction is that one server 20 may provide a plurality of services 210 (at one time). Also, the services 210 relate to those services defined in database 13 and not to the TCP services defined in /etc/services. A server 20 advertises once and receives connection requests for potentially many different types of services 210.
  • 230 are means 233, 234 and 237 for associating a requested service with the host, pathname and
  • conformance information 130a needed to invoke the i-level IPMC resources.
  • FIG. 22 depicts the operation of v-level advertising means 220, for which the corresponding C language procedure is vAdvertise(pServerName) in the annexed source code appendix.
  • Advertising means 220 receives the name of the server 221 wishing to indicate its availability for v-level service connection requests.
  • Step 222 employs database 13 to retrieve a record related to server name 221 and step 223 extracts from this record the pathname 71 at which the particular server
  • Pathname 71 is supplied, in step 224, to i-level advertising means 170 which returns a file descriptor 72 for the STREAM attached to the file at pathname 71.
  • connection request means 230 receives the name 210 of the desired service.
  • connection request means 230 includes a cache (steps 232, 234 and 237) to quickly access records for recently used services.
  • the cache employs the
  • step 233 retrieves the relevant host, pathname, and conformance table parameters 130a necessary to invoke the i-level resources from the database 13, and adds the information to the cache in step 237.
  • I-level connection request means 180 invokes i-level connection request means 180 to establish a connection to the server which provides the requested service.
  • I-level connection request means 180 returns a file descriptor 181 (a or b) for the STREAMS connection to the server process.
  • Step 236 uses file descriptor 181 to send a STREAMS message to the server process indicating the desired service.
  • V-level connection request means 230 terminates by returning to the client process a file descriptor 181 of the STREAM to the server.
  • FIG. 24 depicts the operation of v-level connection acceptance means
  • Connection acceptance means 240 corresponds to the C language function vAccept(vServerFd, pServiceType) in the source code appendix.
  • the server process provides the server's file descriptor 72 to connection acceptance means 240.
  • v-level connection acceptance means 240 invokes i-level connection acceptance means 190 to obtain the file descriptor 91 for the STREAMS connection to the client process.
  • Step 243 uses file descriptor 91 to retrieve the client's STREAMS message designating the requested service.
  • Connection acceptance means 240 returns to the server process both the file descriptor 91
  • Connection rejection means 250 corresponds to the C language procedure vReject(vServerFd) in the source code appendix.
  • V-level connection rejection means 250 simply invokes i-level connection rejection means 200 to reject the i-level connection previously requested by v-level connection request means 230 at step 235.
  • connection closing means 260 Both client 21 and server 20 processes may use connection closing means 260 to terminate v-,i-,t- or p-level connections.
  • Connection closing means 260 corresponds to the C language procedures vClose(vFd), iClose(vFd), tClose(vFd) and pClose(vFd) in the source code
  • Connection closing means 260 relies on the UNIX close() system call (see cited references) to gracefully terminate a connection, allowing messages in transit at the time of its invocation to be
  • Agent 22 corresponds to the C language procedure DoIpmc(pCS, vIpmcFd) in the annexed source code appendix.
  • Each host 12 in domain 11 includes a means for requesting the service of agent 22.
  • step 271 invokes t-level connection acceptance means 140 to construct a STREAMS
  • agent 22 uses this STREAMS connection to receive the client's message (sent in step 184) indicating the pathname (type) of the desired service.
  • Step 273 determines whether the received pathname corresponds to a service provided by a local STREAMS pipe or driver.
  • agent 22 preforms step 274 and opens the
  • Step 275 echoes the client's message while step 276 provides the server process with the file descriptor of the t-level STREAMS connection to the client.
  • step 277 which opens the desired driver.
  • step 279 links the driver with the t-level STREAMS connection to the client.
  • step 279 links the two drivers without penetrating user space.
  • a conventional STREAMS implementation of step 279 would require that the two drivers be linked via a user-space module between their respective stream heads.
  • the kernel space linking of two drivers relies on the service provided by the C language procedure slLinkTogether (PCS, vFdl, vFd2), the source code of which appears in the appendix.
  • the invention provides a STREAMS link multiplexer (mux) for linking two streams within kernel space.
  • the STREAMS link mux is a STREAMS module which provides a bidirectional data link between two drivers.
  • server 20 and client 21 processes each may access message sending means 35 and message receiving means 36. It is apparent that in the IPMC toolkit, all connections (at all levels) are STREAMS based, even though the
  • p-, t-, i-, and v-level message sending means 35 corresponds to the C language procedure sSendMsg(vFd, pProto, vProtoLength, pData, vDataLength) in the source code appendix, which essentially performs the ordinary
  • p-, t-, i-, and v-level message receiving means 36 corresponds to the routine sRecvMsg(Vfd, Pproto, pProtoLength, Pdata, pDataLength), which performs the STREAMS getmsg() function.
  • FIG. 28 depicts the structure of a t-level inter-machine
  • STREAMS read/write modules 282a-b interface between the intra-machine STREAMS pipes on hosts 12a-b and the inter-machine TCP/IP link 24, thereby effectively extending the STREAMS pipe across machine boundaries.
  • STREAMS envelope modules 281a-b at each end of the pipe compensate for the string-of-bytes nature of the inter-machine TCP/IP link 24 by packaging and reassembling messages 40 so as to maintain the
  • STREAMS conformance modules 280a-b cooperate to provide any necessary byte swapping, the need for which may arise from the incompatible byte orderings of hosts 12a-b. This is particularly important for the protocol part 42 of message 40 (Fig. 4), for which the necessary byte swapping will depend not only on the particular hosts 12a-b (Fig. 28), but also on the particular arrangement of fields 46a-k, as determined by the type field 45 of protocol part 42 (Fig. 4).
  • Conformance tables for all possible message sets are compiled into the kernel of the hosts 12.
  • One conformance module 280a sends a message to the other conformance module 280b indicating the name of the conformance table to use.
  • Each module 280a-b will then know the byte orderings and message formats to expect from its partner, and byte swapping may be performed if necessary. Conformance is enforced as a message passes through a conformance module 280a-b.
  • Each message format has associated therewith a particular conformance string indicating the order of byte fields in the message. For example, the string "1412" would indicate a one byte field, followed by a four byte field, followed by a one byte field and terminated by a two byte field.
  • the conformance table is used to map between the type field 45 for a particular message and the set of possible conformance strings for a particular service's message set. Speed is an important issue in the design of the conformance modules 280.
  • the conformance table is preferably ordered in the order in which the message types will be received, so as to eliminate the time needed to search for the conformance string. For other types of services in which the precise sequence of message types is not predetermined, it may be preferable to order the conformance table so that a binary search
  • conformance modules 280 includes the put procedure
  • the write side includes both a put procedure
  • Conformance modules 280 also include an open procedure ConfOpen(pRQ, vDevNum, vFlag, fSFlag) and close procedure ConfClose(pRQ). Other data structures and routines associated with the
  • 280a and 280b perform a handshake sequence to ensure that each knows the byte ordering of the other's machine 12a or b.
  • conformance modules 280a-b invokes its open procedure which flushes the STREAM and sends a handshake request message to the other module (280b).
  • the read put procedure of the other conformance module 280b invokes its open procedure which flushes the STREAM and sends a handshake request message to the other module (280b).
  • module 280a next prepares and sends a conformance request message to module 280b indicating machine 12a's native byte ordering and identifying the conformance table corresponding to the desired message set.
  • module 280b Upon receipt, module 280b's read put procedure configures module 280b to supply the byte swapping requested in the acknowledgement message. At this point, conformance modules 280a and
  • 280b are prepared to provide the proper byte swapping to messages passing between server 20 and client 21.
  • cfSwapProto (pProto,pSubTable), listed in the source code appendix.
  • cfSwapProto relies on the predetermined sequence of messages in the message set or the sorted order of entries in the conformance table to minimize the time to access the entry needed to byte swap a particular type of
  • Fig. 29 depicts the operation of STREAMS envelope modules 281a-b. For messages being sent from host 12a to host 12b (Fig.
  • envelope module 281a adds an envelope 290 to the beginning of message 40. Envelope 290 and message 40 are then transmitted via byte-stream link 291 to envelope module 281b which uses the data in envelope
  • 290 essentially contains a list of the particular buffer types (such as, for example data 41 and
  • envelope module 281b on the receiving end of the byte-stream data link to partition the message into its constituent buffers.
  • envelope modules 281a-b assume a downstream machine boundary: upstream from the envelope modules, data is transmitted as messages; downstream from the envelope modules, data is transmitted as a byte stream.
  • Envelope modules 281 include the following procedures: write service procedure EnvWSrv(pWQ); read service procedure EnvRSrv(pRQ); read put procedure EnvRPut(pRQ,pMsg); open procedure
  • EnvClose(pRQ) EnvClose(pRQ) .
  • An initial handshake is performed to synchronize envelope modules 281a and b.
  • One of the envelope modules (assume 281a) invokes its open procedure which flushes the STREAM and sends a
  • module 281b In response, module 281b's read service
  • Module 281a upon receipt of the acknowledgement by its read service procedure, enables its write queue to complete the handshaking process.
  • the write service procedure is called to add an envelope 290 to the beginning of each message 40 as it passes through envelope module 281a.
  • the write service routine first checks to ensure that the connection is properly synchronized (handshaked) and then invokes an envelope preparation procedure, enPrepEnvMsg(vType,pMsg) in the source code appendix, to prepare envelope 290, and links envelope 290 and message 40 into a single buffer which is sent along byte-stream link 291 to envelope module 281b.
  • An envelope (type Envelope_tg in the source code appendix) is a fixed-length data structure including fields indicating: (1) the total number of bytes in the message (including both envelope 290 and message
  • the envelope preparation procedure computes and fills in the appropriate fields in the envelope 290 based on the parameters of machine 12a and message 40.
  • the receiving function of the envelope modules is somewhat more complex to implement.
  • the receiving envelope module 281b must wait until the entire message (i.e., both envelope 290 and message 40) has arrived at its input queue before invoking its read service procedure to restore message 40.
  • the read side therefore cannot use the automatic queue enabling mechanism provided by the STREAMS system since STREAMS will not automatically enable a non-empty queue.
  • envelope modules 281 use their read put procedures to append to and re-enable the read queue as portions of messages arrive from byte-stream link
  • the STREAMS scheduler periodically invokes envelope module 281b's read service procedure to regenerate messages 40.
  • the service procedure examines the number of bytes in the queue. If these are less than the number of bytes in a (fixed-length) envelope 290, the service procedure simply terminates to await more data from byte-stream link 291.
  • the service procedure next concatenates the bytes comprising envelope 290 (and potentially more) into a single buffer for inspection. Because envelope modules 281 are downstream from conformance modules 280, the service procedure examines the byte order field of envelope 290 and, if necessary, calls the procedure enSwapEnvelope(pEnv) to perform byte swapping. The service procedure looks next at the number-of-bytes field of envelope 290 to determine whether or not the entire message 40 has arrived in the queue. If so, it invokes the procedure
  • enMakeMsg (pBytes,nOffset,pEnv) to regenerate message 40 from the bytes available. If the buffer (pBytes) contains more bytes than were necessary to generate message 40, the service procedure places the extra bytes back onto the queue for later processing. If, on the other hand, enough bytes are available to extract another message 40, the service procedure will repeat the de-enveloping process as necessary.
  • IPMC toolkit which depict but one embodiment of the present invention, various alterations, modifications and improvements will readily occur to those skilled in the art. Such alterations, modifications and improvements as are made obvious by this disclosure, including the drawings and C language source code, are intended to be part of this description though not expressly stated herein. Accordingly, the foregoing description is by way of example only, and not limiting. The invention is limited only as defined in the following claims and equivalents thereto.
  • All SSI user-space code is expected to call these routines rather than calling the UNIX routines directly.
  • vReturnCode putmsg(vFd, pP, pD, 0);
  • vReturnCode putmsg(vFd, pP, pD, RS_HIPRI);
  • vReturnCode getmsg (vFd, pP, pD, &fFlags);
  • vReturnCode getmsg(vFd, pP, pD, &fFlags);
  • vMuxId ioctl(vFd, I_LINK, vLowerFd);
  • vMuxId ioctl(vFd, I_PLINK, vLowerFd);
  • vReturnCode ioctl(vFd, I_PUNLINK, vMuxId) ;
  • vReturnCode ioctl(vFd, I_PUSH, pModuleName)
  • vReturnCode ioctl(vFd, I_POP, 0);
  • pReturnCode sigset (SIGPOLL, pSignalHandler);
  • vReturnCode ioctl(vFd, I_SETSIG, S_INPUT
  • vReturnCode ioctl(vFd, I_SENDFD, vFdToSend)
  • vReturnCode ioctl(vFd, I_RECVFD, &RFd) ;
  • vReturnCode ioctl(vFd, I_STR, &SIoctl);
  • vReturnCode poll(&PFd, 1, lTimeOut);
  • vReturnCode poll(&PFd, 1, lTimeOut);
  • vReturnCode poll(&PFc, 1, lTimeOut);
  • vReturnCode poll(&PFd, 1, 0);
  • pPFs (struct pollfd *) malloc (sizeof (struct pollfd) * nFds); if ( ! pPFs ) return -51; /* malloc failed */
  • vReturnCode poll(pPFs, nFds, lTimeOut);
  • aFds [ 0 ] open ( "/dev/spx" , O_RDWR) ; Mar 9 11:15 1992 /home/steve/doc/memo/patent.1 Page 9 if ( aFds[0] ⁇ 0 ) return -2;
  • aFds[1] open("/dev/spx", O_RDWR);
  • vReturnCode ioctl(aFds[1], I_FDINSERT, &Fdi);
  • vReturnCode fattach (vFd, pPathName);
  • stat Stat /* for stat(2) */
  • vReturnCode fstat(vFd, &Stat);
  • vReturnCode stat (pPathName, &Stat);
  • vReturnCode chmod (pPathName , vPerm);
  • vReturnCode chown (pPathName, vOwner, vGroup);
  • /* sIsPipe() - is a given pathname a STREAMS pipe or not.
  • stat Stat /* for stat (2) */
  • vReturnCode stat (pPathName, &Stat);
  • vReturnCode stat ( "/dev/spx", &Stat);
  • Conform Request may optionally have linked M_DATA containing
  • This mechanism does any byte swapping in messages according to a "table" describing the messages of a message set.
  • Conformance modules on both sides of the machine boundary cooperate to perform the byte swapping.
  • One conformance module sends the name of the conformance table to the other conformance module.
  • each module knows the byte ordering of its parther and what messag formats to expect. When a message comes in, byte swapping may be done if necessary.
  • ConformCB_t *pCCB (ConformCB_t *) (pWQ->q_ptr);
  • struct iocblk *iocp (struct iocblk *) (pMsg->b_rptr); mblk_t *pCfmMsg;
  • pCfmMsg cfPrepCfmMsg(CFM_ConformReq);
  • pCCB->pCfmTable GetCfmTable (pMsg->'b_cont->b_rptr);
  • pCCB->sState ! CFM_HANDSHOOK
  • puthext (pWQ, pMsg);
  • ConformCB_t *pCCB (ConformCB_t *) (pWQ->g_ptr);

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)

Abstract

L'invention concerne un appareil et un procédé orientés objet, offrant des ressources (50, 55) de communication inter-processus à base de messages, qui permettent à un programmeur de mettre en ÷uvre, de façon efficace, des programmes qui réalisent la communication inter-processus entre divers processus (20, 21) dans un réseau informatique. Lesdites ressources, qui, de façon typique, s'adaptent à un modèle client/serveur, sont telles qu'un programmeur peut spécifier une tâche de communication inter-processus particulière, et cela indépendamment du fait que les processus en communication soient: (i) en exécution dans des ordinateurs centraux semblables ou différents; (ii) en exécution dans l'espace de l'utilisateur ou de la partie résidente du système d'exploitation; (iii) en exécution dans des ordinateurs centraux présentant des classements d'octets compatibles ou incompatibles; et, (iv) en exécution dans des ordinateurs centraux reliés par des protocoles de communication à base d'octets ou à base de messages. Des programmes codés faisant appel aux ressources de communication inter-processus selon l'invention sollicitent automatiquement, lorsqu'ils sont en exécution dans un réseau, des procédures appropriées de mise en conformité et/ou d'enveloppement pour assurer une communication fiable inter-processus, à base de messages.
PCT/US1993/006398 1992-07-07 1993-07-07 Appareil et procede permettant la communication inter-processus a base de messages et axee sur le service dans un systeme informatique en reseau WO1994001832A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU46673/93A AU4667393A (en) 1992-07-07 1993-07-07 Apparatus and method for providing service oriented, message-based interprocess communication in a networked computing system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US90998292A 1992-07-07 1992-07-07
US909,982 1992-07-07

Publications (1)

Publication Number Publication Date
WO1994001832A1 true WO1994001832A1 (fr) 1994-01-20

Family

ID=25428140

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1993/006398 WO1994001832A1 (fr) 1992-07-07 1993-07-07 Appareil et procede permettant la communication inter-processus a base de messages et axee sur le service dans un systeme informatique en reseau

Country Status (2)

Country Link
AU (1) AU4667393A (fr)
WO (1) WO1994001832A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0733971A2 (fr) * 1995-03-22 1996-09-25 Sun Microsystems, Inc. Méthode et appareil pour gérer des connexions pour la communication entre des objets dans un système d'objets distribué
EP2156313A2 (fr) * 2007-05-04 2010-02-24 QUALCOMM Incorporated Procédés et dispositif de communication interprocessus pour construire des systèmes de télécommunication extensibles/redondants

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4800488A (en) * 1985-11-12 1989-01-24 American Telephone And Telegraph Company, At&T Bell Laboratories Method of propagating resource information in a computer network

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4800488A (en) * 1985-11-12 1989-01-24 American Telephone And Telegraph Company, At&T Bell Laboratories Method of propagating resource information in a computer network

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0733971A2 (fr) * 1995-03-22 1996-09-25 Sun Microsystems, Inc. Méthode et appareil pour gérer des connexions pour la communication entre des objets dans un système d'objets distribué
EP0733971A3 (fr) * 1995-03-22 1999-07-07 Sun Microsystems, Inc. Méthode et appareil pour gérer des connexions pour la communication entre des objets dans un système d'objets distribué
EP2156313A2 (fr) * 2007-05-04 2010-02-24 QUALCOMM Incorporated Procédés et dispositif de communication interprocessus pour construire des systèmes de télécommunication extensibles/redondants
US8464272B2 (en) 2007-05-04 2013-06-11 Qualcomm Incorporated Inter-process communication methods and apparatus for building scalable/redundant telecommunications systems

Also Published As

Publication number Publication date
AU4667393A (en) 1994-01-31

Similar Documents

Publication Publication Date Title
US5265261A (en) Method and system for network communications using raw mode protocols
EP0725950B1 (fr) Systeme de gestion de reseau oriente objet a appel de procedure a distance
US5548723A (en) Object-oriented network protocol configuration system utilizing a dynamically configurable protocol stack
US5515508A (en) Client server system and method of operation including a dynamically configurable protocol stack
US5499343A (en) Object-oriented networking system with dynamically configurable communication links
US5619650A (en) Network processor for transforming a message transported from an I/O channel to a network by adding a message identifier and then converting the message
US6708223B1 (en) Accelerating a distributed component architecture over a network using a modified RPC communication
KR100387207B1 (ko) 원격네트워크장치에의한통신시스템및통신방법
US6799200B1 (en) Mechanisms for efficient message passing with copy avoidance in a distributed system
US6557046B1 (en) Method and system for providing an event system infrastructure
US7814176B2 (en) System and method for processing transactions in a multisystem database environment
US6088729A (en) Method, system, and computer program product for establishing dialogs in an intraconnect data communication
Lo et al. The implementation of a high-performance ORB over multiple network transports
US6009463A (en) Cooperative service interface with buffer and lock pool sharing, for enhancing message-dialog transfer between network provider and distributed system services
US6021430A (en) Output interface method and system for enhanced data transfers via cooperative service interface
WO1994001832A1 (fr) Appareil et procede permettant la communication inter-processus a base de messages et axee sur le service dans un systeme informatique en reseau
US6490623B1 (en) System, method and computer readable code for encapsulating system, language and device independent communications socket functionality in a lightweight uniform communications object model
Madukkarumukumana et al. Harnessing user-level networking architectures for distributed object computing over high-speed networks
Hertweck et al. X25 based process—process communication
CN113176957B (zh) 一种基于rpc的远程应用自动化系统
EP0958688B1 (fr) Procede et systeme de communications de donnees a architecture cia
CN118200253A (zh) 面向rdma ud传输的可靠通信方法、电子设备及可读介质
Lewandowski Interprocess communication in UNIX and Windows NT
WO1997024664A1 (fr) Systeme et methode de transfert de messages entre des programmes d'applications tournant dans un environnement informatique distribue
Chatterjee A COMMON NETWORK INTERFACE

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU BB BG BR BY CA CZ FI HU JP KR KZ LK MG MN MW NO NZ PL RO RU SD SK UA

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA