CN102833080A - Process-to-process communication method of application software and system - Google Patents

Abstract

The invention relates to a process-to-process communication method of application software and a system. The method comprises receiving registration information of a client through a daemon module; and monitoring, forwarding and responding to service request information of the client, and comprises the specific steps of a client A sending a service request to the daemon module to request the daemon module to return one or more services provided by a client B; the daemon module forwarding the service request of the client A to the client B after receiving the service request sent by the client A; the client B processing the service request of the client A, and returning the processing result to the daemon module; and the daemon module returning the processing result of the client B to the client A. The process-to-process communication method provided by the invention is independent of the operation system, and the same software can be operated on different operation systems, thereby facilitating quick software project development by technicians, and reducing the software development and maintenance cost.

Description

A kind of inter-process communication methods of application software and system

Technical field

The present invention relates to computer realm, relate in particular to a kind of inter-process communication methods and system of application software, specifically, the present invention relates to a kind of communication software and inter-process communication methods operating system independent and system.

Background technology

Process is the elementary cell that operating system is dynamically carried out, and is the program implementation process.Sometimes need communicate for collaborative work between process and the process.

In the most widely used operating system such as Windows and linux system at present; The method that has multiple interprocess communication; Specifically; There are anonymous pipeline, named pipes, mailslot and shared drive in the Windows system, and linux system then has pipeline, named pipes, message queue, shared drive and semaphore.Although so pipeline and shared drive are all arranged in Window and the linux system, they also have some differences in the use.For example, the named pipes of Windows is supported full duplex, can across a network, and the named pipes of Linux is only supported half-duplex, can not across a network.The technical staff is when one of exploitation relates to the software project of communication like this; If want to let this project support a plurality of operating systems simultaneously; Just have to write a cover software code respectively according to the bottom API (Application Programming Interface, API) that each operating system provides.The complexity that this not only can increase item code also can increase the project maintenance cost.

Summary of the invention

Main purpose of the present invention is to provide a kind of inter-process communication methods and system of application software, makes communication and operating system independent between the process.

The invention discloses a kind of inter-process communication methods of application software, be used for the communication between client process A and the client process B, perhaps client process A and the client process B broadcast service that will respond respectively; May further comprise the steps:

Steps A: client process A sends services request to the finger daemon module, requires to return one or more services that client process B provides;

Step B: said finger daemon module is transmitted to said client process B after receiving the services request that said client process A sends;

Step C: said client process B receives and handles the services request of said client process A, and result is returned to said finger daemon module;

Step D: said finger daemon module returns to said client process A with the result of said client process B.

Before said steps A, can also may further comprise the steps:

Said finger daemon module starts and sets up a socket, is used to monitor and wait for client's register requirement and services request;

Said client process A sends register requirement to said finger daemon module, comprises client's log-on message in the request;

Said finger daemon module monitors is saved in the log-on message of said client process A in the database and returns the message that succeeds in registration after the register requirement of client process A.

Can comprise in the said log-on message service that customer name, client provide and client the broadcast that will respond.

Said finger daemon module monitors checks at first whether the customer name of said client process A registration exists, if there has been information from registration failure to said client process A that then return after the register requirement of client process A.

In said step B; After said finger daemon module is received the services request that said client process A sends; At first check the log-on message that whether has client process B in the data,, otherwise get into following steps if there is not the information of then returning the services request failure to said client process A:

Further whether there is said client process A requested service in the log-on message of inspection client process B; If exist the services request of then said client process A being sent to be transmitted to said client process B, otherwise return the information of services request failure to said client process A.

The invention also discloses a kind of interprocess communication system of application software, comprise the finger daemon module, be used to receive client's log-on message, the service request information of monitoring, forwarding and customer in response; Said finger daemon module further comprises:

The services request receiver module is used to receive one or more services request that the client sends;

The services request forwarding module is used for one or more services request that said client sends are transmitted to the ISP;

The service result receiver module is used to receive the service response result that said ISP provides;

Service result is returned module, is used for the service response result that said ISP provides is returned to said client;

Said services request module, said services request forwarding module and said service requester are linked in sequence, and said service requester also returns sequence of modules with said service result receiver module, said service result and is connected.

Said finger daemon module can also comprise:

The socket module is used to monitor and wait for register requirement and the services request that the client sends;

The register requirement receiver module is used to receive the register requirement that the client sends.

Said finger daemon module can further include:

The log-on message processing module is used to check whether the customer name of client enrollment exists, and then returns the information of registration failure to said client if exist, otherwise preserves said client's log-on message and return the message that succeeds in registration.

Said finger daemon module can further include:

Services request inspection module is used for checking whether database exists specified ISP of client and service content.

The inter-process communication methods of a kind of application software disclosed by the invention and system because have the finger daemon module, utilize the network service API of operating system bottom, for carrying out the communication of operating system independent between different client processes; When the technical staff relates to the software project of communication in exploitation, needn't be every kind of operating system stand-alone development one cover code all, reduce the complexity of code, reduce Development of Software and maintenance cost.

Description of drawings

Fig. 1 is the flow chart of inter-process communication methods of the present invention.

Fig. 2 is the data structure sketch map of finger daemon module of the present invention.

Fig. 3 is the register requirement method flow diagram afterwards of finger daemon resume module client process of the present invention.

Fig. 4 is the method flow diagram of the register requirement of finger daemon resume module client process of the present invention.

Fig. 5 is the method flow diagram of finger daemon resume module user's of the present invention services request.

Fig. 6 is the block diagram of the interprocess communication system of application software of the present invention.

Embodiment

Below in conjunction with accompanying drawing and embodiment the present invention is done further explain.

Each different operating systems is basically all followed the Unix network communications standards at present, though may there be different encapsulation in different operating systems, the network service API of bottom is basic identical.The present invention has utilized the consistent situation of the bottom-layer network of different operating system communication API, through the encapsulation of inside, has formed and the irrelevant convenient and practical inter-process communication mechanisms of underlying operating system.At first introduce the interprocess communication system of operating system independent of the present invention below.

The present invention adopts as gives a definition: finger daemon, this process are responsible for receiving client enrollment/cancel, forwards, system message broadcasting and are realized client's monitoring.Client process, the promoter or the recipient of representative communication.

The present invention discloses a kind of inter-process communication methods of operating system independent, not direct communication between the client process, but through the finger daemon forwarding information, the network service API through bottom between finger daemon and the client process gets in touch.The finger daemon module is used to receive client's log-on message, the service request information of monitoring, forwarding and customer in response; In order to make the present invention be convenient to understand, below earlier the finger daemon module is elaborated.

As shown in Figure 1 is the flow chart of inter-process communication methods of the present invention, and as one embodiment of the present of invention, the communication between client process A and the client process B may further comprise the steps:

1, client process A carries out client enrollment to the finger daemon module;

2, the finger daemon module is returned the client process A information that succeeds in registration;

3, client process A proposes services request to the finger daemon module;

4, the finger daemon module proposes services request to client process B;

5, client process B returns result to the finger daemon module;

6, the finger daemon module is returned result to client process A.

As shown in Figure 2 is the data structure sketch map of finger daemon module of the present invention; Said finger daemon module stores has client's log-on message, the number of users of current register and the system broadcast message number of current register, said client's log-on message comprise service that customer name, client provide, client the broadcast that will respond.Each client can be with the title of oneself, own available service and own will corresponding broadcast being registered in the finger daemon module; Thereby the finger daemon module can start the supervision to client's behavior; When a client need use the service of another client enrollment, the finger daemon module can provide related service for this client.

The finger daemon module starts and sets up a socket, is used to monitor and wait for client's register requirement and services request.

There is client process A to send register requirement among Fig. 2, comprises client's log-on message in the request to said finger daemon module.

Client process A when registration, the log-on message that needs to submit to comprise customer name, the available service of client self and client the broadcast that will respond, this service that can provide is a kind of incessantly, more than one of the broadcast that respond.The finger daemon module can be according to the information of client process A registration, for client process A sends its broadcast that need listen to like this.Simultaneously, when other clients needed client process A that service is provided, the finger daemon module can be transmitted the service content of client A for other clients.

Said finger daemon module monitors is saved in the log-on message of said client A in the database and returns the message that succeeds in registration after the register requirement of client A.

Understand easily, the above-mentioned functions of finger daemon module can realize through various programming languages, is example with the JAVA programming language below, introduces the implementation method of finger daemon module.The implementation method of said finger daemon module is following:

At first define the data structure that is used to receive and store client enrollment information in the finger daemon module, concrete JAVA code is:

Struct?client_register

{

String?registerName;

Unsigned int registerID; // finger daemon distributes

。。。。。。。。。// other data members

List < struct server*>listServer; The service chained list that // client registered

List < struct signal*>listSignal; The broadcast chained list of the needs response that // client registered

};

Struct?daemon_register

{

String version; // current version

Unsigned int startTime; // finger daemon start-up time

Unsigned int clientNum; The number of users of // current register

Unsigned int signalNum; The system broadcast message number of // current register

List < struct client_register*>listClient; // current client enrollment information chained list

// other data members

}

Define each basic interface in the finger daemon module then; Comprise customer information registration interface, broadcast registration interface, broadcast transmission interface, message request interface, message sink interface, message transmission interface; Be used to monitor, the service request information of forwarding and customer in response, perhaps the log-on message according to the client directly sends the needed broadcast of client for the client.The define method of described each interface is following:

Int?register(const?char*?pRegisterName)

Function: customer information registration

Parameter: const char* pRegisterName representes login name

Return value: 0 representes successfully, greater than 0 expression error code;

Int?register_signal(const?char*?pRegisterName)

Function: broadcast registration

Parameter: const char* pRegisterName representes the broadcast name

Return value: 0 representes successfully, greater than 0 expression error code;

Int?register_call(const?char*?pRegisterName)

Function: message request

Parameter: const char* pRegisterName representes message name

Return value: 0 representes successfully, greater than 0 expression error code;

Int?message_receive(MESSAGE*?pMsg)

Function: message sink

Parameter: MESSAGE* pMsg representes the message that receives

Return value: 0 representes successfully, greater than 0 expression error code;

Void?signal_send(MESSAGE*?pMsg)

Function: broadcast is sent

Parameter: the broadcast that MESSAGE* pMsg indicates to take place

Return value: do not have;

MESSAGE*?call_send(MESSAGE*?pMsg)

Function: message is sent

Parameter: the message that MESSAGE* pMsg indicates to send

Return value: the result of returning;

The data structure and the interface definition of finger daemon module of the present invention have below been introduced in detail; Through the finger daemon module; No matter client A and client process B can communicate, and that is to say that the process of client A can directly carry out communicating by letter of operating system independent with the process of client process B.Data structure is a term in the software; The data structure definition of finger daemon module is the key that its function realizes.

Shown in Figure 3 is the method flow diagram of finger daemon module of the present invention monitor communication demand after client A registration connects; After client A registration is accomplished, the finger daemon module keep watch on through socket and etc. to be connected, judge whether new client requests repeatedly, have and then create new thread, and through this new thread of finger daemon resume module.

Shown in Figure 4 is the flow chart of the thread of finger daemon resume module registration request from user of the present invention; The finger daemon module monitors can be created a new thread after have a client to send register requirement, and simultaneously said socket continues the register requirement that other clients of monitoring send.After said new thread is created; Whether the customer name of at first checking said client A registration exists; If had information from registration failure to said client A that then return, otherwise the log-on message of client A is added in the database, the log-on data that renewal is relevant is simultaneously also returned and is succeeded in registration.In the embodiment of the invention, database can realize that for example, the service of client enrollment (being the available service of client self) can be kept in the service chained list with the structure chained list, and the client wants corresponding broadcast then to be kept in the broadcast chained list.

Shown in Figure 5 is the method flow diagram of finger daemon resume module user's of the present invention services request.Client A sends services request to said finger daemon module, requires to return one or more services that client B provides.

Said finger daemon module checks at first whether client B exists, and does not exist, and then returns failure information.And then check that whether client B exists this service, does not exist and then returns failure information.

Said finger daemon module is transmitted the services request that said client A sends to said client B after receiving the services request that said client A sends.

Said client B handles the services request that said client A sends, and result is returned to said finger daemon module.

If said client B need not to handle the services request of said client A, then flow process finishes.

Said finger daemon module returns to said client A with the result of said client B.

As shown in Figure 6 is the block diagram of the interprocess communication system of application software of the present invention.Comprise the steps:

The finger daemon module starts and sets up a socket, is used to monitor and wait for client's register requirement and services request.

Client A sends register requirement to said finger daemon module, comprises client's log-on message in the request.

Said finger daemon module monitors is saved in the log-on message of said client A in the database and returns the message that succeeds in registration after the register requirement of client A.

Client A sends services request to said finger daemon module, requires to return one or more services that client B provides.

Said finger daemon module is transmitted the services request that said client A sends to said client B after receiving the services request that said client A sends.

Said client B handles the services request that said client A sends, and result is returned to said finger daemon module

Said finger daemon module returns to said client A with the result of said client B.

In sum; The present invention can establish a communications link for the client who is positioned at different operating system through finger daemon module of definition, that is to say between different clients' process and can carry out the communication of operating system independent; Thereby the technical staff is when exploitation communication class project; Needn't be every kind of operating system exploitation one cover code, can reduce the complexity of code, reduce development and maintenance cost.

The above is merely preferred embodiment of the present invention, not in order to restriction the present invention, all any modifications of within spirit of the present invention and principle, being done, is equal to and replaces and improvement etc., all should be included within protection scope of the present invention.

Claims (9)

1. the inter-process communication methods of an application software is used for the communication between client process A and the client process B, perhaps client process A and the client process B broadcast service that will respond respectively; It is characterized in that: may further comprise the steps:

Steps A: client process A sends services request to the finger daemon module, requires to return one or more services that client process B provides;

Step B: said finger daemon module is transmitted to said client process B after receiving the services request that said client process A sends;

Step C: said client process B receives and handles the services request of said client process A, and result is returned to said finger daemon module;

Step D: said finger daemon module returns to said client process A with the result of said client process B.

2. the inter-process communication methods of operating system independent according to claim 1 is characterized in that, and is further comprising the steps of before said steps A:

Said finger daemon module starts and sets up a socket, is used to monitor and wait for client's register requirement and services request;

Said client process A sends register requirement to said finger daemon module, comprises client's log-on message in the request;

Said finger daemon module monitors is saved in the log-on message of said client process A in the database and returns the message that succeeds in registration after the register requirement of client process A.

3. the inter-process communication methods of operating system independent according to claim 2 is characterized in that: comprise in the said log-on message service that customer name, client provide and client the broadcast that will respond.

4. the inter-process communication methods of operating system independent according to claim 2; It is characterized in that: said finger daemon module monitors is after the register requirement of client process A; Whether the customer name of at first checking said client process A registration exists, if there has been information from registration failure to said client process A that then return.

5. the inter-process communication methods of operating system independent according to claim 1; It is characterized in that: in said step B; After said finger daemon module is received the services request that said client process A sends; At first check the log-on message that whether has client process B in the data,, otherwise get into following steps if there is not the information of then returning the services request failure to said client process A:

Further whether there is said client process A requested service in the log-on message of inspection client process B; If exist the services request of then said client process A being sent to be transmitted to said client process B, otherwise return the information of services request failure to said client process A.

6. the interprocess communication system of an application software is characterized in that: comprise the finger daemon module, be used to receive client's log-on message, the service request information of monitoring, forwarding and customer in response; Said finger daemon module further comprises:

The services request receiver module is used to receive one or more services request that the client sends;

The services request forwarding module is used for one or more services request that said client sends are transmitted to the ISP;

The service result receiver module is used to receive the service response result that said ISP provides;

Service result is returned module, is used for the service response result that said ISP provides is returned to said client;

Said services request module, said services request forwarding module and said service requester are linked in sequence, and said service requester also returns sequence of modules with said service result receiver module, said service result and is connected.

7. interprocess communication according to claim 6 system, it is characterized in that: said finger daemon module also comprises:

The socket module is used to monitor and wait for register requirement and the services request that the client sends;

The register requirement receiver module is used to receive the register requirement that the client sends.

8. interprocess communication according to claim 7 system, it is characterized in that: said finger daemon module also comprises:

The log-on message processing module is used to check whether the customer name of client enrollment exists, and then returns the information of registration failure to said client if exist, otherwise preserves said client's log-on message and return the message that succeeds in registration.

9. according to each described interprocess communication system of claim 6 to 8, it is characterized in that: said finger daemon module also comprises:

Services request inspection module is used for checking whether database exists specified ISP of client and service content.

Images