論軟體介面中幾種底層通訊的實現

2021-04-13 08:11:43 字數 2578 閱讀 4851

論軟體介面中幾種底層通訊的實現

整理:ackarlix

一、 概述

軟體介面是實現乙個系統跟另外系統進行資訊互動的橋梁,在不同的系統之間,根據系統的關聯程度的不同存在緊耦合和松耦合兩種:緊耦合要求介面響應反應快,訊息不能阻塞;松耦合對響應反應要求比較低。本人主要討論緊耦合介面通訊實現,在目前應用中,socket、中介軟體、soap等都用相應的應用,但是應用中發現各通訊方式有自己固有的特徵,"適合的才是最好的",這是真理。

在介面和系統資訊互動的過程中,兩種模式使用得很普遍:同步呼叫和非同步呼叫,同步呼叫要求介面發出請求訊息後必須等待服務端系統的應答訊息,介面阻塞直至超時;非同步呼叫則發出請求訊息後,介面可以從事其它處理,定時輪詢服務端應答訊息和訊息或事件通知。同步方式簡單,但是很容易造成介面阻塞,造成訊息積壓超時。

二、 技術實現

1、 socket通訊

socket通訊相對來說是很古老的通訊方式,也是最常用的通訊方式。socket通訊有阻塞和非阻塞兩種方式。在同步方式,採用阻塞程式設計比較簡單,但是為了防止介面阻塞,我們需要設定socket超時,因此可以使用socket的select模型(參考如下示例**):

currecelen=0;

for(;;)

currecelen = recv(socket, obuf+recelen, len, no_flag_set);

if((currecelen>0) && (currecelen != socket_error))

recelen+=currecelen; }

}     

在非同步方式下,採用非阻塞方式實現比較方便,在非阻塞方式下可使用wsaasyncselect模型和wsaeventselect模型:wsaasyncselect模型基於訊息,wsaeventselect模型基於事件,下面的示例**設定了socket進行讀寫和關閉操作的訊息:

if (status == socket_error)

無論使用阻塞方式或非阻塞方式程式設計,需要重點考慮的乙個問題:粘包現象,即應用傳送兩個或以上的資料報,在socket通訊層將資料報合併成乙個傳送出去,因此接收端收到資料報以後需要對資料報根據應用定義的長度進行拆分,否則導致應用層丟包。

2、中介軟體通訊

目前中間平台也比較多,我所使用的中介軟體有bea的tuxedo和東方通的tongeasy,tongeasy我就不說了,主要討論一下tuxedo。bea tuxedo系統提供九種通訊模式:

⑴.同步request/response模式;

⑵.非同步request/response模式;

⑶.巢狀呼叫;

⑷.呼叫**;

⑸.會話通訊;

⑹.主動訊息通告;

⑺.基於事件的通訊;

⑻.基於佇列的通訊;

⑼.使用事務。

同步請求/應答方式比較簡單,因此在應用中也使用得相當多。但是同步請求/應答方式在服務端服務端反應比較慢時造成阻塞,如果使用了多執行緒方式,不管tuxedo採用長連線還是短連線均容易造成執行緒掛起,不能再進行後續處理,很多情況需要程式重啟。採用非同步方式不會造成阻塞,但需要去查詢是否有應答訊息,下面的**實現了使用非同步函式實現同步呼叫的功能,增加了超時處理,這樣不會導致程式阻塞:

int tpcallex(char *svc, char *idata, long ilen, char **odata, long *olen, long flags, long timeout)

while(itimeout>0)

break; }

if(itimeout<=0)

return ihandler;

}            

如果要增加介面的處理能力,使用多執行緒方式會存在隱患,最好的方式是採用多程序,不過存在如何訊息均衡的問題。

3、soap通訊

soap作為一種協議,同服務端web service進行通訊。ibm和微軟提供了soap協議的sdk,我使用的是微軟的soap toolkit3.0,這是基於com的一套元件,因此具有com的特徵,在呼叫引數的處理,windows和unix順序恰好相反,下面的**實現了呼叫乙個web service:

if(!m_bflattype)

} 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,

¶ms,

&result, 0, 0);

if(failed(hr))

三、總結

在三種通訊方式中,各有優缺點,但是主要還在於服務端採用什麼技術方案來實現,介面必須對應採用相應的通訊模式。

除了上面的通訊模式,當然還有很多其它的方式,如管道、訊息佇列等,目前我在緊耦合的介面中使用得不多。

論軟體介面中幾種底層通訊的實現

一 概述 軟體介面是實現乙個系統跟另外系統進行資訊互動的橋梁,在不同的系統之間,根據系統的關聯程度的不同存在緊耦合和松耦合兩種 緊耦合要求介面響應反應快,訊息不能阻塞 松耦合對響應反應要求比較低。本人主要討論緊耦合介面通訊實現,在目前應用中,socket 中介軟體 soap等都用相應的應用,但是應用...

理解C 中引用的底層實現

1 c primer提到 引用並非物件,相反的,它只是為乙個已經存在的物件所起的另外乙個名字。引用的定義必須伴隨初始化,而且一旦定義了引用,就無法令其再繫結到另外的物件,之後每次使用這個引用都是訪問它最初繫結的那個物件。2 何為物件?對於物件導向來說,物件就是類的例項,是抽象化的資料本身。更廣義的來...

工作中的糾結 區分於底層OR介面

在使用模板引擎時,遇到了乙個糾結的問題,現需要分析一下。在介面完全一樣的情況下,所需的變數,也就是put到標記語言中的內容不一樣 時,是選擇重寫介面,還是選擇在底層進行邏輯區分?場景假設 有27個介面,平均每個介面需要裝載4個小介面,也就是4個 panel。有8種panel。當然對於愛好偏向介面的我...