トップ «前の日記(2003-03-08) 最新 次の日記(2003-03-16)» 編集

Public Diary


2003-03-11

[ネット] バレンタインデーのためのプロトコル

*1

毎年2月14日には、チョコレートやお菓子などのパケットの交換が頻繁に行われます。その大部分はブロードキャスト型の通信で、一般に VDP (Valentine's Delivery Protocol) と呼ばれるプロトコルに基づいて配送されます。

ごく一部のクライアントは、Peer-to-peer の接続を要求するものがあり、また持続的なセッションを要求することもあります。サーバーは、リソースが不足気味な場合はこれを拒絶することができます。この拒絶はエラーレスポンスとして返されます。一部のクライアントはこのエラー処理を適切に処理できないため、時にオーバーフローやハードウェアの故障・システム停止などを招くことがありますので気を付けましょう。

このプロトコルを使って配送されたパケットは、どんなものであれ、他のホストにルーティング(横流し)してはいけません。このプロトコルはブロードキャストを念頭に考案されたものですが、プロトコルを構成する各々の通信は閉じた単一のネットワーク内で1対1で行われます。その他のホストにパケットを流したり、ホストからパケット同士を比較するとネットワークシステムの破綻を起こすことがありますので、絶対にルーティングするべきではありません!なお、確実に隔離されていることが保証されているならば、他のセグメントにパケットを横流しすることも理論的には可能です。(ただし、筆者の経験から言うと、技術的に不可能に近いです)

また、このパケットを受け取ったサーバーは、送信元のクライアントに対してまずレスポンスコードを返し、さらにそのちょうど1ヶ月後(たいていは3月 14日)に、レスポンスの本体を返す必要があります。ここで注意しなければならないのは、ブロードキャストされたパケットに対してはブロードキャストでパケットを返す必要がある、ということです。たとえば、ホストAからパケットa1を、ホストBからパケットb1を受け取った場合、それぞれに対してパケット a2とパケットb2を返すのではなく、どちらにも同じパケット c を送り返す必要があるということです。

パケットをブロードキャストしたクライアントに対してpeer-to-peerなレスポンスを返してはいけません。これはプロトコル違反です。また、パケットの中身は何でも構いませんが、慣例として3倍のバイト数のパケットを返すことになっています(が、10倍でも20倍でも構わない)。逆に、peer-to-peerなレスポンスを期待するクライアントに対してブロードキャスト用のパケットを返すことはできますが、この場合は他よりも若干はやめにレスポンスを返すことが推奨されています(が、規定されているわけではありません)。

 エラーコード一覧:
   100 Continue            持続的な接続の受け入れ
   101 Switching Protocol  場所を変えて話そう
   200 OK                  ありがとう (一般的なレスポンス)
   204 No Response         ……。(ゴルゴ13風に)
   205 Reset Content       なかったことにしよう
   300 Multiple Choices    いくつかの選択肢がある
   301 Moved Permanently   昔の話さ
   303 See Other           他を当たってくれ
   304 Not Modified        おまえも変わらないなぁ
   305 Use Proxy           受け渡しは第三者に委任せよ
   400 Bad Request         常識はずれなこと言うなよ
   402 Payment Required    おごりは無理・割り勘でお願い
   403 Forbidden           そんな愛、認めない!
   404 Not Found           外出ということにしてください
   406 Not Acceptable      受理できない
   409 Conflict            あぁ!本命たくさんもらっちゃった!
   410 Gone                イッテヨシ
   413 Request Entity Too Large  そんなに愛してくれてるなんて!
   500 Internal Error   家庭内の事情で…
   503 Service Unavailable 混乱中

AUTHOR

このプロトコルの提唱者はモロゾフ株式会社だと言われています。

BUGS

このプロトコルは日本でのみ有効です。その他の国では、1日以内にレスポンスをする必要があったり、宗教的な理由によってプロトコルが禁止されていたりしますので、注意が必要です。

STATUS

この文書に対するコメントは募集中です(Request for Comments)が、本文書は世間一般で言う RFC ではありません。また、仕様書や参考文献ではなく、単なる覚え書きです。

SYNOPSIS

実例1 (C:Client, S:Server)
C> あの…これ…<br>
S> 100 Continue (なんでそ?)<br>
C> (パケットの送信を開始)<br>
S> 200 OK (ありがと〜)<br>

これは、うまくいった場合の例である。
クライアントは、1ヶ月以内にさらにレスポンスを返す必要がある。

実例2
C> 今晩お暇ですか?
S> 500 Internal Error (家には妻子がいて…その…)
(しばらくして)
S> 102 Accepted※ (考え直したらしい)

※…なお、このステータスコード102は慣例によるものであって、通常は100の使用が推奨される。

実例3
   :
C> ひっどーい私とは遊びだったのね!
S> 101 Switching Protocol (ちょ、ちょっと、大声出すなよ)

んー、いい例が思いつかない…あんまりトラブル巻き込まれたことないしなぁ…

*1 もともと「ホワイトデーのためのプロトコル」(http://washitake.com/diary/?date=20030311) として公開、その後移転&タイトル変更。2005年2月:サーバー・クライアントモデルがおかしかったので書き換え。2005年10月、http://a.hatena.ne.jp/pikopikohammer/?date=20030311 より再度移転。

本日のツッコミ(全3件) [ツッコミを入れる]
hoge (2004-02-09 17:04)

すごい!の一言です。よこぞここまで書きましたね。

wassy (2004-02-12 05:54)

暇だったんですよ、きっと。いや、むしろ忙しさの中での現実逃避か…

caprin (2004-02-14 02:24)

単純におもしろかったです。やはり3倍以上送らないと駄目!?


1980|03|
1986|04|
1998|04|
2002|01|11|
2003|03|04|05|07|08|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|02|03|04|06|07|08|11|12|
2008|01|02|03|04|06|07|08|09|10|
2009|01|12|
2011|05|10|11|
2012|01|02|10|