CN100392599C - Universal interprocess communication achieving method - Google Patents
Universal interprocess communication achieving method Download PDFInfo
- Publication number
- CN100392599C CN100392599C CNB2006100489780A CN200610048978A CN100392599C CN 100392599 C CN100392599 C CN 100392599C CN B2006100489780 A CNB2006100489780 A CN B2006100489780A CN 200610048978 A CN200610048978 A CN 200610048978A CN 100392599 C CN100392599 C CN 100392599C
- Authority
- CN
- China
- Prior art keywords
- service
- data
- client
- information
- service end
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The present invention relates to a realization method for interprocess communication, which provides a realization method for universal interprocess communication and realizes application independence on data formats. The method comprises the following steps: a client end starts services; the client end calls services, parameters are packed and serialized, and called correlated data information is packed into information packets of data parameters without types; a service end carries out processing and call, return information packets are unpacked by the client end, and after packing information is extracted for processing, the information is packed again into information packets of data parameters without types for return; the client end unpacks return information packets, and after data is extracted, the values of parameters of calling positions are covered; the service end closes services. The technique of function call among Windows processes can be encapsulated by designing a universal and simple data interface to realize details and improve the developing efficiency of programmers. The method is suitable for callers and service providers simultaneously, avoids the problems of protocol compatibility and versions of client ends and has wide application ranges.
Description
Technical field
The present invention relates to a kind of interprocess communication implementation method.More particularly, the present invention relates to realize on a kind of data layout use the universal interprocess communication implementation method of independence.
Background technology
Under 16 environment of Windows (Windows 3.1/3.2), all window applications are shared single address, any process can both be carried out read-write operation to the content in this space (comprising the internal memory that belongs to other processes), but even the data of accessing operation system itself, so just may destroy the data segment code of other programs.
For the purpose of safety, each process all has the address space of oneself under Windows 32 environment, the internal storage data that WIN32 process can not another process of access.Two processes can be with the pointer addressing with identical value, but will be mapped to different physical addresss.Just their data separately of being read and write have so just reduced the phase mutual interference between the process.Such as: stated a pointer P at process A, this pointer can only be used by this process A, uses P in other processes B, will cause fatal problem, and Windows forbids its operation.Realized like this each process execution environment is protected and isolated.This also is the basic function that operating system will realize.
Under the WIN32 environment, each WIN32 process has the address space of 4GB, but does not represent it really to have the actual physics internal memory of 4GB, and is the virtual address space that operating system utilizes the Memory Allocation function of CPU to provide.In the ordinary course of things, most virtual addresses do not have physical memory in its correspondence, before really can using these address spaces, also will provide actual physical internal memory (this process is " submission " commit) by operating system.Under different situations, the physical memory that system is submitted to is different, may be RAM, also may be the virtual memory of hard disk simulation.
In the actual application, usually need swap data between each process of Windows, carry out data communication.WIN32 API provides many functions to make us can make things convenient for the communication of carrying out efficiently between process, and we can control the exchanges data between different processes by these functions, just as in WIN16 local process being carried out read-write operation.
Common Windows uses IPC technology (IPC:Inter-Process Communication, interprocess communication) and mainly contains following several:
Use clipbook:, provide support among the CWnd in the normal mode of using of 16 epoch.Because the occasion that clipbook uses is a lot, occur the situation of conflict easily, and efficient is not high.
Dynamic data exchange (DDE): its mode is the manual lot of data of placing in a global memory, uses window message to transmit the internal memory pointer then.This is the mode of using in 16 WIN epoch, because do not had the overall situation and local memory under WIN32, it is exactly that void is deposited that present internal memory has only a kind of.So this method is invalid under WIN32.
Message pipeline (anonymous pipeline Anonymous Pipes, named pipes Named Pipes): it need set up a channel between program, can read and write data as the flat file of application access of oneself by this channel.Defective: service end has to operate at Windows NT/2000/XP.
Mailslot (Mailslots): broadcast operation, the new method that provides in the WIN32 system can realize across a network, but only supported the mailslot client under WIN9X at different main frame swapping datas.Service end has to operate at Windows NT/2000/XP.
Windows socket (Windows Socket), TCP/IP mode: this pattern is observed a cover communication standard, possesses all functions of message pipeline, and can allow can mutual communication between the application program on the different operating system.It is relatively good that this mode is used for network facet, but be used for the communication between local process, and efficient is not high.
COM/DCOM: the counterfoil mode of acting on behalf of by the COM system is carried out exchanges data between process, but transmits data when being merely able to show the docking port function calls, can transmit data between different main frames by DCOM.
RPC: remote procedure call, call method more complicated.Seldom use, because of the RPC of itself and UNIX incompatible.
Send WM_COPYDATA message to another process: the transmission read-only data can be used the WM_COPYDATA message among the Win32.This message allows to transmit read-only data between process, returns but can not handle, and available shared drive remedies the passback data.The SDK document recommends the user to use the SendMessage function, and reciever does not return before copying data is finished, and transmit leg just can not deletion and modification data like this.
The method of above-mentioned realization IPC all is the universal method that provides in the Windows operating system.List is sayed from technical standpoint, can select one directly to use.And from application point, be not a total solution, there are such-and-such defective and deficiency more or less.Below these problems are made and described explanation.
1, fails to make up complete service end, client application model, use inconvenient
In actual application, we need the computation model of a client/server.Provide the data respond services by service end, client sends command request.In addition, in communication process, also need to consider the problem of transmission of data layout.It similarly is the TCP/IP host-host protocol.Modes such as shared drive above-mentioned, DDE, this model of all being unrealized.
Though mailslot has possessed certain characteristic,, after service end is received information, can't write data to client and return because be individual event communication.The message pipeline has possessed model of client, but the restriction of use is arranged, and service end has to operate at the operating system of Windows Server Systems series.
We need make up the model of similar message pipeline, also will avoid the version restriction of Windows operating system.
2, do not consider the problem of interface related argument sequenceization, interface generality and ease for use
In communication patterns such as message pipeline, can use elongated character stream to realize the conventional data transmission, and not provide argument sequence algorithm and the realization that is more conducive to use.Like this, pretty troublesome in the process of using.All need the data set of given parameter is made into character stream at every turn, be pressed into the data consistent with client and need separate this data stream in service end.These all are unrealized in standard I PC communication means.
3, do not consider efficient and concurrent invocation problem
Existing many IPC communication modes, though accomplished in various ways striding course communication, efficient and concurrent problem are not considered.In application, often run into the problem that needs the concurrent invocation service.
In such cases, use shared drive, DDE isotype merely, can not solve the concurrent invocation internal memory and use collision problem.And we know, the message pipe modes exists service end to use Windows operating system version restricted problem.
Summary of the invention
Fundamental purpose of the present invention is to overcome deficiency of the prior art, by setting up the SSIPCall instrument, provides the universal interprocess communication implementation method that has realized using independence on a kind of data layout.
In order to solve the problems of the technologies described above, the present invention is achieved by the following technical solutions:
The invention provides a kind of universal interprocess communication implementation method, this method comprises:
Service end starts service;
Client call service to parameter packing, serializing, is packaged into the related data information of calling the packets of information of no categorical data parameter;
Service end is handled and to be called, and the packets of information of receiving is unpacked, and after extracting packing data and processing, the packets of information that is repackaged into no categorical data parameter is returned;
Client unpacks the return message bag, covers after the extraction data and calls place's parameter values;
Service end is closed service;
The described service of calling comprises:
Client application shared drive is used as the service end write back information;
Client finds service window, and uses service window to send message;
In the service end window procedure, obtain client data, and call call back function;
The service end call back function is handled, and realizes the data backfill;
Client obtains data and returns according to the shared drive of application;
Described shared drive, can't help service end and be responsible for sharing in advance, call by caller at every turn and before service window, apply for a shared drive, the internal memory name that service window distributes client passes to service end, after service end is called and is finished, according to this name data message is write back to shared drive, client is returned from this shared drive zone acquired information.
As a kind of improvement of the present invention, described no categorical data parameter comprises the data and the pointer data length information of no type pointer.
As a kind of improvement of the present invention, a plurality of service windows that adhere to different threads separately simultaneously can walk abreast in the service processes of client and service end, usage policy calculated each service window task actual figure when client was sought service window, therefrom selected the service window of less task actual figure.
As a kind of improvement of the present invention, the implementation that the client and server end is packed, unpacked parameter is:
Parameter information universal architecture body of client structure copies to the buffer zone, forms the IPC binary data stream order bag that comprises command number, number of parameters, parameter length and parameter buffer memory;
Stream format data is passed to service end;
Service end form according to a preconcerted arrangement with reduction of data, obtains the data layout before the client serializing.
As a kind of improvement of the present invention, a plurality of service windows that adhere to different threads separately simultaneously can walk abreast in the service processes of client and service end, each service thread comprises the shared information of visit lock, parameter information district and service block of information, and identical service thread can be used this shared information when storage allocation.
Compared with prior art, the invention has the beneficial effects as follows:
By designing general, as to be simple and easy to a usefulness data-interface, the technology that encapsulates function call between the Windows process realizes details, improves the development efficiency of programmer.Function call is divided caller and two roles of ISP, the present invention is applicable to caller and ISP's (being called for short client and service end later on) simultaneously, has avoided the protocol-compliant and the version problem of service end, client.SSIPCall provides standard WIN32 api interface, being convenient to each speech like sound (comprising VC++, Delphi, VB, C# etc.) like this calls, and it can be moved on all Windows 32-bit operating systems such as Windows95/98/98SE/ME/NT4.0/2000/XP/2003, usable range is extensive.
Description of drawings
Fig. 1: SSIPCall illustraton of model;
Fig. 2: client, service end argument sequence process model;
Fig. 3: SSIPCall mechanism A illustraton of model;
Fig. 4: SSIPCall mechanism B illustraton of model;
Fig. 5: SSIPCall multithreading implementation model figure;
Fig. 6: function parameter memory model figure;
Fig. 7: argument sequence process synoptic diagram;
Fig. 8: SSIPCall serializing and reduction implementation procedure synoptic diagram;
Fig. 9: the form synoptic diagram of order bag (IPC binary stream);
Figure 10: many service calls of IPCall illustraton of model.
Embodiment
With reference to figures 1 through 4, will describe the present invention below.
As shown in Fig. 1,2, present embodiment provides the universal interprocess communication implementation method that has realized using independence on a kind of data layout by setting up the SSIPCall instrument, and this method comprises:
Service end starts service;
Client call service to parameter packing, serializing, is packaged into the related data information of calling the packets of information of no categorical data parameter;
Service end is handled and to be called, and the packets of information of receiving is unpacked, and after extracting packing data and processing, the packets of information that is repackaged into no categorical data parameter is returned;
Client unpacks the return message bag, covers after the extraction data and calls place's parameter values;
Service end is closed service.
This method has following feature:
1) application program based on SSIPCall is divided into customer end A, service end B, SSIPCall realize three parts of DLL (C).
SSIPCall realizes that DLL is the SSIPCall instrument.It is a basic Windows DLL module.For customer end A and service end B provide communication mechanism.Customer end A and service end B are actually two processes.
2) key element of customer end A comprises:
A1: a general data-interface allows SSIPCall can satisfy different business demands;
A2: parameter is packed, serializing, the relevant data message of client call is packaged into the packets of information of certain-length;
A3: data unpack, duplicate, and after the service end handle calls and finishes dealing with, have return message to give client, and client unpacks these information, and A3 is the anti-process of A2.Duplicate, after data were extracted from universal data interface, what cover client called place's parameter values.
Conventional data about A1 can elaborate in the back.
3) key element of service end B comprises:
B1: parameter unpacks, and service end after receiving the client call signal extracts packing data, unpacks.
B2: the data layout after service end unpacks, B2=A1 at present.Like this, service end can obtain and the preceding consistent data of client packing.Realized communicating by letter and called the transparence of details concerning caller.
B3: after service end service routine section is taken the data of B2 form, calling of customer end A processed.And the data in the modification B2.
B4: service end finally is packaged into intermediate form to amended B2 again, so that communication.
After this, customer end A unpacks by 3 pairs of return results information of steps A, and copies the data to and call the place.
3) basic procedure between customer end A and the service end B is:
Service end B starts service;
The customer end A service of calling (by the FunCall function of SSIPCall);
Service end B service code section is handled and to be called, and processes and return;
Customer end A obtains return data, unpacks the back covering and calls place's parameter values;
After service end B closes service, client will be called overstepping the time limit, malloc failure malloc by retry in a time range.
4) the core DLL of SSIPCall instrument realizes file, and the data transfer mechanism between process is provided, and this is transparent to the user.Wherein used " shared drive " mechanism of Windows, transmitted the basis as data between process.
The environment of types of applications is not quite similar, and some memory configurations is bigger, and some configuration is less.Consider the situation that can be applicable to big internal memory, satisfy complicated applications; Also can satisfy basic the application with less internal memory.In addition, also need to consider not make application program to use the internal memory situation bigger upheaval to occur, avoid occurring memory overflow.SSIPCall provides two kinds of Memory Allocation patterns, is respectively at the client storage allocation with at the service end storage allocation.Introduce two kinds of models below respectively.
Model A: initiatively share parameter internal memory (static allocation) (Fig. 3) by service end:
Under this pattern, after service end starts service window, (the internal memory application is relatively large to open a memory-mapped, can allow several call concurrent), and this region of memory carried out subregion, each zone is handled and is once called, divide a plurality of zones, the function call of concurrent processing is so simultaneously used different region of memorys between each is handled, and no datat information is disturbed mutually.
Call and be divided into 5 steps substantially:
The distribution in client process shared drive zone obtains the call number of a unappropriated shared drive subregion;
Client finds service window, and uses SendMessage to send message;
In the service end window procedure, call call back function (in window procedure, obtain the parameter internal memory according to call number, and pointer as parameter, call call back function);
The service end call back function is handled, and realizes data backfill (in the call back function, resolve the data content that client is used, execution is called related service function, class function, and the result is backfilling into the client internal memory);
Client obtains data and returns (region of memory of return message use here and the region of memory of using as parameter just now are same, and the shared drive zone of distribution is the conduct inlet both, again the carrier of conduct outlet return message) according to call number.
Model B: client is each dynamically applies for shared drive (dynamic assignment) (Fig. 4):
Under this pattern, the not responsible shared drive in advance of service end calls by caller at every turn and apply for a shared drive before SendMessage, and SendMessage tells service end the internal memory name that client is distributed.After service end is called and finished, data message is write back to shared drive according to this name.Client from then on shared drive zone acquired information is returned.
Invoked procedure also can be divided into 5 steps:
Client application shared drive, (name of shared drive has been used GUID in order not repeat, and the algorithm of GUID has determined that each function call can not be applied for out the shared drive of repetition name as service end write back information usefulness.Like this, under the situation of multithreading, can the phase mutual interference between the parameter information that at every turn calls);
Client finds service window, and uses SendMessage to send message;
In the service end window procedure, obtain client data, and call call back function (in window procedure, the write-back pointer that obtains supplemental characteristic and shone upon by shared drive calls call back function);
The service end call back function is handled, and realizes data backfill (in the call back function, the analytic parameter data are carried out the related service function calls, and the result is backfilling into the client internal memory, and in the client application, name has passed to service end);
Client obtains data and returns according to the shared drive of application
(under this pattern,, used character string here as parameter because will in SendMessage, pass to the service end window to the shared drive name that the client application obtains.Under windows platform, can only realize by sending WM_COPYDATA message when realizing) with SendMessage.
Being compared as follows shown in the table of model A and Model B:
As complete, an adaptable product SSIPCall, model A and Model B have all obtained realization, and they all have separately characteristic and speciality, are not to be substitutional relation.
| Compare content | Model A | Model B |
| The Memory Allocation mode | At the service end storage allocation.Static allocation.Size is relevant with Thread Count. | The client storage allocation.Dynamic assignment.When calling at every turn, distribute by client, and the internal memory name of client is passed through parameter notification service end. |
| Thread mode and burse mode | Support multithreading.The number of threads parameter configuration.Can not call again when concurrent invocation reaches number of threads, can only wait for. | Support multithreading.The configuration of thread format parameter.When concurrent invocation reaches number of threads, submit to the current minimum thread of executing the task calling. |
Model A has used the static allocation internal memory, so total system Memory Allocation situation is stable.But reaching on the concurrent invocation in limited time, performance there is certain influence, is suitable for application generally speaking.The Model B dynamic assigning memory has guaranteed concurrent invocation, but because internal memory all needs to redistribute at every turn, this has sacrificed invocation performance.Be suitable for disposing computer system preferably.
More than the support of two kinds of models, need realize that client and service end are supporting by conditional compilation.
By setting up the SSIPCall instrument, provide the universal interprocess communication implementation method that has realized the application independence on a kind of data layout also to need to consider the solution of following several problems:
1, efficiency
Service end has only under the situation of a window, can not realize concurrent invocation.After SendMessage can only wait called the last time of target window to finish, could handle this and call.This and wes' design original intention is contrary.
Solve efficiency, use multithreading to realize.Can allow each interior service window of service processes adhere to different threads separately.Like this, each window is when handling, and performance can not influence each other.Thread is the minimum thread of Windows operating system CPU processor resource.
The problem that but needs to solve is, because same funcall can be handled by a plurality of service windows.So just the problem of individual dispatching algorithm is arranged, can use some scheduling strategies: the simplest use randomized policy; Select according to the hurrying of each service window, the situation of not being in a hurry.
SSIPCall uses random algorithm in early days.Considering afterwards SSIPCall is transplanted in the ABWOA software bus and use, is to improve performance, has used task to handle the relevant dispatching algorithm of degree of doing, be not in a hurry.
As shown in Figure 5, under this pattern, need the ability complete call of 6 steps.Compare many these steps of selection service window with the single-threaded realization version of Fig. 3, Fig. 4.Select service window to use some strategies, be used to calculate each window task actual figure, and therefrom select less window, can improve the handling capacity of performance and total system like this.
Realize writing down the information of executing the task the structure below having used (in the relevant shared drive of the following information service of leaving in):
typedef struct_my_ssipc_server_node
// service thread node information
{
HWND hWnd; The window handle of // current node
Long nExecuteCount; The task numeration of // current window
}MYSERVERNODE，*LPMYSERVERNODE；
typedef struct_my_ssipc_server_info
The tabulation of // service thread node
{
long thread_count；
MYSERVERNODE thread_list[SSIPC_MAX_THREAD]；
} MYSERVERINFO，*LPMYSERVERINFO；
Before each SendMessage, obtain the service window of nExecuteCount minimum earlier, directly take out hWnd then.Then nExecuteCount is added 1, expression has increased a task newly, and SendMessage sends message then.
In the window procedure function of service window, this nExecuteCount need be subtracted 1, a task has been finished in expression, has also reduced by a task naturally.
2, argument sequenceization is not considered
Two inter-process calling functions directly can not call, can only be by means of IPC mechanism.But how parameter is transmitted is problem.Consider versatility in addition, need provide one to use independence serializing implementation model.
General function statement, such as:
int test_fun(int a，int b，int c，int*pIntValue)；
The place of calling:
int retvalue＝0；
int iret＝test_fun(12，32，3，&retvalue)；
This is with in-process parameter transfer method, and during call function, the C++ compiler is pressed into storehouse to these parameters, can use these data (Fig. 6) so that function is carried out body.
No matter Data transmission between two processes uses WM_COPYDATA also to be to use shared drive, just above 16 bytes is handled as a whole, during transmission, can obtain first address P, duplicates 16 bytes then.16 bytes are passed to other processes as binary stream.Other processes, these 16 bytes, restoring is 4 parameters again, has so just realized the parameter transmission.Because the middle binary stream that uses is so can freely transmit.
As shown in Figure 7, client can be constructed a universal architecture body:
typedef struct_my_ssipc_buff
{
DWORD dwFunctionCode; // function command number
Long nParamCount; // number of parameters (current maximum 30 parameters)
long len1；LPVOID buff1；
long len2；LPVOID buff2；
long len3；LPVOID buff3；
long len4；LPVOID buff4；
。。。。。。
long len30；LPVOID buff30；
}MYFUNBUFF，*LPMYFUNBUFF；
Buff1, buff2, buff3, buff4 can point to the address of a, b, c respectively, and pIntValue (itself being pointer), like this so that the wrapper serializing of back.
MYFUNBUFF Mycall；
Mycall.dwFunctionCode=TEST_FUN; // be a constant, be used to identify any funcall
Mycall.nParamCount=4; This has called four parameters // expression
Mycall.buff1＝&a；
Mycall.len1＝4；
Mycall.buff2＝&b；
Mycall.len2＝4；
Mycall.buff3＝&c；
Mycall.len3＝4；
Mycall.buff4＝pIntValue；
Mycall.len4＝4；
During client call, only need provide above parameter information to get final product.Packing process is in the inner realization of SSIPCall.
SSIPCall serializing, reduction implementation procedure are as shown in Figure 8.
The form of order bag (IPC binary stream) is as shown in Figure 9:
CC CC CC CC PP PP PP PP LL LL LL LL XXXXXXXX LL LL LL LLXXXXXXXX
CC representative function command number
PP represents number of parameters
LL represents the length of each parameter
XXXX represents the parameter buffer memory
The length of command number, parameter format, each parameter is all used 4 byte representations.
Above data use parameter information memcpy to copy to the buffer zone when packing, the data model above forming, thus become stream format (internal arrangement is according to the form of order bag).These data are passed to service end.Service end restores the data among the universal architecture body MYFUNBUFF according to the form of above agreement.In service end, thereby obtained as the data layout before the client serializing.At this moment, the data that can directly visit among the MYFUNBUFF in service end get final product.
Fig. 9 has described this process more visually.
Because use LPVOID in the structure as parameter, can point to any kind information, comprise the data of simple types such as shaping, floating-point; But also directional structure data, as: structure, public body.So just realized the independence of application data form.
The len value of each buffer memory must be provided with, otherwise when serializing (packing), can't know when the data message of parameter finishes, also just can not information completely duplicate.Represent the length of the information that buff1 points to as len1, len2 represents the length of buff2 directional information.Typical shaping is exactly 4 bytes (under the WIN32 environment).In order to take into account all kinds of complicated applications, be provided with here and can allow 30 pointers at most.In the SSIPCal of latest edition l, be upgraded to and supported 255 pointers.
Note when utilization structure body parameter: pointer can not be used in inside, because wrapper can't know that it points to the length of content, the seriation of also just having no way.The way that solves is to use the fixed length array.
struct test_struct
{
char buff[255]；
Int buff_len; The actual content length of //buff
double c1；
int c2；
long c3；
}
Following form is wrong as parameter:
struct test_struct
{
char *buff；
Int buff_len; The actual content length of //buff
double c1；
int c2；
long c3；
}
Because the SSIPCall wrapper is a general program, it does not know that buff_len is exactly the pointer content-length of buff, also just can not handle the packing problem.
If run into and need minor structure body array in the structure, definable shape as:
typedef struct_my_ssipc_exchange_node
{
BYTE bUsed; Whether // current node is being used
HWND hWnd; The window handle of // current node
long buff_len；
BYTE buff[SSIPC_BUFSIZE]；
}MYFUNEXCHANGENODE，*LPMYFUNEXCHANGENODE；
typedef struct_my_ssipc_exchange_buff
{
Long buff_count; // actual useful number
MYFUNEXCHANGENODE buff_list[SSIPC_MAX_THREAD]；
}MYFUNEXCHANGEBUFF，*LPMYFUNEXCHANGEBUFF；
More than these structures can use sizeof () function to obtain total internal memory length, when Copy Info, directly copy in the serializing buffer memory according to this length and to get final product, do not need to be concerned about the form of structure.According to the structure of static defining, in content, will be order and distribute, could duplicate and will obtain the data of total body with memcpy like this.
And,, just can visit the content of the inside then as long as the pointer that obtains is converted to the LPMYFUNEXCHANGEBUFF pointer in service end.
Use under the situation of pointer in the structure the inside, memory address that pointer variable is pointed and structure memory address are not that order distributes, and pointer may point to an other internal memory, can not use memcpy to duplicate fully.And simple pointer passes in the other process, with meaningless.
SSIPCall provides SSIPC_PackFun () and SSIPC_UnpackFun () to finish packing, unpack.Realize serializing and information reverting.
3, a DLL supports many services
Can be according to business need, with the classification of the service window in the service processes, as: for the window of bank note service call, be the window of coin service call, realizes supporting in the DLL how application.Being convenient to code classification realizes.
The naming method of service end window, the open method of window handle
In order to allow client can explicitly find service window, we need to name according to some rules to the window title, perhaps the handle of these service windows are placed on a shared drive zone relevant with " Service name ".And client can find these information, and client just can find service window like this, could send SendMessage message.
In a service routine, may provide multiple " service ".Such as cash module service program, may need to provide the service interface of bank note, also need to provide the service interface of coin, for the ease of in service end distribution code; When also allowing client call, individual class discrimination is more clearly arranged.We can carry out class discrimination to each service window.But in fact, these services all realize in same EXE.
Be the relevant mentality of designing explanation of service below:
Every kind of relevant service window name of service has identical prefix
Service window called after as EPP:
″_ssipc_v1.0_#_win_epp_#0″
″_ssipc_v1.0_#_win_epp_# 1″
″_ssipc_v1.0_#_win_epp_#2″
_ ssipc_v1.0_ is unified name prefix, repeats to avoid service window name and other application name;
_ win_epp_ is a Service name;
#0, #1, #2 are all service windows of each thread, are used to realize the concurrent invocation of service together.
Belong to same service, will have following these shared information:
1) " information on services district ", window handle, the current task of each thread of record current service
″_ssipc_v1.0_#_win_epp_#server_info″
This piece region of memory offers client, so that select the decision analysis of service window when calling.
2) " the parameter information district " under each service, memory partitioning number=Thread Count=service window number
″_ssipc_v1.0_#_win_epp_#exchange″
This piece region of memory is used to allow client distribute acquisition internal memory piecemeal, so that transmission information.
If use second kind of Memory Allocation mode, promptly return the time spent with the shared drive zone of GUID name as information in the application of client internal memory, this region of memory is invalid.
3) " the visit lock " under each service, control a memory partitioning can not occur and be obtained to distribute by a plurality of threads:
″_ssipc_v1.0_#_win_epp_#lock″
Between two services, above shared drive zone is different, has avoided the information between two services to disturb like this, has improved the integrated dispatch ability simultaneously.Because different " visit lock ", different " parameter information districts " and " information on services district " are used in each service when storage allocation, the concurrency of system is just strong.
Realize among the SSIPCall.dll that in inside every kind of corresponding SSIPC object of service comprises a plurality of threads and service window (comprising a service window in the thread) in each object.
Figure 10 object 1, object 2, object A, object B all are the instantiations of CSSIPC class.After SSIPCall.dll was loaded, its memory headroom used the process space of the EXE that loads it.So the memory headroom of SSIPCall.dll is exactly the memory headroom of service end EXE process.
At last, it is also to be noted that what more than enumerate only is specific embodiments of the invention.Obviously, the invention is not restricted to above embodiment, many distortion can also be arranged, all distortion that those of ordinary skill in the art can directly derive or associate from content disclosed by the invention all should be thought protection scope of the present invention.
Claims (5)
1. universal interprocess communication implementation method, this method comprises:
Service end starts service;
Client call service to parameter packing, serializing, is packaged into the related data information of calling the packets of information of no categorical data parameter;
Service end is handled and to be called, and the packets of information of receiving is unpacked, and after extracting packing data and processing, the packets of information that is repackaged into no categorical data parameter is returned;
Client unpacks the return message bag, covers after the extraction data and calls place's parameter values;
Service end is closed service;
The described service of calling comprises:
Client application shared drive is used as the service end write back information;
Client finds service window, and uses service window to send message;
In the service end window procedure, obtain client data, and call call back function;
The service end call back function is handled, and realizes the data backfill;
Client obtains data and returns according to the shared drive of application;
Described shared drive, can't help service end and be responsible for sharing in advance, call by caller at every turn and before service window, apply for a shared drive, the internal memory name that service window distributes client passes to service end, after service end is called and is finished, according to this name data message is write back to shared drive, client is returned from this shared drive zone acquired information.
2. universal interprocess communication implementation method according to claim 1 is characterized in that, described no categorical data parameter comprises the data and the pointer data length information of no type pointer.
3. universal interprocess communication implementation method according to claim 1, it is characterized in that, a plurality of service windows that adhere to different threads separately simultaneously can walk abreast in the service processes of client and service end, usage policy calculated each service window task actual figure when client was sought service window, therefrom selected the service window of less task actual figure.
4. universal interprocess communication implementation method according to claim 1 is characterized in that, the implementation that the client and server end is packed, unpacked parameter is:
Parameter information universal architecture body of client structure copies to the buffer zone, forms the IPC binary data stream order bag that comprises command number, number of parameters, parameter length and parameter buffer memory;
Stream format data is passed to service end;
Service end form according to a preconcerted arrangement with reduction of data, obtains the data layout before the client serializing.
5. universal interprocess communication implementation method according to claim 1, it is characterized in that, a plurality of service windows that adhere to different threads separately simultaneously can walk abreast in the service processes of client and service end, each service thread comprises the shared information of visit lock, parameter information district and eye affair block of information, and identical service thread can be used this shared information when storage allocation.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2006100489780A CN100392599C (en) | 2006-01-10 | 2006-01-10 | Universal interprocess communication achieving method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2006100489780A CN100392599C (en) | 2006-01-10 | 2006-01-10 | Universal interprocess communication achieving method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1811717A CN1811717A (en) | 2006-08-02 |
| CN100392599C true CN100392599C (en) | 2008-06-04 |
Family
ID=36844655
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB2006100489780A Expired - Fee Related CN100392599C (en) | 2006-01-10 | 2006-01-10 | Universal interprocess communication achieving method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100392599C (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106470221B (en) * | 2015-08-18 | 2019-12-31 | 北京京东尚科信息技术有限公司 | Method for improving inter-process communication coordination efficiency |
Families Citing this family (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101141742B (en) * | 2007-10-12 | 2011-08-10 | 中兴通讯股份有限公司 | Application communication method of terminal |
| CN102137123A (en) * | 2010-01-25 | 2011-07-27 | 腾讯科技（北京）有限公司 | Device and method for realizing process-to-process communication of different application programs on mobile terminal |
| CN102469064B (en) * | 2010-11-03 | 2016-05-11 | 中兴通讯股份有限公司 | Realization Method of Communication and communication equipment |
| CN102103526A (en) * | 2011-02-14 | 2011-06-22 | 博视联（苏州）信息科技有限公司 | Method and system for performing inter-process communication between server and client by service management |
| CN103995736B (en) * | 2011-06-17 | 2017-09-22 | 天津书生软件技术有限公司 | A kind of method and apparatus for transmitting shared drive |
| CN103034529A (en) * | 2011-10-10 | 2013-04-10 | 国民技术股份有限公司 | Method and system for compatible combination of high-level platform and dynamic link library of low-level platform |
| CN103179173B (en) * | 2011-12-26 | 2018-03-02 | 腾讯科技（深圳）有限公司 | Hyper text transfer system, client and Hyper text transfer method |
| CN102609310A (en) * | 2012-02-14 | 2012-07-25 | 浪潮(北京)电子信息产业有限公司 | Computer operating system and inter-process communication method therefor |
| CN105843691B (en) * | 2012-06-29 | 2020-04-10 | 北京奇虎科技有限公司 | Method and device for interprocess communication in browser |
| CN102902542B (en) * | 2012-09-27 | 2016-06-01 | Tcl通力电子（惠州）有限公司 | Virtual interface configuration method and device |
| CN104123265B (en) | 2013-04-26 | 2017-12-22 | 华为技术有限公司 | A kind of many communication method between cores and system |
| CN104268025B (en) * | 2014-09-30 | 2018-11-27 | 珠海市君天电子科技有限公司 | A kind of method and system of interprocess communication, server |
| CN105446910B (en) * | 2015-11-24 | 2019-01-25 | 东软集团股份有限公司 | A kind of data transmission method and device |
| CN105528257B (en) * | 2016-01-08 | 2021-01-05 | 腾讯科技（深圳）有限公司 | Single-process data processing method and device |
| CN107239353A (en) * | 2017-06-02 | 2017-10-10 | 浪潮金融信息技术有限公司 | Inter-process communication methods and system |
| CN107291480B (en) * | 2017-08-15 | 2020-12-15 | 中国农业银行股份有限公司 | Function calling method and device |
| CN110502418B (en) * | 2018-05-17 | 2023-05-23 | 长沙博为软件技术股份有限公司 | Method for realizing remote debugging |
| CN109697131B (en) * | 2018-12-06 | 2021-08-24 | 京信网络系统股份有限公司 | Method and device for managing and synchronizing parameters between processes |
| CN112199205B (en) * | 2019-07-08 | 2023-10-27 | 南京工程学院 | Program communication method between heterogeneous platforms |
| CN111414603A (en) * | 2020-03-17 | 2020-07-14 | 用友网络科技股份有限公司 | Application based on communication mechanism between named pipelines |
| CN112068970B (en) * | 2020-08-10 | 2024-04-19 | 珠海全志科技股份有限公司 | RPC implementation method and medium based on heterogeneous multi-core processor |
| CN113595887B (en) * | 2021-09-09 | 2023-03-24 | 北京天空卫士网络安全技术有限公司 | Flow control method and device in mail system |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1197955A (en) * | 1997-04-17 | 1998-11-04 | 阿尔卡塔尔-阿尔斯托姆通用电气公司 | Method of managing shared memory |
| CN1404264A (en) * | 2001-09-04 | 2003-03-19 | 三星电子株式会社 | Unified intra-process communication |
-
2006
- 2006-01-10 CN CNB2006100489780A patent/CN100392599C/en not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1197955A (en) * | 1997-04-17 | 1998-11-04 | 阿尔卡塔尔-阿尔斯托姆通用电气公司 | Method of managing shared memory |
| CN1404264A (en) * | 2001-09-04 | 2003-03-19 | 三星电子株式会社 | Unified intra-process communication |
Non-Patent Citations (6)
| Title |
|---|
| Windows进程间通讯技术研究. 吴新爱，徐文楷.电脑知识与技术，第2005年第2期. |
| Windows进程间通讯技术研究. 吴新爱，徐文楷.电脑知识与技术，第2005年第2期. * |
| 动态共享内存缓冲池技术. 余翔湛，殷丽华.哈尔滨工业大学学报，第36卷第3期. 2004 |
| 动态共享内存缓冲池技术. 余翔湛，殷丽华.哈尔滨工业大学学报，第36卷第3期. 2004 * |
| 机内进程间通信的性能测试和评价. 胡亮，王敏珍.吉林大学学报（信息科学版），第21卷第4期. 2003 |
| 机内进程间通信的性能测试和评价. 胡亮，王敏珍.吉林大学学报（信息科学版），第21卷第4期. 2003 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106470221B (en) * | 2015-08-18 | 2019-12-31 | 北京京东尚科信息技术有限公司 | Method for improving inter-process communication coordination efficiency |
Also Published As
| Publication number | Publication date |
|---|---|
| CN1811717A (en) | 2006-08-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN100392599C (en) | Universal interprocess communication achieving method | |
| US6546553B1 (en) | Service installation on a base function and provision of a pass function with a service-free base function semantic | |
| EP2132640B1 (en) | Abstracting operating environment from operating system | |
| CN100498699C (en) | Sharing objects in runtime systems | |
| US6260075B1 (en) | System and method for providing shared global offset table for common shared library in a computer system | |
| US20070074192A1 (en) | Computing platform having transparent access to resources of a host platform | |
| US20070050765A1 (en) | Programming language abstractions for creating and controlling virtual computers, operating systems and networks | |
| US20080028401A1 (en) | Software executables having virtual hardware, operating systems, and networks | |
| US20070067769A1 (en) | Method and apparatus for providing cross-platform hardware support for computer platforms | |
| US20040255268A1 (en) | Systems and methods providing lightweight runtime code generation | |
| US20010037417A1 (en) | Method and system for dynamically dispatching function calls from a first execution environment to a second execution environment | |
| Scott et al. | Multi-model parallel programming in Psyche | |
| US20070050770A1 (en) | Method and apparatus for uniformly integrating operating system resources | |
| CA2888684A1 (en) | Multi-threaded, lockless data parallelization | |
| Potluri et al. | Extending openSHMEM for GPU computing | |
| US20050138640A1 (en) | System and method for inducing asynchronous behavioral changes in a managed application process | |
| EP2941696A1 (en) | Software interface for a hardware device | |
| JPH0855035A (en) | Method and equipment for separation of transmission control for microkernel data processing system | |
| CN103268245B (en) | A kind of method of weather data fast processing flow | |
| McMahon et al. | eMPI/eMPICH: embedding MPI | |
| WO2014107542A1 (en) | Capability based device driver framework | |
| US8201185B2 (en) | COM object and managed code object interoperability | |
| US9361266B2 (en) | System and method for distributed computing | |
| US7418710B1 (en) | Processing data objects based on object-oriented component infrastructure | |
| Kim et al. | Distributed execution for resource-constrained mobile consumer devices |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| ASS | Succession or assignment of patent right |
Owner name: EAST COMMUNICATION CO., LTD. Free format text: FORMER OWNER: HANGZHOU EASTCOM LINGTONG ELECTRONIC CO CO., LTD. Effective date: 20090403 |
|
| C41 | Transfer of patent application or patent right or utility model | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20090403 Address after: 398, Wensanlu Road, Xihu District, Hangzhou, Zhejiang. Zip code: 310021 Co-patentee after: Dongxin Finance Technology Service Co., Ltd., Hangzhou Patentee after: Oriental communications Limited by Share Ltd Address before: No. 1, Ding Ding Road, Hangzhou, Zhejiang, 310021, Jianggan District Patentee before: Hangzhou Eastcom Lingtong Electronic Industrial Co., Ltd. |
|
| CF01 | Termination of patent right due to non-payment of annual fee | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20080604 Termination date: 20190110 |