On the implementation of several underlying communication in software interface
Li Weima MSN: LiWeihua200204@hotmail.com
2005-3-28
I. Overview
The software interface is a bridge that implements information interaction with additional systems. Between different systems, according to the different levels of relationships and loosely coupled in different systems: tight coupling requires the interface response to the interface response, the message cannot be blocked; Loose coupling is relatively low for response. I mainly discuss the implementation of tight coupling interface communication, in the current application, Socket, middleware, soap, etc. use the corresponding application, but the communication methods have their own intrinsic features, "suitable for the best", This is truth.
In the process of interface and system information interaction, the two modes are very common: synchronous calls and asynchronous calls, synchronous call Requirements The interface must wait for the service system response message, the interface is blocked until timeout; asynchronous calls are issued After the request message, the interface can be engaged in other processing, timing polling server response messages and messages or event notifications. Simple synchronization is simple, but it is easy to cause interface blocking, resulting in a message backlink timeout.
Second, technology implementation
1, Socket Newsletter
Socket communication is relatively old communication method, and is also the most common way of communication. Socket communication has two ways of blocking and non-blocking. In synchronous mode, it is relatively simple to use blockage programming, but in order to prevent interface blocking, we need to set up Socket timeout, so you can use the Socket's SELECT model (refer to the following sample code):
Recelen = 0;
CurRecelen = 0;
For (;;)
{
IRESULT = SELECT (0, & fdread, null, null, & timeout);
IF (IRESULT == 0)
{
AFXMessageBox ("Receive Answering Message Timeout !!!", MB_ok | MB_ICONERROR);
CloseSocket (Socket);
Return False;
}
Currecelen = Recv (socket, Obuf Recelen, Len, NO_FLAG_SET);
IF (CurRelen> 0) && (curRecelen! = Socket_ERROR))
{
Obuf [Recelen Currecelen] = '/ 0';
Memcpy ((char *) & msglen, Obuf, Sizeof (Word32));
Msglen = NTOHL (MSGLEN);
IF (Recelen Currecelen == MSGLEN)
{
Recelen = CURRECELEN
Break;
}
Recelen = CURRECELEN
}
}
In an asynchronous mode, it is more convenient to achieve a non-blocking method, and the WSAAsyncSelect model and the WSAEventselect model can be used in non-blocking mode: the WSAAsyncselect model is based on the message. The WSAEventSelect model is based on events. The following sample code sets the Socket to read and write and close the operation. news:
Status = WSAASYNCSELECT (Tempsocket, HWND, WSA_READ, FD_READ | FD_CLOSE | FD_WRITE);
IF (status == Socket_ERROR)
{
Writelogfile ("SET Stream Socket Module Fail !!! IP (% s), Port (% d) and error (% d)", GetIpaddr ((Peermap Node) -> ipaddr), (Peermap Node) -> Peerportno Wsagetlasterror ()); CloseSocket (TempSocket, __ line __, __ file__);
Return False;
}
Regardless of the use of blocking methods or non-blocking methods, a problem that needs to be considered: the adhesive phenomenon, that is, the application sends two or more packets, and the data packet is combined into one transmission, so the receiving end is received. After the packet, you need to split the packet according to the length of the application definition, otherwise the application layer is packetified.
2, middleware communication
At present, there are many intermediate platforms. The middleware I use has a BEA Tuxedo and Dongfang Tongeasy, Tongeasy I will not say, mainly discuss Tuxedo. The BEA Tuxedo system provides nine communication modes:
(1). Synchronize the Request / Response mode;
(2). Asynchronous REQUEST / RESPONSE mode;
(3). Nested call;
. Call forward;
. Session communication;
. Active message announcement;
. Eventual communication;
. Queuing communication;
. Use a transaction.
The synchronous request / response mode is relatively simple, so it is also used in applications. However, the synchronous request / answering method is slower when the server is slower, and if multi-threaded mode is used, whether tuxedo uses long connections or short connections, it is easy to cause thread hanging, and can no longer be subsequently processed, and many cases require a program Restart. The asynchronous mode will not cause blocking, but you need to check if there is a reply message, the following code implements the function of using the asynchronous function to achieve synchronous calls, add timeout processing, which will not cause the program to block:
Int TpCallex (Char * SVC, Char * Idata, Long ilen, char ** ODATA, Long * Olen, long flags, long timeout
{
const Int err_invoke_result = -1;
INT iHandler = 0;
INT IRESULT = 0;
Int itimeout = timeout;
iHandler = TPACALL ((char *) SVC, (char *) Idata, Ilen, (long) TPNOBLOCK;
IF (ihandler == Err_invoke_result)
{
Return ihandler;
}
While (Itimeout> 0)
{
IRESULT = TpGetrPly (& iHandler, (char **) OData, Olen, (long) TPNOBLOCK;
IF (IRESULT == Err_invoke_result)
{
Sleep (10);
ITimeout - = 10;
CONTINUE;
}
Break;
}
IF (ItiMeout <= 0)
{
TpCancel (ihandler);
Return Err_invoke_result;
}
Return ihandler;
}
If you want to increase the processing capability of the interface, use multithreading how there is hidden dangers, the best way is to adopt a multi-process, but there is a problem with how to balanced. 3, SOAP newsletter
SOAP communicates with server Web Service as an agreement. IBM and Microsoft provide SDK of the SOAP protocol. I use Microsoft's SOAP Toolkit 3.0, which is a set of components of CoM, so the characteristics of COM, the processing of calling parameters, the order of Windows and UNIX is exactly the opposite, below The code implements call a web service:
IF (! m_bflattype)
{
For (i = paramnum, j = 0; i> j; i -, j )
{
Variantarg argtemp;
VariantInit (& argtemp);
ArgTemp = VA [I-1];
VA [I-1] = VA [J];
VA [J] = ArgTemp;
}
}
Params.cargs = paramnum;
Params.Rgvarg = VA;
Params.cnamedargs = 0;
Params.rgdispidnamedargs = null;
HR = SOAPCONNECT.PSOAPCLIENT [INDEX] -> Invoke (Dispidfn, IID_NULL, LOCALE_SYSTEM_DEFAULT, DISPATCH_METHOD, & PARAMS,
& Result, 0, 0);
IF (Failed (HR))
{
HandlehResult (_T ("Invoke of" strService "Method Failed."), HR);
VariantClear (& result);
For (i = 0; i Sysfreestring (BSTRServiceName); Couninitialize (); Return False; } Third, summary In three communication methods, each has advantages and disadvantages, but mainly in what technical solutions are implemented by the server, the interface must correspond to the corresponding communication mode. In addition to the above communication mode, there are otherwise many other ways, such as pipelines, message queues, etc., I am using lots in the interface that is tight.
