バックナンバーはこちら。
https://www.simulationroom999.com/blog/In-vehicle-network-backnumber/
はじめに
IPフラグメントの特殊な仕様。
登場人物
博識フクロウのフクさん
イラストACにて公開の「kino_k」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=iKciwKA9&area=1
エンジニア歴8年の太郎くん
イラストACにて公開の「しのみ」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=uCKphAW2&area=1
IPフラグメントの特殊な仕様
前回、IPフラグメントの結合には成功したけど、
また別の仕様があるとかないとか・・・。
そんなに複雑な話ではないよ。
どんなん？
受信EthernetFrameの順番が入れ替わってもOK。
って仕様。
なにそれ？！
え？
どうするの？
IPヘッダのフラグの中の「継続」が無効だと最終フレームで、
それでパケット確定ってことじゃなかったっけ？？？
そうだねー。
そんな話だったかなー。
ここらへんでそういうこと言ってたじゃん！
IPフラグメントの断片化フレームは順番通りじゃなくてもよい
上の話はあくまで分割/結合ルールの話だねー。
実際にどの順番でフレームが来るかについては言及してない。
(なんか要件が噛み合わなかったことが納品後に発覚して、問答してる時にでてきそうなセリフだ。)
あ、でも、lwIPとしては対応してるから問題無し？
だといいなぁ。
えー！！
まぁやってみればわかるんじゃない？
ちょっと図解してみた。
とりえあず、一回落ち着いて。
説明するから。
とりあえず、説明は聞こう。
図解するとこんな感じ。
うーん。
これが許容されるってのが解せない。
まぁEthernetFrameが遅延するってのは仕様上あり得るからねー。
プロトコルスタックの仕様次第ってのもあるが、
途中のルータの仕様次第ってのもあって、
現実的には順番が変わることは起きなくとも、仕様上は加味しておく必要はある。
って感じだねー。
なるほど。
確かに、イレギュラーな状況は想定すべきではあるが。。。
組み込み用のプロトコルスタックでそこまで面倒見てるのかなー。
結構ハンドリングややこしそうだけど・・・。
まぁやり方はいろいろあるけど、
後日説明かなー。
とりえあず、まずはlwIPが受信可能かってところを確認だねー。
まとめ
まとめだよ。
- IPフラグメントはEthernetFrameの順番が入れ替わっても結合してくれる仕様。
- lwIPが対応しているかは不明。
バックナンバーはこちら。
コメント