0

私は現在、クライアントがメッセージ付きのxmlファイルを送信してサーバーと通信するサービスを開発しています。メッセージングの信頼性を向上させるために (クライアントは低品質の制限されたバンドスイッチ モバイル インターネットを使用します)、これらのメッセージを 64 または 128 Kb サイズの小さな部分にチャンクし、BasicHttp バインディングで transfer="streamed" を使用して送信します。

ここで、問題があります。サーバーは、クライアントがチャンクを正常に受信したかどうかをクライアントに報告する必要があるため、fe 5 チャンクの転送に失敗した後、転送プロセスはキャンセルされ、後で試行されるように延期され、どれを追跡するかを追跡します。チャンクが受信され、どれが受信されないか。

クライアントと通信するためにコールバックメカニズムを使用することを考えているので、サーバーはサーバー側のファイルにチャンクを保存するときに、[OperationContract] のコールバックメソッド ChunkReceived を呼び出しますが、間違っている場合は修正してください。 WS Dual http バインディングでのみ機能し、basichttp バインディングではサポートされていません。ただし、ストリーミング転送は WS デュアル バインドではサポートされていません。

それで、WS Dual binding に切り替えて transfer="buffered" を使用しても問題ありませんか (チャンク サイズが比較的小さいことを考慮して) - それによって転送の信頼性が損なわれることはありませんか? または、何らかの応答メッセージを返すことで、基本的な http バインディングでクライアントと通信できるかもしれません。

    [OperationContract]
    ServerResponse SendChunk (Chunk chunk);

ここで、ServerResponse は enum または bool フラグを保持して、SendChunk 操作が正常かどうかをクライアントに伝えます。しかし、すべてのチャンクのステータスを追跡するために、クライアント側とサーバー側の両方である種の配列を保持する必要があります。そこで使用するのに最適なパターンが何であるかはわかりません。アドバイスをいただければ幸いです。

4

1 に答える 1

1

私たちのアプリケーションにも同様の問題がありました - 低帯域幅と多くの切断/タイムアウトです。メッセージが小さいので分割しませんでしたが、このソリューションはチャンクでも機能するはずです。クライアントにリピーターを作成しました。これは、信頼できるソリューションであることが証明されています。接続が低速で貧弱なクライアント (GPRS など - 頻繁に切断される移動中) でうまく機能します。また、高負荷のためにサーバーの速度が低下しても、クライアントはタイムアウト エラーを受け取りません。これは、チャンクを含む変更されたバージョンです

クライアント：

1. Client sends Chunk#1, with pretty short timeout time

2. Is there OK response:

   2A. Yes - proceed to next chunk

       3. Was that last chunk?

          3A. Yes - process reponse

          3B. No - send next chunk

   2B. No - repeat current chunk

サーバ：

  1. 要請を受け入れます

  2. チャンクは繰り返されますか

    2A。はい：

    1. 最終チャンクです:

      3A。はい - 応答の準備ができているかどうかを確認し、そうでない場合は待機します (これにより、おそらくクライアントが繰り返されます)

      3B. いいえ - OK 応答を送信します

    2B. いいえ：

    1. リクエストをどこかに保存します（リスト、辞書など）

    2. これは最後のチャンクですか:

      5A。はい - メッセージを処理し、応答を保存して、クライアントに送信します

      5B. いいえ - OK メッセージを送信します

于 2012-08-09T07:37:52.277 に答える