0

プロセス間通信にMicrosoftRPCを使用するプログラムがあります。このような[in、string]パラメータを使用してメソッドを呼び出すと（MIDL表記）：

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

呼び出されると、通常は成功します。ただし、パラメータ文字列が十分に長い場合（約300万文字を超える場合）、呼び出しはRPC_S_CALL_FAILED_DNE（ "リモートプロシージャコールが失敗し、実行されませんでした。"）で失敗します。それは確かに弦の長さに依存します。同じ条件での同じ呼び出しは、文字列が制限内にある場合は常に成功し、文字列が長い場合は常に失敗します。また、制限はシステムまたはマシンに依存しているように見えます。

誰かがそのような振る舞いを観察しましたか、そして（パラメータを短くすることなく）可能な解決策は何ですか？

4

2 に答える 2

1

以前にそのメッセージを確認しましたが、同じ原因ではないと思います。「実行されませんでした」は、多くの原因で発生する可能性のある一般的な RPC エラーです。

私たちの特定のケースでは、WMI を強く叩きすぎて、オブジェクトをクリーンアップしなかったことが原因でした。しかし、あなたの場合は別の原因のようです。

パラメータを短くしたくないと言ったのは知っていますが、それが唯一の方法かもしれません。RPC 呼び出しで 6M を送信する必要がある状況を視覚化するのに苦労しています。その背後にある理由を説明していただければ、さらにお役に立てるかもしれません。

これまでのコメントに基づくその他の可能性:

1/ セグメンテーション。

RPC 呼び出しで、ネットワーク上を移動するデータの量を制限します。これは、送信元でメッセージをセグメント化し、送信先でそれを再構築することで実行できます。たとえば、3 つのパラメーターを使用することができます (サーバーに別の RPC 呼び出しでメッセージ識別子を提供させるか、他の方法を見つけて、2 つのクライアントが同じものを持たないようにすることができます)。 ID): - メッセージ識別子 (メッセージ セグメントを結合するため)。- 最後のフラグ (再構築プロセスを開始するため)。- 限られたサイズのセグメント (例: 1M)。

2/圧縮。

XML はテキストであるため、圧縮に適しています。7zip ライブラリは、サイズの削減という点で私が見た中で最高です。これが十分に速いかどうかは別の問題です。

3/レジストリを変更することで解決できる可能性があります。

RpcMaxSize キーの HKLM/Software/Microsoft/Rpc レジストリ領域を確認してください。これを-1に設定するとサイズ制限が解除されることを示唆しているサイトがいくつかあります（グローバルなので注意してください）。

4/インターフェイスの登録中に修正される可能性があります。

を使用すると、特定のインターフェイスで (3) と同じ効果が得られるようRpcServerRegisterIf2()です。

于 2009-04-09T12:52:07.597 に答える
1

全体としての各 RPC 呼び出しのサイズは、通常、トランスポート制限などのさまざまな要因によって制限されます (例: UDP のパケット サイズ、ビット レート/最大遅延)。

できることは、文字列をパケットに分割し、複数の呼び出しで送信することです。

または、追加の tcp ソケットを開いてデータを送信し、現在の RPC で制御します

于 2009-04-09T12:52:31.650 に答える