この質問は、Node.js Net モジュールが ip-fragmentation を処理しないことを示唆しています: Node.js how to handle packet fragmentation with net.Server
それが本当だとはほとんど想像できませんが、これに関するドキュメントは見つかりません (これに関する情報を見つけるのがそれほど難しくない場合は、ご容赦ください :-) )。本当ですか？
そうでない場合：ありがとう、それは私にとって本当に安全です:-)。
本当の場合: データグラム全体の大きさがわからない場合、この問題をどのように処理しますか?
状況: 組み込みシステム (Wiznet W5500) との TCP 接続があります。MSS (最大セグメント サイズ、MTU - 40 にほぼ等しい) は 536 に設定され、データ パッケージは可変サイズで、サイズが 4kb を超える場合があります。そのため、データ パッケージは複数のセグメントで送信されます。「オンデータ」イベントは、セグメントが受信されたときにトリガーされますか、それともパッケージ全体が受信されたときにのみトリガーされますか?
副次的な質問: データ セグメント (MSS レジスタの説明で Wiznet が話していることについて) が ip-fragment に相当するというのは正しいですか? したがって、4000 バイト (すなわちペイロード) を送信する必要があり、MSS が 536 に設定されている場合、連続して受信します:
segment1: 536bytes payload
segment2: 536bytes payload
segment3: 536bytes payload
segment4: 536bytes payload
segment5: 536bytes payload
segment6: 536bytes payload
segment7: 536bytes payload
segment8: 248bytes payload
「データ上」イベントはセグメント 8 の後にのみトリガーされ、「データ引数」にはパッケージ全体が含まれるか、それともセグメントを個別に受信するたびに「on data」イベントがトリガーされることはありますか?
処理を続行する前に、パッケージ全体を取得することを 100% 確実にするにはどうすればよいですか? 私が考えた解決策：
- データ パッケージの最初の 2 バイトは、全体の長さのバイト長です。受信したデータを、バイト数分受信するまで連結し続けます。パッケージ サイズを超えるサイズを受信した場合は、これらの連続するバイトが後続のデータ パッケージの開始であると想定します。
この「解決策」はややこしいと思いますが、それが必要でないことを願っています。
前もって感謝します！情報が不足している場合: 申し訳ありませんが、お気軽にお問い合わせください :-)。