US20080127206A1 - Conducting client-server inter-process communication - Google Patents
Conducting client-server inter-process communication Download PDFInfo
- Publication number
- US20080127206A1 US20080127206A1 US11/497,830 US49783006A US2008127206A1 US 20080127206 A1 US20080127206 A1 US 20080127206A1 US 49783006 A US49783006 A US 49783006A US 2008127206 A1 US2008127206 A1 US 2008127206A1
- Authority
- US
- United States
- Prior art keywords
- client
- server
- inter
- thread
- connection
- 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.)
- Granted
Links
- 238000004891 communication Methods 0.000 title claims abstract description 154
- 238000000034 method Methods 0.000 title claims abstract description 153
- 230000000903 blocking effect Effects 0.000 claims abstract description 26
- 230000004044 response Effects 0.000 claims abstract description 19
- 230000000977 initiatory effect Effects 0.000 claims abstract description 4
- 230000008569 process Effects 0.000 claims description 40
- 238000004590 computer program Methods 0.000 description 12
- 238000013459 approach Methods 0.000 description 5
- 238000013500 data storage Methods 0.000 description 3
- 239000003999 initiator Substances 0.000 description 3
- 238000012423 maintenance Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000026676 system process Effects 0.000 description 1
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
-
- 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/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/541—Client-server
Definitions
- Computer systems are systems that manipulate data according to a list of instructions called a program.
- a program contains instructions that are understandable and executable by a computer's main processor.
- An operating system is a type of computer program that controls applications that can be run on the computer.
- Computer programs can include sub-system components that drive various processes when they are executed. The various processes that can be associated with one or more computer program sub-systems can communicate through a protocol called inter-process communication (IPC).
- IPC inter-process communication
- IPC can be used to facilitate the coordination of activities among different program processes that run concurrently in an operating system.
- An advantage of coordinating the activities of different program processes is that it enables a program to handle many user requests at the same time. Since even a single user request can result in multiple processes running in the operating system on the user's behalf, each of the processes should be provided with the capacity to communicate with the others.
- IPC interfaces make this possible.
- a type of IPC is called local procedure call (LPC).
- LPC is a protocol that one computer program can use to request a service from a computer program located in the same computer.
- LPC uses the client/server model.
- the service requesting program is called the client and the service-providing program is called the server.
- LPC is a synchronous operation that requires that operations of the requesting program to be suspended until the results of the local procedure are returned.
- the use of lightweight processes or threads that share the same address space allows multiple LPCs to be performed concurrently.
- LPC can be implemented using kernel “port” objects.
- a server process first creates a port object with a well known name and then waits for client processes to connect.
- a client process can connect by “opening” the port object and sending a connect message. If the server accepts the connection a new unnamed port object is created for the connection.
- Port objects are securable kernel objects that allow a process to identify a process on the other side of the connection.
- LPC is the fastest IPC that is used on the WINDOWSTM platform. Unfortunately, LPC does not possess request or connection timeout support, which can cause client processes to “hang” (be suspended) while waiting for server replies (there currently is not a mechanism for aborting a client call to the server). To overcome this limitation, conventional products perform client side LPC communication from a separate thread.
- FIG. 1 illustrates the operation of LPC.
- client subsystem 101 and server subsystem 105 that are shown in FIG. 1 represent respective processes that execute on a computer.
- a client subsystem 101 spawns a separate thread 103 a as shown at 103 , for the purpose of communicating with server subsystem 105 via server side port object 109 a that has been previously created (e.g., 109 ).
- the separate thread 103 a is maintained during client-server communications.
- the separate thread 103 a can perform synchronous calls (see 119 - 125 ) to server subsystem 105 via server side port object 109 a .
- LPC seeks to isolate possible delays from the main client process through the use of separate thread 103 a.
- Such communications include initiating an inter-process communication thread that is separate from a main client inter-process communication thread, where the inter-process communication thread that is separate from the main client inter-process communication thread establishes a connection with a server.
- a client communication port is created during the establishment of the connection with the server.
- One or more non-blocking asynchronous communications are transmitted to a server communication port.
- Responses to the one or more non-blocking asynchronous communications are awaited for receipt by the client communication port.
- Inter-process communications are conducted in a manner that avoids a blocking of the execution of main client processes and in a manner that avoids the memory and speed resource expenditures that are associated with maintaining a separate thread for the purpose of executing such communications.
- FIG. 1 illustrates the operation of (LPC) local procedure call.
- FIG. 2A is a block diagram of a computer system upon which a system (SCIC) for conducting client-server inter-process communications can be implemented according to one embodiment.
- SCIC system for conducting client-server inter-process communications
- FIG. 2B illustrates the operation of SCIC as a part of client server inter-process communications according to one embodiment.
- FIG. 3 shows components of a system for conducting client-server inter-process communications (SCIC) according to one embodiment.
- SCIC client-server inter-process communications
- FIG. 4 shows a flowchart of the steps performed in a method for conducting client-server inter-process communications (SCIC) according to one embodiment.
- SCIC client-server inter-process communications
- FIG. 2A is a block diagram of a computer system 200 upon which a system (SCIC) 350 for conducting client-server inter-process communications can execute according to one embodiment.
- SCIC 350 directs the conduction of inter-process communications between internal sub-systems (client and server) of one or more computer programs 300 that are resident on computer system 200 .
- the conduction of these inter-process communications is performed in a manner that avoids a blocking of the execution of main client processes and in a manner that avoids the memory and speed resource expenditures that are associated with maintaining a separate thread for the purpose of executing such communications.
- SCIC 350 accomplishes this by directing the creation of a client side port that has functionality similar to that of server side local procedure call (LPC) ports (e.g., it possesses a time out function) during the establishment of a client process connection with a server side port.
- LPC server side local procedure call
- the creation of a client side port is discussed herein in detail with reference to FIG. 2B .
- This port can be used (in combination with the server side port) in the execution communications between server and client processes and to support a dual port approach to inter-process communications. It should be appreciated that the aforementioned client side port can be used instead of a separate memory and speed burdening separate client side thread to receive communications from a server process.
- communications e.g., calls
- communications can include timeout support. Consequently, these communications may not block other client processes.
- computer system 200 includes at least one processing unit 202 and data storage components 204 wherein one or more computer programs 300 reside.
- one or more computer programs 300 can include client subsystem 340 and server subsystem 360 as is shown in FIG. 2A . It should be appreciated that although only two subsystems are shown in FIG. 2A for clarity and brevity, one or more computer programs 300 can include numerous internal client and server subsystems and processes. For purposes of the discussion that follows, client subsystem 340 and server subsystem 360 represent client and server processes operating on computer system 200 and that engage in inter-process communications.
- SCIC 350 can be encompassed by components and operations of client subsystem 340 (see FIG. 2A ). In an alternate embodiment, SCIC 350 can be separate from client subsystem 340 but can operate in cooperation with components and operations thereof.
- data storage components 204 can include volatile (such as RAM) and/or non-volatile (such as ROM, flash memory, etc.) components.
- volatile such as RAM
- non-volatile such as ROM, flash memory, etc.
- Other data storage components that can be a part of computer system 200 include but are not limited to CD-ROM, DVD or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed.
- computer system 200 can also include input devices and output devices (not shown).
- computer system 200 can include network connections to other devices, computers, networks servers, etc. using either wired or wireless media. All these devices are well known in the art and need not be discussed here at length.
- computer system 200 is shown and described in FIG. 2A as having certain numbers and types of elements, embodiments are not limited to the implementation shown in FIG. 2A . That is, computer system 200 can include elements other than those shown in FIG. 2A . Moreover, computer system 200 can include more than one of each of the elements that are shown in FIG. 2A .
- computer system 200 upon which one or more computer programs (e.g., 300 ) reside and upon which SCIC 350 executes can possess a variety of forms.
- computer system 200 can be but is not limited to being a personal desktop computer (as is shown in FIG. 2A ), a portable notebook computer, a personal digital assistant (PDA), and a gaming system.
- PDA personal digital assistant
- FIG. 2B illustrates the operation of SCIC 350 in the context of client-server inter-process communications.
- SCIC 350 is shown in FIG. 2B as being encompassed by client subsystem 340 .
- SCIC 350 directs the creation of a server side communications port and inter-process communications between client subsystem 340 and server subsystem 360 .
- a server side port object 251 a is created and thereafter handshake messages between client subsystem 340 and server subsystem 360 are exchanged that establish a connection via the server side port object 251 a for supporting communications between client subsystem 340 and server subsystem 360 . Moreover, an identification number of a client side port 255 a is passed to the server subsystem during the establishment of the connection.
- server side port object 251 a is created at 251 .
- server side port object 251 a is created through the use of a server subsystem port creation call (e.g., NtCreateWaitablePort in WINDOWSTM).
- a server subsystem port creation call e.g., NtCreateWaitablePort in WINDOWSTM.
- client subsystem inter-process communication thread separate from a main client subsystem thread
- client side port object 255 a is created.
- client side port object 255 a is created through the use of a client subsystem port creation call 255 (e.g., NtCreateWaitablePort in WINDOWSTM).
- the readiness of the server side port object 251 a to receive messages is indicated by port object call readiness condition 259 (e.g., NtReplyWaitReceivePortEx in WINDOWSTM).
- port object call readiness condition 259 e.g., NtReplyWaitReceivePortEx in WINDOWSTM.
- a port connection call 263 e.g., a request for port access
- messages can be transmitted to client subsystem 340 via the separate thread that indicate that the port connect request has been accepted 265 and completed 267 .
- the series of message exchanges 263 - 267 is termed a “handshake.”
- a port identification number of client side port object 255 a can be transmitted to server subsystem 360 during the handshake (during the establishment of the connection as indicated in the drawings).
- a second handshake can be performed, this time establishing a connection between the client side port object 255 a and the server subsystem 360 .
- a series of non-blocking asynchronous client side calls e.g., messages that can terminate after a period or after being responded to
- initiate and drive exchanges between client subsystem and server system processes can be commenced as is described below.
- the readiness of the client side port object 255 a to receive messages in order that the aforementioned second handshake can be commenced is indicated by a port object call readiness condition shown in FIG. 2B at 269 (e.g., NtReplyWaitReceivePortEx in WINDOWSTM).
- a port connection call from server subsystem 360 can be transmitted to client side port object 255 a .
- messages can be transmitted to server subsystem 360 that indicate that the port connection call 271 has been accepted as shown at 273 and completed as shown at 275 .
- measures that can be employed to avoid server subsystem side hang that may be caused by the potentially blocking port connection call 271 can include but are not limited to: (1) creating a separate short lived server subsystem inter-process communication thread for the second handshake, (2) using a pre-created server subsystem inter-process communication thread for the second handshake, and (3) using an available inter-process communication thread from a thread pool for the second handshake.
- non-blocking asynchronous client side calls e.g., 279 and 287
- client subsystem 340 invokes a server subsystem 360 procedure or process through calls 279 and 287 , whose results, asynchronous call replies 283 and 291 , are delivered back to the client side port object 255 a point of call.
- port call ready condition e.g., 277 , 281 , 285 , and 289 , indicates the readiness of the respective port objects to receive calls.
- embodiments take advantage of server subsystem side functions that support a timeout feature and reverses client subsystem 340 and server subsystem roles 360 by identifying a client side port to server subsystem 360 during the initial handshake. Because the port created on the client side can possess timeout support (unlike a separate client side thread) subsequent inter-process communications between client subsystem 340 and server subsystem 360 can use LPC with timeout support. Moreover, this can be done without the need to maintain a separate client subsystem 340 thread throughout an LPC session.
- FIG. 3 shows components of a system 350 for conducting client-server inter-process communications (SCIC) according to one embodiment.
- SCIC 350 directs the conduct of inter-process communications between internal sub-systems (client and server) of one or more computer programs (e.g., 300 in FIG. 2A ) that execute on a computer system (e.g., 200 in FIG. 2A ).
- inter-process communications are conducted in a manner that avoids a blocking of the execution of main client processes and in a manner that avoids the memory and speed resource expenditures that are associated with maintaining a separate thread for the purpose of executing such communications.
- components of SCIC 350 can be implemented in hardware or software or in a combination of both.
- SCIC 350 can be encompassed by components and operations of a client subsystem (e.g., 340 in FIG. 2 ) of a computer program (e.g., 300 in FIG. 2 ) that executes on a computer system (e.g., 200 in FIG. 2 ).
- components and operations of SCIC 350 can be separate from the aforementioned client subsystem but can operate cooperatively with components and operations thereof.
- components of SCIC 350 include inter-process communication thread initiator/generator 351 , client subsystem inter-process communication port generator 353 and asynchronous inter-process communication transmitter 355 .
- inter-process communication thread initiator/generator 351 initiates the generation of a client subsystem (e.g., 340 in FIG. 2 ) inter-process communication thread that is separate from a main client subsystem inter-process communication thread.
- the separate client subsystem inter-process communication thread facilitates client subsystem calls that serve to establish a connection with a server subsystem so as to allow information related to the identification of a client subsystem side inter-process communications port (e.g., client side port object 255 a of FIG. 2B ) to be passed to the server subsystem.
- an identification number of a client subsystem side inter-process communication port (e.g., client side port object 255 a of FIG. 2B ) is transmitted to the server subsystem so that the server subsystem can identify the client subsystem side inter-process communication port (e.g., client side port object 255 a of FIG. 2B ).
- the server subsystem can identify the client subsystem side inter-process communication port (e.g., client side port object 255 a of FIG. 2B ).
- the separate client subsystem inter-process communication thread can be terminated (see FIG. 2B ).
- Client subsystem inter-process communication port creator 353 creates a client side inter-process communication port (e.g., client side port object 255 a of FIG. 2B ) during the establishment of the connection between the client subsystem and the server subsystem.
- client side inter-process communication port e.g., client side port object 255 a of FIG. 2B
- the client inter-process communication port can be created in order to facilitate the conduction of client-server inter-process communications that may not rely upon the maintenance of a client subsystem thread that is separate from a main client subsystem thread.
- the client side inter-process communication port (e.g., client side port object 255 a of FIG. 2B ) is created during the establishment of the connection between the client and the server via the separate thread.
- Asynchronous communications transmitter 355 transmits non-blocking asynchronous inter-process communications (non-blocking calls, messages, requests etc.) to a server side inter-process communication port.
- the client side inter-process communication port e.g., client side port object 255 a of FIG. 2B
- the client side inter-process communication port is readied to receive responses to the aforementioned one or more non-blocking asynchronous communications before the transmission of the non-blocking asynchronous inter-process communications (through the aforementioned connection process).
- asynchronous client subsystem calls can timeout after a predetermined period. Moreover, in one embodiment an immediate response to an asynchronous client subsystem call can terminate the client call.
- FIG. 4 shows a flowchart 400 of the steps performed in a method 400 for conducting client-server inter-process communications (SCIC) according to one embodiment.
- the flowchart includes processes that, in one embodiment can be carried out by processors and electrical components under the control of computer-readable and computer-executable instructions. Although specific steps are disclosed in the flowcharts, such steps are exemplary. That is embodiments are well suited to performing various other steps or variations of the steps recited in the flowcharts. Within various embodiments, it should be appreciated that the steps of the flowcharts can be performed by software, by hardware or by a combination of both.
- a client subsystem inter-process communication thread that is separate from a main client subsystem inter-process communication thread is initiated.
- an inter-process communication thread initiator/generator e.g., 351 in FIG. 3
- the separate client subsystem inter-process communication thread facilitates client subsystem calls that serve to establish a connection with a server subsystem so as to allow information related to the identification of a client side inter-process communications port (e.g., client side port object 255 a in FIG. 2B ) to be passed to the server subsystem.
- a client subsystem inter-process communication port is created.
- a client subsystem inter-process communication port creator e.g., 353 in FIG. 3
- creates the client side inter-process communication port e.g., client side port object 255 a in FIG. 2B ) during the establishment of the connection between the client subsystem and the server subsystem.
- the client subsystem inter-process communication port is created in order to facilitate the conduction of client-server inter-process communications that do not rely upon the maintenance of a client subsystem thread that is separate from a main client subsystem thread.
- step 405 the establishment of a connection with the server subsystem via client side inter-process communication port is completed. And, at step 407 when the connection with the server subsystem via the client side inter-process communication port is completed the separate client subsystem inter-process communications thread is terminated.
- one or more non-blocking asynchronous communications are transmitted to a server side inter-process communication port (e.g., server side port object 251 a in FIG. 2B ).
- an asynchronous communication transmitter e.g., 355 in FIG. 3
- transmits non-blocking asynchronous inter-process communications (non-blocking calls, messages, requests, etc.) to a server side inter-process communication port (e.g., server side port object 251 in FIG. 2B ).
- the client side inter-process communication port e.g., client side port object 255 a in FIG. 2B
- is readied to receive responses to the aforementioned one or more non-blocking asynchronous communications through the aforementioned establishment of a connection with server subsystem).
- Such communications include initiating an inter-process communication thread that is separate from a main client inter-process communication thread, where the inter-process communication thread that is separate from the main client inter-process communication thread establishes a connection with a server.
- a client communication port is created during the establishment of the connection with the server.
- One or more non-blocking asynchronous communications are transmitted to a server communication port.
- Responses to the one or more non-blocking asynchronous communications are awaited for receipt by the client communication port.
Abstract
Description
- Computer systems are systems that manipulate data according to a list of instructions called a program. A program contains instructions that are understandable and executable by a computer's main processor. An operating system is a type of computer program that controls applications that can be run on the computer. Computer programs can include sub-system components that drive various processes when they are executed. The various processes that can be associated with one or more computer program sub-systems can communicate through a protocol called inter-process communication (IPC).
- IPC can be used to facilitate the coordination of activities among different program processes that run concurrently in an operating system. An advantage of coordinating the activities of different program processes is that it enables a program to handle many user requests at the same time. Since even a single user request can result in multiple processes running in the operating system on the user's behalf, each of the processes should be provided with the capacity to communicate with the others. IPC interfaces make this possible. A type of IPC is called local procedure call (LPC).
- LPC is a protocol that one computer program can use to request a service from a computer program located in the same computer. LPC uses the client/server model. The service requesting program is called the client and the service-providing program is called the server. LPC is a synchronous operation that requires that operations of the requesting program to be suspended until the results of the local procedure are returned. However, the use of lightweight processes or threads that share the same address space allows multiple LPCs to be performed concurrently.
- LPC can be implemented using kernel “port” objects. As a part of the process, a server process first creates a port object with a well known name and then waits for client processes to connect. A client process can connect by “opening” the port object and sending a connect message. If the server accepts the connection a new unnamed port object is created for the connection. Port objects are securable kernel objects that allow a process to identify a process on the other side of the connection.
- LPC is the fastest IPC that is used on the WINDOWS™ platform. Unfortunately, LPC does not possess request or connection timeout support, which can cause client processes to “hang” (be suspended) while waiting for server replies (there currently is not a mechanism for aborting a client call to the server). To overcome this limitation, conventional products perform client side LPC communication from a separate thread.
-
FIG. 1 illustrates the operation of LPC. It should be appreciated thatclient subsystem 101 andserver subsystem 105 that are shown inFIG. 1 represent respective processes that execute on a computer. As shown inFIG. 1 , initially, aclient subsystem 101 spawns aseparate thread 103 a as shown at 103, for the purpose of communicating withserver subsystem 105 via serverside port object 109 a that has been previously created (e.g., 109). Theseparate thread 103 a is maintained during client-server communications. After a connection between the client subsystem and the server subsystem has been established in a manner such as is discussed above, at 115-117, theseparate thread 103 a can perform synchronous calls (see 119-125) toserver subsystem 105 via serverside port object 109 a. LPC seeks to isolate possible delays from the main client process through the use ofseparate thread 103 a. - It should be appreciated that although this approach achieves better stability than regular LPC, it introduces extra memory and speed costs that are associated with maintaining the additional thread on the client side. Another approach is to tolerate the lack of client side LPC timeout support and address resultant crashing or hanging as it occurs. This approach is dependent on an unsatisfactory manual response to the problem. Still other approaches to addressing the lack of client timeout support require undesirable infrastructural changes at the operating system level and consequential core changes on both client subsystem and server subsystem sides at the application level.
- This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
- Conducting client-server inter-process communications is disclosed. Such communications include initiating an inter-process communication thread that is separate from a main client inter-process communication thread, where the inter-process communication thread that is separate from the main client inter-process communication thread establishes a connection with a server. A client communication port is created during the establishment of the connection with the server. One or more non-blocking asynchronous communications are transmitted to a server communication port. Responses to the one or more non-blocking asynchronous communications are awaited for receipt by the client communication port. Inter-process communications are conducted in a manner that avoids a blocking of the execution of main client processes and in a manner that avoids the memory and speed resource expenditures that are associated with maintaining a separate thread for the purpose of executing such communications.
- The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments and, together with the description, serve to explain the principles of the embodiments:
-
FIG. 1 illustrates the operation of (LPC) local procedure call. -
FIG. 2A is a block diagram of a computer system upon which a system (SCIC) for conducting client-server inter-process communications can be implemented according to one embodiment. -
FIG. 2B illustrates the operation of SCIC as a part of client server inter-process communications according to one embodiment. -
FIG. 3 shows components of a system for conducting client-server inter-process communications (SCIC) according to one embodiment. -
FIG. 4 shows a flowchart of the steps performed in a method for conducting client-server inter-process communications (SCIC) according to one embodiment. - The drawings referred to in this description should not be understood as being drawn to scale except if specifically noted.
- Reference will now be made in detail to various embodiments, examples of which are illustrated in the accompanying drawings. While embodiments will be described herein, it will be understood that these descriptions are not intended to limit the disclosed subject matter to specific embodiments. On the contrary, the embodiments are intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the subject matter disclosed herein as defined by the appended claims. Furthermore, in the following description, numerous specific details are set forth in order to provide a thorough understanding of embodiments. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of embodiments.
-
FIG. 2A is a block diagram of acomputer system 200 upon which a system (SCIC) 350 for conducting client-server inter-process communications can execute according to one embodiment. In one embodiment, SCIC 350 directs the conduction of inter-process communications between internal sub-systems (client and server) of one ormore computer programs 300 that are resident oncomputer system 200. In one embodiment, the conduction of these inter-process communications is performed in a manner that avoids a blocking of the execution of main client processes and in a manner that avoids the memory and speed resource expenditures that are associated with maintaining a separate thread for the purpose of executing such communications. - In one embodiment, SCIC 350 accomplishes this by directing the creation of a client side port that has functionality similar to that of server side local procedure call (LPC) ports (e.g., it possesses a time out function) during the establishment of a client process connection with a server side port. The creation of a client side port is discussed herein in detail with reference to
FIG. 2B . This port can be used (in combination with the server side port) in the execution communications between server and client processes and to support a dual port approach to inter-process communications. It should be appreciated that the aforementioned client side port can be used instead of a separate memory and speed burdening separate client side thread to receive communications from a server process. - In one embodiment, unlike communications between a separate client thread and a server side port associated with a server process, communications (e.g., calls) between a client side port and the server side port associated with a server process can include timeout support. Consequently, these communications may not block other client processes.
- In the
FIG. 2A embodiment,computer system 200 includes at least oneprocessing unit 202 anddata storage components 204 wherein one ormore computer programs 300 reside. In one embodiment, one ormore computer programs 300 can includeclient subsystem 340 andserver subsystem 360 as is shown inFIG. 2A . It should be appreciated that although only two subsystems are shown inFIG. 2A for clarity and brevity, one ormore computer programs 300 can include numerous internal client and server subsystems and processes. For purposes of the discussion that follows,client subsystem 340 andserver subsystem 360 represent client and server processes operating oncomputer system 200 and that engage in inter-process communications. - In one embodiment,
SCIC 350 can be encompassed by components and operations of client subsystem 340 (seeFIG. 2A ). In an alternate embodiment,SCIC 350 can be separate fromclient subsystem 340 but can operate in cooperation with components and operations thereof. - It should be appreciated that depending on the computer system (e.g., 200) configuration and type, data storage components 204 (computer readable media) can include volatile (such as RAM) and/or non-volatile (such as ROM, flash memory, etc.) components. Other data storage components that can be a part of
computer system 200 include but are not limited to CD-ROM, DVD or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed. - Similarly,
computer system 200 can also include input devices and output devices (not shown). Moreover,computer system 200 can include network connections to other devices, computers, networks servers, etc. using either wired or wireless media. All these devices are well known in the art and need not be discussed here at length. - Although
computer system 200 is shown and described inFIG. 2A as having certain numbers and types of elements, embodiments are not limited to the implementation shown inFIG. 2A . That is,computer system 200 can include elements other than those shown inFIG. 2A . Moreover,computer system 200 can include more than one of each of the elements that are shown inFIG. 2A . - It should also be noted that the computer system (e.g., 200) upon which one or more computer programs (e.g., 300) reside and upon which
SCIC 350 executes can possess a variety of forms. For example,computer system 200 can be but is not limited to being a personal desktop computer (as is shown inFIG. 2A ), a portable notebook computer, a personal digital assistant (PDA), and a gaming system. -
FIG. 2B illustrates the operation ofSCIC 350 in the context of client-server inter-process communications.SCIC 350 is shown inFIG. 2B as being encompassed byclient subsystem 340. In theFIG. 2B embodiment,SCIC 350 directs the creation of a server side communications port and inter-process communications betweenclient subsystem 340 andserver subsystem 360. - In operation, in a first phase, a server
side port object 251 a is created and thereafter handshake messages betweenclient subsystem 340 andserver subsystem 360 are exchanged that establish a connection via the serverside port object 251 a for supporting communications betweenclient subsystem 340 andserver subsystem 360. Moreover, an identification number of a client side port 255 a is passed to the server subsystem during the establishment of the connection. These operations are illustrated at 251-267 shown inFIG. 2B and are described in detail below. - Referring to
FIG. 2B , the aforementioned serverside port object 251 a is created at 251. In theFIG. 2B embodiment, serverside port object 251 a is created through the use of a server subsystem port creation call (e.g., NtCreateWaitablePort in WINDOWS™). Subsequently, at 253 a separate client subsystem inter-process communication thread (separate from a main client subsystem thread) 253 a is spawned byclient subsystem 340. Thereafter, the client side port object 255 a is created. In theFIG. 2B embodiment, client side port object 255 a is created through the use of a client subsystem port creation call 255 (e.g., NtCreateWaitablePort in WINDOWS™). - In the
FIG. 2B embodiment, the readiness of the serverside port object 251 a to receive messages is indicated by port object call readiness condition 259 (e.g., NtReplyWaitReceivePortEx in WINDOWS™). Subsequently, at 261 (as a part of the aforementioned communication thread that is separate from the main client communication thread) a port connection call 263 (e.g., a request for port access) is transmitted to serverside port object 251 a. In response, messages can be transmitted toclient subsystem 340 via the separate thread that indicate that the port connect request has been accepted 265 and completed 267. It should be appreciated that the series of message exchanges 263-267 is termed a “handshake.” In theFIG. 2B embodiment, a port identification number of client side port object 255 a can be transmitted toserver subsystem 360 during the handshake (during the establishment of the connection as indicated in the drawings). - After the initial connection has been established and the identification number of client side port object 255 a has been transmitted to the
server subsystem 360, a second handshake can be performed, this time establishing a connection between the client side port object 255 a and theserver subsystem 360. Upon the completion of the second handshake, a series of non-blocking asynchronous client side calls (e.g., messages that can terminate after a period or after being responded to) that initiate and drive exchanges between client subsystem and server system processes can be commenced as is described below. - Referring again to
FIG. 2B , the readiness of the client side port object 255 a to receive messages in order that the aforementioned second handshake can be commenced is indicated by a port object call readiness condition shown inFIG. 2B at 269 (e.g., NtReplyWaitReceivePortEx in WINDOWS™). Subsequently, at 271 a port connection call fromserver subsystem 360 can be transmitted to client side port object 255 a. In response, messages can be transmitted toserver subsystem 360 that indicate that the port connection call 271 has been accepted as shown at 273 and completed as shown at 275. - In one embodiment, measures that can be employed to avoid server subsystem side hang that may be caused by the potentially blocking port connection call 271 (port connection call 271 can block other server subsystem processes if in response to port connection call 271 port
connection acceptance message 273 and portconnection completion message 275 are not forthcoming) that is a part of the second handshake can include but are not limited to: (1) creating a separate short lived server subsystem inter-process communication thread for the second handshake, (2) using a pre-created server subsystem inter-process communication thread for the second handshake, and (3) using an available inter-process communication thread from a thread pool for the second handshake. - As discussed above, upon the completion of the second handshake that establishes a connection between
client subsystem 340 andserver subsystem 360 processes via client side port object 255 a and server side port object 351 a, non-blocking asynchronous client side calls (e.g., 279 and 287) that initiate and drive exchanges betweenclient subsystem 340 andserver subsystem 360 can be commenced (client subsystem 340 invokes aserver subsystem 360 procedure or process throughcalls - It should be appreciated that asynchronous calls such as 279 and 287 can operate independently of other processes whereas synchronous calls (such as those discussed with reference to
FIG. 1 ) are executed as a result of other processes being completed. Exemplary components ofSCIC 350 that can support the aforementioned operations ofSCIC 350 described above are described below with reference toFIG. 3 . - It should be appreciated that embodiments take advantage of server subsystem side functions that support a timeout feature and reverses
client subsystem 340 andserver subsystem roles 360 by identifying a client side port toserver subsystem 360 during the initial handshake. Because the port created on the client side can possess timeout support (unlike a separate client side thread) subsequent inter-process communications betweenclient subsystem 340 andserver subsystem 360 can use LPC with timeout support. Moreover, this can be done without the need to maintain aseparate client subsystem 340 thread throughout an LPC session. -
FIG. 3 shows components of asystem 350 for conducting client-server inter-process communications (SCIC) according to one embodiment. In one embodiment,SCIC 350 directs the conduct of inter-process communications between internal sub-systems (client and server) of one or more computer programs (e.g., 300 inFIG. 2A ) that execute on a computer system (e.g., 200 inFIG. 2A ). In one embodiment, inter-process communications are conducted in a manner that avoids a blocking of the execution of main client processes and in a manner that avoids the memory and speed resource expenditures that are associated with maintaining a separate thread for the purpose of executing such communications. - It should be appreciated that components of
SCIC 350 can be implemented in hardware or software or in a combination of both. In one embodiment,SCIC 350 can be encompassed by components and operations of a client subsystem (e.g., 340 inFIG. 2 ) of a computer program (e.g., 300 inFIG. 2 ) that executes on a computer system (e.g., 200 inFIG. 2 ). In another embodiment, components and operations ofSCIC 350 can be separate from the aforementioned client subsystem but can operate cooperatively with components and operations thereof. In theFIG. 3 embodiment, components ofSCIC 350 include inter-process communication thread initiator/generator 351, client subsystem inter-processcommunication port generator 353 and asynchronous inter-process communication transmitter 355. - Referring to
FIG. 3 , inter-process communication thread initiator/generator 351 initiates the generation of a client subsystem (e.g., 340 inFIG. 2 ) inter-process communication thread that is separate from a main client subsystem inter-process communication thread. In one embodiment, the separate client subsystem inter-process communication thread facilitates client subsystem calls that serve to establish a connection with a server subsystem so as to allow information related to the identification of a client subsystem side inter-process communications port (e.g., client side port object 255 a ofFIG. 2B ) to be passed to the server subsystem. - In one embodiment, during the establishment of a connection with the server subsystem an identification number of a client subsystem side inter-process communication port (e.g., client side port object 255 a of
FIG. 2B ) is transmitted to the server subsystem so that the server subsystem can identify the client subsystem side inter-process communication port (e.g., client side port object 255 a ofFIG. 2B ). In one embodiment, once the connection has been established the separate client subsystem inter-process communication thread can be terminated (seeFIG. 2B ). - Client subsystem inter-process
communication port creator 353 creates a client side inter-process communication port (e.g., client side port object 255 a ofFIG. 2B ) during the establishment of the connection between the client subsystem and the server subsystem. In one embodiment, the client inter-process communication port (e.g., client side port object 255 a ofFIG. 2B ) can be created in order to facilitate the conduction of client-server inter-process communications that may not rely upon the maintenance of a client subsystem thread that is separate from a main client subsystem thread. - In this manner memory and speed resource expenditures associated with the maintenance of a separate client thread are avoided. As is discussed herein, the client side inter-process communication port (e.g., client side port object 255 a of
FIG. 2B ) is created during the establishment of the connection between the client and the server via the separate thread. - Asynchronous communications transmitter 355 transmits non-blocking asynchronous inter-process communications (non-blocking calls, messages, requests etc.) to a server side inter-process communication port. In one embodiment, the client side inter-process communication port (e.g., client side port object 255 a of
FIG. 2B ) is readied to receive responses to the aforementioned one or more non-blocking asynchronous communications before the transmission of the non-blocking asynchronous inter-process communications (through the aforementioned connection process). - In one embodiment, asynchronous client subsystem calls can timeout after a predetermined period. Moreover, in one embodiment an immediate response to an asynchronous client subsystem call can terminate the client call.
-
FIG. 4 shows aflowchart 400 of the steps performed in amethod 400 for conducting client-server inter-process communications (SCIC) according to one embodiment. The flowchart includes processes that, in one embodiment can be carried out by processors and electrical components under the control of computer-readable and computer-executable instructions. Although specific steps are disclosed in the flowcharts, such steps are exemplary. That is embodiments are well suited to performing various other steps or variations of the steps recited in the flowcharts. Within various embodiments, it should be appreciated that the steps of the flowcharts can be performed by software, by hardware or by a combination of both. - Referring to
FIG. 4 , atstep 401, a client subsystem inter-process communication thread that is separate from a main client subsystem inter-process communication thread is initiated. In one embodiment, an inter-process communication thread initiator/generator (e.g., 351 inFIG. 3 ) initiates the generation of the client subsystem inter-process communication thread that is separate from a main client subsystem inter-process communication thread. In one embodiment, the separate client subsystem inter-process communication thread facilitates client subsystem calls that serve to establish a connection with a server subsystem so as to allow information related to the identification of a client side inter-process communications port (e.g., client side port object 255 a inFIG. 2B ) to be passed to the server subsystem. - At
step 403, a client subsystem inter-process communication port is created. In one embodiment, a client subsystem inter-process communication port creator (e.g., 353 inFIG. 3 ) creates the client side inter-process communication port (e.g., client side port object 255 a inFIG. 2B ) during the establishment of the connection between the client subsystem and the server subsystem. In one embodiment, the client subsystem inter-process communication port is created in order to facilitate the conduction of client-server inter-process communications that do not rely upon the maintenance of a client subsystem thread that is separate from a main client subsystem thread. - At step 405, the establishment of a connection with the server subsystem via client side inter-process communication port is completed. And, at
step 407 when the connection with the server subsystem via the client side inter-process communication port is completed the separate client subsystem inter-process communications thread is terminated. - At
step 409, one or more non-blocking asynchronous communications are transmitted to a server side inter-process communication port (e.g., serverside port object 251 a inFIG. 2B ). In one embodiment, an asynchronous communication transmitter (e.g., 355 inFIG. 3 ) transmits non-blocking asynchronous inter-process communications (non-blocking calls, messages, requests, etc.) to a server side inter-process communication port (e.g., serverside port object 251 inFIG. 2B ). In one embodiment, the client side inter-process communication port (e.g., client side port object 255 a inFIG. 2B ) is readied to receive responses to the aforementioned one or more non-blocking asynchronous communications (through the aforementioned establishment of a connection with server subsystem). - With reference to exemplary embodiments thereof, conducting client-server inter-process communications is disclosed. Such communications include initiating an inter-process communication thread that is separate from a main client inter-process communication thread, where the inter-process communication thread that is separate from the main client inter-process communication thread establishes a connection with a server. A client communication port is created during the establishment of the connection with the server. One or more non-blocking asynchronous communications are transmitted to a server communication port. Responses to the one or more non-blocking asynchronous communications are awaited for receipt by the client communication port.
- The foregoing descriptions of specific embodiments have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the subject matter to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the disclosed subject matter and its practical application, to thereby enable others skilled in the art to best utilize the disclosed subject matter and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the scope of the disclosed subject matter be defined by the Claims appended hereto and their equivalents.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/497,830 US8032900B2 (en) | 2006-08-02 | 2006-08-02 | Conducting client-server inter-process communication |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/497,830 US8032900B2 (en) | 2006-08-02 | 2006-08-02 | Conducting client-server inter-process communication |
Publications (2)
Publication Number | Publication Date |
---|---|
US20080127206A1 true US20080127206A1 (en) | 2008-05-29 |
US8032900B2 US8032900B2 (en) | 2011-10-04 |
Family
ID=39465438
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/497,830 Expired - Fee Related US8032900B2 (en) | 2006-08-02 | 2006-08-02 | Conducting client-server inter-process communication |
Country Status (1)
Country | Link |
---|---|
US (1) | US8032900B2 (en) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110029595A1 (en) * | 2009-07-31 | 2011-02-03 | Thayer Karen E | Non-blocking communication between an application and a server |
US20110106941A1 (en) * | 2009-10-30 | 2011-05-05 | International Business Machines Corporation | Processing Network Events |
US20120291038A1 (en) * | 2010-11-24 | 2012-11-15 | Clevenger Brian Duane | Method for reducing inter-process communication latency |
CN104636210A (en) * | 2013-11-07 | 2015-05-20 | 腾讯科技(深圳)有限公司 | Method and device for achieving data exchanging between progresses |
CN104750543A (en) * | 2013-12-26 | 2015-07-01 | 杭州华为数字技术有限公司 | Thread creation method, business request processing method and associated device |
CN111400055A (en) * | 2019-01-03 | 2020-07-10 | 中国移动通信集团终端有限公司 | Method, device, equipment and storage medium for communication among multiple processes |
CN111858177A (en) * | 2020-07-22 | 2020-10-30 | 广州六环信息科技有限公司 | Method and device for repairing abnormality of interprocess communication, electronic equipment and storage medium |
CN112416584A (en) * | 2020-11-18 | 2021-02-26 | 捷开通讯(深圳)有限公司 | Process communication method, device, storage medium and mobile terminal |
CN114036092A (en) * | 2021-11-16 | 2022-02-11 | 深圳市联影高端医疗装备创新研究院 | Medical equipment operation management system, method and storage medium |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109117279B (en) * | 2018-06-29 | 2020-10-02 | Oppo(重庆)智能科技有限公司 | Electronic device, method for limiting inter-process communication thereof and storage medium |
US10645196B1 (en) | 2019-04-26 | 2020-05-05 | Clario Tech Limited | Multicomponent software-controllable system and a method for interaction of server-client processes and a machine-readable carrier for performing the method |
CN113037875B (en) * | 2021-05-24 | 2021-07-27 | 武汉众邦银行股份有限公司 | Method for realizing asynchronous gateway in distributed real-time service system |
Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5682534A (en) * | 1995-09-12 | 1997-10-28 | International Business Machines Corporation | Transparent local RPC optimization |
US6131126A (en) * | 1994-07-22 | 2000-10-10 | Sun Microsystems, Inc. | Method and apparatus for space-efficient inter-process communication |
US6157959A (en) * | 1997-07-03 | 2000-12-05 | Tandem Computers, Incorporated | Method and apparatus for providing portable kernel-mode support for fast interprocess communication |
US6226689B1 (en) * | 1997-01-29 | 2001-05-01 | Microsoft Corporation | Method and mechanism for interprocess communication using client and server listening threads |
US6263456B1 (en) * | 1997-05-09 | 2001-07-17 | International Business Machines Corporation | System for remote debugging of client/server application |
US6324492B1 (en) * | 1998-01-20 | 2001-11-27 | Microsoft Corporation | Server stress testing using multiple concurrent client simulation |
US20020038340A1 (en) * | 2000-08-14 | 2002-03-28 | I2 Technologies Us, Inc. | Network application program interface facilitating communication in a distributed network environment |
US20030202522A1 (en) * | 2002-04-24 | 2003-10-30 | Ping Jiang | System for concurrent distributed processing in multiple finite state machines |
US6704768B1 (en) * | 2000-01-31 | 2004-03-09 | Aether Systems, Inc. | System, method and computer program product for providing server discovery services during a startup sequence |
US6748452B1 (en) * | 1999-03-26 | 2004-06-08 | International Business Machines Corporation | Flexible interprocess communication via redirection |
US20060167982A1 (en) * | 2005-01-07 | 2006-07-27 | Apple Computer, Inc. | Restricted media sharing over networks |
US20060168136A1 (en) * | 2004-12-02 | 2006-07-27 | Desktopsites Inc. | System and method for launching a resource in a network |
US7114106B2 (en) * | 2002-07-22 | 2006-09-26 | Finisar Corporation | Scalable network attached storage (NAS) testing tool |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0689139A3 (en) | 1994-06-22 | 1997-09-10 | Ibm | Anonymous reply port method and apparatus for a microkernel data processing system |
US6519686B2 (en) | 1998-01-05 | 2003-02-11 | Intel Corporation | Information streaming in a multi-process system using shared memory |
US7127514B2 (en) | 2000-12-28 | 2006-10-24 | Microsoft Corporation | Stateless distributed computer architecture with server-oriented state-caching objects maintained on network or client |
EP1322097A1 (en) | 2001-12-21 | 2003-06-25 | Siemens Aktiengesellschaft | A method and computer system for client server inter process communication |
US20050010925A1 (en) | 2003-07-10 | 2005-01-13 | Charbel Khawand | Interprocessor communication protocol with smart streaming port |
US7647599B2 (en) | 2003-12-22 | 2010-01-12 | Motorola, Inc. | Interprocessor communication network providing dynamic dedication of ports |
-
2006
- 2006-08-02 US US11/497,830 patent/US8032900B2/en not_active Expired - Fee Related
Patent Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6131126A (en) * | 1994-07-22 | 2000-10-10 | Sun Microsystems, Inc. | Method and apparatus for space-efficient inter-process communication |
US5682534A (en) * | 1995-09-12 | 1997-10-28 | International Business Machines Corporation | Transparent local RPC optimization |
US6226689B1 (en) * | 1997-01-29 | 2001-05-01 | Microsoft Corporation | Method and mechanism for interprocess communication using client and server listening threads |
US6263456B1 (en) * | 1997-05-09 | 2001-07-17 | International Business Machines Corporation | System for remote debugging of client/server application |
US6157959A (en) * | 1997-07-03 | 2000-12-05 | Tandem Computers, Incorporated | Method and apparatus for providing portable kernel-mode support for fast interprocess communication |
US6324492B1 (en) * | 1998-01-20 | 2001-11-27 | Microsoft Corporation | Server stress testing using multiple concurrent client simulation |
US6748452B1 (en) * | 1999-03-26 | 2004-06-08 | International Business Machines Corporation | Flexible interprocess communication via redirection |
US6704768B1 (en) * | 2000-01-31 | 2004-03-09 | Aether Systems, Inc. | System, method and computer program product for providing server discovery services during a startup sequence |
US20020038340A1 (en) * | 2000-08-14 | 2002-03-28 | I2 Technologies Us, Inc. | Network application program interface facilitating communication in a distributed network environment |
US20030202522A1 (en) * | 2002-04-24 | 2003-10-30 | Ping Jiang | System for concurrent distributed processing in multiple finite state machines |
US7114106B2 (en) * | 2002-07-22 | 2006-09-26 | Finisar Corporation | Scalable network attached storage (NAS) testing tool |
US20060168136A1 (en) * | 2004-12-02 | 2006-07-27 | Desktopsites Inc. | System and method for launching a resource in a network |
US20060167982A1 (en) * | 2005-01-07 | 2006-07-27 | Apple Computer, Inc. | Restricted media sharing over networks |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9442777B2 (en) * | 2009-07-31 | 2016-09-13 | Hewlett-Packard Development Company, L.P. | Non-blocking communication between an application and a server |
US20110029595A1 (en) * | 2009-07-31 | 2011-02-03 | Thayer Karen E | Non-blocking communication between an application and a server |
US20110106941A1 (en) * | 2009-10-30 | 2011-05-05 | International Business Machines Corporation | Processing Network Events |
US8930526B2 (en) * | 2009-10-30 | 2015-01-06 | International Business Machines Corporation | Processing network events |
US20120291038A1 (en) * | 2010-11-24 | 2012-11-15 | Clevenger Brian Duane | Method for reducing inter-process communication latency |
US8726287B2 (en) * | 2010-11-24 | 2014-05-13 | Thomson Licensing | Method for reducing inter-process communication latency |
US9965341B2 (en) * | 2013-11-07 | 2018-05-08 | Tencent Technology (Shenzhen) Company Limited | Method and device for exchanging data between processes |
US20160253225A1 (en) * | 2013-11-07 | 2016-09-01 | Tencent Technology (Shenzhen) Company Limited | Method and device for exchanging data between processes |
CN104636210A (en) * | 2013-11-07 | 2015-05-20 | 腾讯科技(深圳)有限公司 | Method and device for achieving data exchanging between progresses |
CN104750543A (en) * | 2013-12-26 | 2015-07-01 | 杭州华为数字技术有限公司 | Thread creation method, business request processing method and associated device |
CN111400055A (en) * | 2019-01-03 | 2020-07-10 | 中国移动通信集团终端有限公司 | Method, device, equipment and storage medium for communication among multiple processes |
CN111858177A (en) * | 2020-07-22 | 2020-10-30 | 广州六环信息科技有限公司 | Method and device for repairing abnormality of interprocess communication, electronic equipment and storage medium |
CN112416584A (en) * | 2020-11-18 | 2021-02-26 | 捷开通讯(深圳)有限公司 | Process communication method, device, storage medium and mobile terminal |
CN114036092A (en) * | 2021-11-16 | 2022-02-11 | 深圳市联影高端医疗装备创新研究院 | Medical equipment operation management system, method and storage medium |
Also Published As
Publication number | Publication date |
---|---|
US8032900B2 (en) | 2011-10-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8032900B2 (en) | Conducting client-server inter-process communication | |
US11848979B1 (en) | Method to determine use of local and remote applications in a distributed multiuser environment for shared file resources | |
US10142425B2 (en) | Session reliability for a redirected USB device | |
US8140688B2 (en) | Method and system for establishing connections between nodes in a communication network | |
CN108681777B (en) | Method and device for running machine learning program based on distributed system | |
WO2019000871A1 (en) | Method and device for providing voice service, and server | |
WO2019019864A1 (en) | Communication system, method and apparatus for embedded self-service terminal | |
JP6595625B2 (en) | Automatic recharge system, method and server | |
US10904238B2 (en) | Access token management for state preservation and reuse | |
US10924590B1 (en) | Virtual workspace experience visualization and optimization | |
US10621124B2 (en) | Method, device and computer program product for enabling SR-IOV functions in endpoint device | |
CN114296953A (en) | Multi-cloud heterogeneous system and task processing method | |
US10523741B2 (en) | System and method for avoiding proxy connection latency | |
US10999362B1 (en) | Seamless switching of terminal servers in remote-access computing environments | |
JP6899907B2 (en) | Technology for scaling user interface backend clusters for database bound applications | |
US20240022670A1 (en) | Scanning preview method in scanner redirection | |
KR20220167217A (en) | Method and apparatus for blockchain system startup, device, and storage medium | |
US20160232251A1 (en) | Continuously blocking query result data for a remote query | |
WO2014171965A1 (en) | Website server request rerouting | |
US20100095006A1 (en) | Efficient selection of a messaging multiplexed channel instance | |
US20180254970A1 (en) | Methods and Devices for Testing Applications | |
WO2023226787A1 (en) | Communication method, system, and apparatus, and electronic device | |
US20240036939A1 (en) | Deterministic execution of background jobs in a load-balanced system | |
CN108810087B (en) | Connection method, system and equipment of storage server | |
US20210368008A1 (en) | Network resource access |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: MICROSOFT CORPORATION, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LEONOV, MIKHAIL V;FEIVESON, ERIC H;REEL/FRAME:018165/0096 Effective date: 20060731 |
|
ZAAA | Notice of allowance and fees due |
Free format text: ORIGINAL CODE: NOA |
|
ZAAB | Notice of allowance mailed |
Free format text: ORIGINAL CODE: MN/=. |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034542/0001 Effective date: 20141014 |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 8 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20231004 |