2009-04-09 153 views
0

我有一個使用Microsoft RPC進行進程間通信的程序。當與[在,字符串]像這樣(MIDL符號)參數的方法的調用:「呼叫失敗並且未執行」

interface IOurInterface 
{ 
    error_status_t rpcMethod([in, string] const WCHAR* parameter); 
} 

被調用它通常是成功的。但是,如果參數字符串足夠長(超過大約300萬個字符),則調用失敗,並且RPC_S_CALL_FAILED_DNE(「遠程過程調用失敗並且未執行。」)。這當然取決於字符串的長度。如果字符串在限制範圍內,則在相同條件下的相同調用總是成功,如果字符串較長,則總是失敗。它看起來像極限是系統或機器相關的。

有沒有人觀察過這種行爲,以及可能的解決方案是什麼(不縮短參數)?

回答

1

我以前曾觀察過該消息,但我不認爲它是同一個原因 - 「未執行」是一個泛型的RPC錯誤,可能由許多事情引起。

在我們的特殊情況下,這是因爲我們在捶打WMI時太難而且沒有清理我們的物體。但在你的情況下,它似乎是一個不同的原因。

我知道你說你不想縮短參數,但這可能是你前進的唯一途徑。我很難想象您需要在RPC調用中發送6M的情況。也許如果你解釋它背後的原因,我們可以進一步提供幫助。

基於評論日期其他可能性:

1 /分割。

RPC調用是否限制通過導線傳輸的數據量。這可以通過在源處分割消息並在目的地重建它來完成,例如有三個參數(您可以讓服務器在另一個RPC調用中釋放消息標識符,或者找到其他方法確保沒有兩個客戶端具有相同的ID): - 消息標識符(用於將消息段捆綁在一起)。 - 最後一個標誌(開始重建過程)。 - 尺寸有限的細分受衆羣(例如1M)。

2 /壓縮。

由於XML是文本,壓縮已經成熟。在尺寸縮小方面,7zip庫是我見過的最好的。這是否足夠快是另一回事。

3/可能通過更改註冊表修復。

查看RpcMaxSize密鑰的HKLM/Software/Microsoft/Rpc註冊表區域。有幾個網站我GOOGLE了,建議將其設置爲-1將刪除大小限制(全球,所以要小心)。

4/可能註冊您的接口時修復。

在與RpcServerRegisterIf2()的特定界面上顯然可以達到與(3)相同的效果。

你可以做的就是分裂您的字符串:

+0

的原因是,我們發送超大對象的XML表示,不希望想到優化它(但它絕對有可能)。所以如果有一個簡單的方法來繞過這個問題,它會非常方便。 – sharptooth 2009-04-09 12:55:50

+0

那麼,分段是一種可能性:將參數限制爲會話標識,最後標記和(例如)1M文本。您必須在源代碼處對您的XML進行細分,並在目標位置將它們合併在一起。不是我的第一選擇,而是一個應該盡最大努力工作的快速和骯髒的解決方案 – paxdiablo 2009-04-09 13:00:04

1

每個RPC調用作爲一個整體的大小通常是由各種因素,如運輸的限制(在UDP上,比特率/最大延遲數據包大小EX)的限制在數據包,並與多個呼叫發送,

或打開一個額外的TCP套接字將與您當前的RPC發送數據和控制它