私は、サーバーからいくつかの XML データを取得することになっています。
<?xml><a></a><?xml><a></a><?xml><a></a><?xml><a></a>
パケットが次の順序で受信されたとします。
<?xml><a>
</a><?xml><a></a><?xml>
<a></a>
この種のデータを解析するロジックをどのように定式化できますか?
私は、サーバーからいくつかの XML データを取得することになっています。
<?xml><a></a><?xml><a></a><?xml><a></a><?xml><a></a>
パケットが次の順序で受信されたとします。
<?xml><a>
</a><?xml><a></a><?xml>
<a></a>
この種のデータを解析するロジックをどのように定式化できますか?
手短に言えば、順序を気にする必要はありません。TCP が再構成を処理します。
TCP はストリーミング プロトコルであり、各パケットには、ネットワーク スタックが着信パケットを正しい順序で再構成できるようにするシーケンス番号が含まれています。また、送信中にドロップまたは破損したパケットを自動的に再送信します。ただし、一度に完全なメッセージを送信する UDP とは異なり、TCP は接続が閉じるまでデータを送信し続けるだけであり、個々のメッセージのプロトコル レベルの概念はありません。
あなたの質問は注文に関するものではなく、すべてのデータをいつ受け取ったかを知ることに関するものだと思います。そのためには、一般的に 2 つの方法があります。
まず、データの送信が完了すると、サーバーは接続を閉じることができます。クライアントは要求を行い、接続が閉じられるまで応答を蓄積してから、受信したすべてのデータをアプリケーションに渡します。
次に、アプリケーションは、各メッセージの末尾をマークするか、各メッセージの先頭にバイト カウントを挿入することによって、データ自体をフレーム化できます。受信側は、指定されたバイト数が到着するのを待って、それらをアプリケーションに渡します。
実際には 3 番目の方法がありますが、エラーが発生しやすく、一般的に不適切な方法と見なされています。クライアントは、タイムアウトがメッセージの終了を示していると仮定して、データの受信が停止するまでしばらく待つことができます。ただし、これにより、クライアントがタイムアウトを待機している間に不要な遅延が発生する可能性があり、ネットワークに大きな遅延がある場合は、メッセージの終了を時期尚早に示すこともあります。サーバーがメッセージの途中で「立ち去った」場合にクライアントがハングするのを防ぐためのフェイルセーフと見なす必要があります。または、他の方法が機能しない場合の最後の手段として使用できます。ただし、断続的に失敗する可能性が高いため、私から聞いたことを誰にも言わないでください。:-)
幸運を!