GCDAsyncSocket 如何顺序发送？？？比如先发送，文件名，再发长度，再发送文件，还必须要在文件名发送完了之后发送下一个
巴扎黑2017-05-02 09:34:41
簡単に言うと、TCP 接続はネットワーク送信中に (主にデータ送信を最適化するために) 順序が乱れますが、TCP には対応する「ソート」処理があるため、同じ接続 (クライアント A とサーバー S の間 (この接続) など) では、 TCP Socket の最下層では、a、b、c の順に送信すると、受信側は a、b、c の順に受信します。これは、UDP に対する TCP の利点でもあります。
したがって、あなたの問題はGCDAsyncSocketの問題ではないはずです。
ソケットは特定のビジネス ロジックを持たずにデータの送受信のみを行うため、ソケット アプリケーションには通常、さまざまなパラメーターを区切り文字で結合したり (例: ファイル名 | ファイル)、共通形式の xml や json を使用したりするなど、独自のデータ形式があります。簡単に解析するため ( {"filename": "", "data": ""} )。同時に、MTU の制限により、送信時に完全なビジネス データが解凍されて送信される可能性があり、ネットワーク上の理由によりパケット損失が発生する可能性があるため、「ソケット データ長」パラメーターがカスタム データ形式に追加されます。 HTTP POST の Content-Length と同様、通常、後続のソケット データ全体の長さをマークするためにデータの先頭に追加されます。 「長さ」パラメータはデータ形式には関与しません。双方が合意した特定のサブセクションの長さが「ソケットデータ長」パラメータを表します。受信機がデータを処理するとき、最初に最初の数桁の「長さ」を解析し、次にこの長さに基づいて後続の完全なデータを決定します。
ソケットの開発中に問題が発生し、原因が明確に特定できない場合は、まずパケットをキャプチャして分析し、データがどのように送信されるかを確認し、ネットワーク障害のトラブルシューティングを行ってから、送信側の問題かどうかを判断することをお勧めします。または受信機の問題。送信側と受信側に問題がなく、サービスコードにも問題がない場合は、最後にルーターやオペレーターなどの「ネットワークプロキシ」の原因を確認することを検討してください。中国のネットワークの中間層。
