原理的には,バーチャルネットワークを構成し,そこでブロードキャストとユニキャストを定義するだけ.
・初回接続時は,ネットワークに参加しているサーバントを手動で指定するが, 次回からは前回の切断時に把握していた参加サーバントのうち,IP-reachableであるものを順に試していく.
・IP-reachableなサーバントは,誰かに接続が成功した時点で自分の「接続しました自己紹介」をブロードキャストし,以後はコネクションを切って待てば,他のサーバントからの自己紹介がユニキャストで続々届く.
・IP-reachableでないサーバントは,(マスカレードの場合) 最初に接続成功した相手を(もしも禁止されていなければ)「受信ポイント」と決め, その情報も含んだ自己紹介をブロードキャストし,以後この相手とのコネクションを維持する.
・ログオフ時には「切断します」をブロードキャストするのだが, もし強制終了などでその手順をはぶいてもいいように, IRCやICQのように数分ごとに「Keep Alive＋自己紹介」をブロードキャストする. 他のサーバントは,この間隔の1.5倍ほどにわたってKeepAliveを受けていない相手をオンラインリストから外す.
・接続してきた相手にいちいち自己紹介をユニキャストで返すのは面倒かもしれないし, 何かの拍子に失敗するかもしれないが,数分のうちにはKeepAlive自己紹介で必要な情報は届く.
・というか,「接続しました」と「KeepAlive」の内容には違いがないので区別する必要がない. これを受け取った相手が,オンラインリストと比較して,新規接続してきた者には自分の情報をユニキャストしてやればよいだけ.
・ブロードキャストの送信アルゴリズムはconcept2の通り,「隣接」する全ての相手にコピーする. ・「隣接」の定義は,自分が知っているIP-reachableなサーバント全て,及び自分に対して接続を維持しているnon-reachableなサーバント. つまり,トポロジーはほぼ網型.
・上で,隣接の定義を,reachableなサーバントの中の１０個程度としても,おそらく問題は無い. 少なすぎれば島が複数に分離してしまう可能性が増え,多ければ上の定義に近づく. このあたりは経験と,１０個程度を選び出すアルゴリズムの工夫でチューンできる部分. サーバントが数百規模になった場合は負荷にかなりの違いがでると思われる.
・個人間のメッセージは,相手の自己紹介を見て,直接とどけるか,指定されている受信ポイントに委託する.
いままでマルチスレッドのクラス生成がよくわからんで, Windowsの非同期ソケットでごまかしてきたので, 押し付ける気は無いですが自力では不安が…といったところ.
[8/27 (2001)]