- 506 名前：デフォルトの名無しさん [2007/07/10(火) 19:17:26 ]
- >>503と>>505は釣りかい？
マジなら>>505はもう一度勉強な。
それから、UDPの送信フレーム数そのものに制限は無い。
どこで知ったかしらないが、64kbyteなんて制限はない。
恐らくAPIレベルの話だろう。64kbyte以上送りたければ、何度もAPIを呼べばいい。
受信側が受け取れなければ、単に破棄するだけだ。
それは、受け取り側が糞なんじゃなくて、そういう仕様。
UDPの通信フレームの最大長は、1500オクテット（＝バイト）だが、
IP情報分を除くと1480バイトになる。経路が全てイーサネットで
組まれているのなら、APIレベルで1480バイト以下を送れば分割（フラグメント）は起こらない。
インターネットに流すのならもっと小さくする必要がある。
IPヘッダ専用のチェックサムはあるが、それはデータとは無関係。データ自身には何のチェックバイトもない。
イーサネットフレームのCRCはあるが、それは送信時のもので、異なるプロトコルにぶちあたるとコロリととれてしまう。
イーサネットフレームに戻るときにはCRCも戻るが、それは再構築されたものなので、送信時のものとは全く関係ない。
そもそも、UDPは、次の特徴をもっている。
・>>504が言うとおりIPフレームの到来順序を期待してはいけない。
・戻されたIPフレームがどの順番に届くかは保証されない。
・IPフレームの一部が失われた場合、再送の手順は行わない。
・IPフレームは分割（フラグメント）されるかもしれないが、分割された順序を記憶するフィールドがあり、再構築されるようになっている。
UDPとは、
・本来、内部LANのように信頼性の高い部分で使用することを前提に策定された
・今は、動画や音声のように、一部が失われても十分機能する場合によく用いる
のですよ。ちなみにコレはIPv4の仕様。IPv6はこうとは限らない。
|
 |
