IPマルチキャスト勉強中

ネットワーク周りには全く素人だったので今の仕事では色々学ぶべきことが多い.ここ数日はマルチキャストの扱いに関して作業していた.マルチキャストで降ってくるデータを聞くモジュールを担当しており,Javaでちょろっと初期実装をでっち上げることまでは前に済んでいる.12月現在,聞くべきデータが聞ける環境はSSHで入れる別ネットワークにしか無いので,どうにか貰ってきたい.そのためにマルチキャストから得たデータグラムをTCPでクライアントに配信するゲートウェイ・サーバをPythonで書いた.TCPならSSHポート転送できるからね.Unix標準コマンドを使ってるこの辺の例に割と近い:

ただ netcat (aka nc(1)) はマルチキャストを聞けないっぽいのでPythonBSDソケットを叩くことにした次第.マルチキャスト対応の socat(1) とかあるらしいが,コンパイルの手間やコマンドライン・オプションの書式がわけわかめで余計めんどいと判断:

BSDソケット with Pythonは,やりたいあらゆることに関して,ぐぐればすぐサンプルがいくつも見つかる.それらは大抵本質的に同じ3, 4行でなんで最初から薄いラッパが標準ライブラリにあればいいのに,とか思う.SocketServer は微妙... 誰かが実用しているとは思い難い残念な感じ.

本格的な応用にはTornadoとかのfull fledgedなフレームワークを最初から使うんでしょうね...
IPマルチキャストの送受信はこうすればいいらしい(こういうときのStackOverflowのヒット率はマジ異常):

ちなみにPythonBSDソケットは「Cなら -1 が返るはずの相手方の切断で空文字列が返る」とか,確かに便利な改善なんだけど知っておかないといけないポイントがいくつかあるので,そこは別途慣れですね.すぐだけど.
IPマルチキャストというのは本質的にルーティングの技術で,上流にある全てのルータに思い通り動いてもらう必要がある.きちんと聞けるようになるにはプログラムが正しく自ホストのsyscallを叩くだけでなく,自ホストがきちんと上流ルータに通知し,また上流ルータがきちんと反応し... 複雑ですね.自ホストから直近のルータへの要求にはIGMP (Internet Group Management Protocol: IPデータグラムの "protocol" フィールドは2) というプロトコルが使われるが,これはBSDソケットでは直接送るものではなく,ソケットのオプションに対応してOSが勝手に送る.疑問:

  • netstat -g で自分の参加してる(つもりの)マルチキャストIPが表示されるのと,IGMP "Memmership Query" (参加要求)が実際に自ホストから発せられたかどうかは,等価なんだろうか? 等価なはずだよね... 等価だとイイナァ
  • IGMP ってパケット・スニッファで見えるのかな? まぁ試せば分かるはずのことだし,"tcpdump igmp" とかいう例がweb上にあるので見えるんだろうけど,不思議な感じ.考えてみればARPとかもBSDソケット経由でのユーザプロセスによる要求とは直接の関係なく送られるから一緒か.

実はまだ正しく受信できてない... どうも「マルチキャストRPF」というループ形成回避の仕組みがあって,ユニキャストのルーティング・エントリが無いホストからはマルチキャストのデータグラムが来てもOSがドロップするらしく,ルーティング表をネットワーク管理者に変えてもらわないといけない気がしている.

今回のためにDCで空きNICに新しくケーブルを刺してもらったんで,ルーティング設定までされてないんだろうと想像中.(と言うか netstat -r に無いものは無い)
しっかしマルチキャスト受信のためということでLANパッチング要求してるんだからネットワーク管理者の方で受信まで確認してから引き渡してくれないもんかね... これでどうやって給料に見合う働きをしてると証明できるのやら.... みたいなことは英語で言おうとしたらこうなった:

Well, today, there were some progress on this... we [Kai and the network admin] were getting closer to the common agreement on the current situation. On Monday, I'll test packet sniffering for IGMP, so maybe I can provide him [the network admin] more information for his work.

うーむ日本人表現(?)である... それを差し引いても色々怪しい... can と will を組み合わせられないとか欠陥言語である."will be able to" とか咄嗟に出てこねーよ.