マルチキャスト技術の今後

1 ：01/11/23 〜 最終レス ：11/08/09

ユニキャスト全盛のIPネットワーク網において、
マルチキャストの入り込む余地はあるのか？
そもそも、マルチキャストは帯域を守り、サーバーへの負荷の削減を
ISPにとっては美味しい技術であるが、
受信者側から見たら、別にユニキャストでもマルチキャストでも
変わらない。
また、ISP側から見ても、ルーターの変革が必須であるし、
NATとの相性が悪いなど、問題は山積みである。
今度、IPv6が台頭してマルチキャスト技術は
再注目されるのか？
マルチキャストの今後を考えたい。
諸君らの、有意義な考えを聞かせて欲しい。

2 ：

おっと、間違えた。
サーバーへの負荷の削減を→サーバーへの負荷を削減できるなど、

3 ：

>そもそも、マルチキャストは帯域を守り、サーバーへの負荷の削減を
>ISPにとっては美味しい技術であるが、
>受信者側から見たら、別にユニキャストでもマルチキャストでも
>変わらない。
サーバ負荷が下がるってのは利用者のメリットにはならんの？
受信者側の内部LANに複数のユーザがいれば、上位Linkの帯域を節約できるし
マルチキャストで提供可能なサービスをユニキャストで流すことのほうが犯罪かと、、、
確かにネットワーク機器がきっちり対応してくれないと苦しいけど

4 ：

>>3
サーバーの負荷が下がるってのは、受信者側のメリットにはならないんじゃないかな？
まぁ、負荷が下がる事で遅延が押さえられたりするのは、有効ではあるけれど。
>受信者側の内部LANに複数のユーザがいれば、上位Linkの帯域を節約できるし
そうだな。
つまりこれは、ISP（というか、同一ドメイン内）のメリットであって、レシーバーにはそういう部分は見えないから、
ユニキャストでも、マルチキャストでもいいのよ。
>マルチキャストで提供可能なサービスをユニキャストで流すことのほうが犯罪かと、、、
>確かにネットワーク機器がきっちり対応してくれないと苦しいけど
言ってることは激しく同意だけど、
問題は、なんでマルチキャストが有効だとわかっていて、
ここまで整備が整わないのか？
つまり、マルチキャストは根本的に問題を抱えているのか？
って事なんだな。
マルチキャストが有効であるなら、ISPは、積極的にマルチキャストルータを整備するべきだけど、
それを行わないのは、
１）新技術がまだ浸透してない→これから整備が進む？
２）マルチキャストの有効性が見いだせない→バックボーンが太くなってきて、ユニキャストでも今後数年は事足りる？
３）経済的な問題→整備するのにお金が無い？
とまぁ、こんな感じっす。
この板の住民はどういう考えを持っているよ？

5 ：

ISPにマルチキャストルータを導入させるほどの力を持った
コンテンツプロバイダが存在しないということでは。
Ciscoなんかは大規模コンテンツはMulticastではなくてCDN薦めているし。

6 ：

ISP/iDCは帯域を売っているのだから
マルチキャスト使われてお客さんの帯域消費減って
減速オーダとかされるのはイヤーンなりよ。
ユニキャストでバンバン帯域使ってもらって
増速オーダカモーン！

7 ：

↑ISPの本音っぽいな、これは

8 ：

もっと本音が聞きたい！
(ﾟ∀ﾟ)ｲｲ!!

9 ：

イントラの業務アプリ開発やってるんだが、マルチキャストで
P2P モドキやりたいねぇ。いや、ほんとにイントラだったら
使いどころたくさんあると思うけど、なかなかコボラーたちに
は受け入れがたいもんがあるようだね。

10 ：

マルチキャスト、というと妙な誤解してる開発者多いんだけどどうよ:
　1)全マシンにパケット送るのでネットワーク負荷が高い。
　　→マルチキャストの仕組みを知らないだけ。
　2)パケロスや化けを検知できないので信頼できない。
　　→確認・リトライ手順とサムチェックを定義する。
1)はまだ良いよ。10Base-T のリピータハブの仕組みと
合わせて説明してやるとたいてい納得するんだけど、2)
が受け入れがたいらしいね。「UDP は信頼できない」が
定説として張り付いているらしい。
　・アプリケーションサーバの起動・終了通知
　・サーバ起動監視 (全アプリケーションサーバへの一斉 Ping)
　・負荷テストツールの一斉開始 (200 台にアプレット表示させて
　　一台からよーいドン)
　・定番のメッセージツール
今までにマルチキャスト使ったツールはこんなかな。
他に何か面白いもの作ってる人いる？

11 ：

>>1
鎌倉市から接続の吉川くんじゃん。
どしたの？話題変えて新スレですか？

12 ：

>>5
なるほどね。
コンテンツプロバイダーの問題かぁ。
たとえばさ、アスキーがインターネットラジオやってるけれど、
あれはかなりの視聴者がいると思うんだけど、
パイオニアにはなれないかなぁ。
ＣＮＮなんかは、動画ストリーミングをおこなってるしね。
スターダストとか、利用してる人はいるかな？
>>6
面白い考えだなぁ。
でも、視野が狭いとも思えるわな。
>>9
具体案が聞きたいね。

13 ：

>>10
>1)全マシンにパケット送るのでネットワーク負荷が高い。
>　　→マルチキャストの仕組みを知らないだけ。
全マシンにパケットを送るってのは、
DVMRPのようなデンスモードでのルーティングプロトコルの事を言ってるのか？
まぁ、確かに一時的に高負荷になるわな。
リピーターハブ云々のクダリは、よくわからんが、説明が聞きたい気もするな。
>2)パケロスや化けを検知できないので信頼できない。
>　　→確認・リトライ手順とサムチェックを定義する。
これは、要するにTCPが利用できないって事だな。
ACK集約が起こるからね。
じゃぁ、UDPしか利用できないのかというと、
そういうわけでもなくて、リライアブルなトランスポートプロトコルが
整備されているから、今後のマルチキャスト利用の動機付けになるかな。
>・アプリケーションサーバの起動・終了通知
　・サーバ起動監視 (全アプリケーションサーバへの一斉 Ping)
　・負荷テストツールの一斉開始 (200 台にアプレット表示させて
　　一台からよーいドン)
　・定番のメッセージツール
このあたりは、現場の声って感じで、なかなか興味深いっすなぁ。
>・サーバ起動監視 (全アプリケーションサーバへの一斉 Ping)
これに関しては、意味無いね。
送ったらPingが帰ってくるわけだし、帰ってくるのを受け止める余裕があるなら無理して使う必要はないかな。
たいしてバンド幅を使わないものに対して、グループ管理したりするほうが
大変そうだ。
引き続き、面白い情報を待つ！

14 ：

>>11
なんじゃそりゃ？
スレ違いか？

15 ：

> DVMRPのようなデンスモードでのルーティングプロトコルの事を
> 言ってるのか？
すまん、ネットワーク詳しくないのでよく分からん。前の話のは、
ログイン時に保存しといた IP アドレスにユニキャストで投げま
くるようなものと考えて。
> 送ったらPingが帰ってくるわけだし、帰ってくるのを受け止める
> 余裕があるなら無理して使う必要はないかな。
サーバの台数や IP アドレスがあらかじめわかっている場合はね。
マルチキャストの利点に「相手のアドレスや台数がわからなくても
サービス開始していれば見つけられる」というのがあるっしょ
(JINI とかでネットワーク上のサービスを LOOKUP するのはこれだ
わな)。サーバの台数増やした時やテスト用サーバが立った時、音声
応答等の別目的サーバが立ったときなんか、クライントをわざわざ
設定しなおさなくても良いので、監視クライアントがどこで何台
立っててもかまわない構成に出来るから。
まぁ金融システムみたいな莫迦みたいに巨大なシステムは、どこで
どんな製品がポートリスニングしてるか分かんないから、いきなり
マルチキャストでパケット投げるのはチト怖いもんがあるけどな。
とりあえず企業イントラではそれほど制約なく使えるけど、あまり
有効に使われてないってのが現状かな。

16 ：

>>15
なるほど。
言われてみて納得のサービスだな。
俺は、IPマルチキャストアドレスの割り当てに詳しくないのだが、
たしか、固定に割り当てるのではなく、DHCPのように
空いてるアドレスをその都度割り当てるという事らしいのだが、
このシステムでは、アドレスの割り当てはどうしてるのだ？

17 ：

おっと、企業イントラ限定かな。
金融システムとかだと、閉じた空間でのネットワークになりそうだしな。
技術者達よ、マルチキャストの話を聞かせれ！

18 ：

>>16 そうか? Java だとクラス D の固定 IP アドレス & ポート
使ってやるけどな。先の Ping で使ったのは 228.100.100.1/2950
だったよ。
http://java.sun.com/products/jdk/1.2/ja/docs/ja/api/java/net/MulticastSocket.html
まぁ企業イントラだと動画のブロードキャスト配信なんて無いから
サービスの LOOKUP が使われどころというところかな (サービスが
ファイルだと P2P ファイル交換になるかな)。

19 ：

つーかルータの負荷がシャレにならんのだ。
ユニキャストだとステートレスにルーティングできるけど、�
マルチキャストの場合は木を維持しなきゃならないからね。
現状のユニキャストだけでもイッパイイッパイなのに、
さらに負荷のかかるマルチキャストはかなりキツい。
マルチキャストについては、よいチュートリアルがあるぞ＞１
http://www.soi.wide.ad.jp/iw2000/iw2000_tut/slides/13/index_bar.html

20 ：

つーか、そういう話とは違うのかな

21 ：

>>19
(・∀・)ｲｲ!!線をついてきたな。
おっしゃるとおりに、ルーターへの負荷はかかるようだ。
つまりだな、ここで問題となることは、
ルータでのある程度の負荷と、帯域の温存とのトレードオフなのだな。
さらに言うと、パケットのフォワーディグ以上に、
IGMPでのホスト・ルーター間でのやりとりに、えらい負荷がかかるようだ。
IGMP　Queryを６０秒に１回出すわけで、なんだか
本当に帯域削減なってんのかよ＆ルーターに負荷かかりすぎー！って感じだな。
貼ってるリンクのサイトは、以前に全部プリントアウトして
熟読したよ。
でも、有意義な情報ありがとう。

22 ：

>>18
プログラムを組む人では無いので、
っていうか、学生なんだけど、
その辺の話は、なかなか疎いのよ。
クラスＤ云々ってのは、なによ？
閉じたネットワークでの構築か？
オープンなネットワークか？
そもそもＩＡＮＡで、IPv4でのマルチキャストアドレスは、
初っぱなが1110*.*.*で始まるアドレスにするという風に決められた
背景があるわけだな。

23 ：

>>19 おう、いいチュートリアルだな!!
今まで使って覚えただけだから良い勉強になったよ。

24 ：

>>19
資料紹介、産休です。いい資料ですね。

25 ：

マルチキャストの問題点については、以下でも記載あり
http://www.janog.gr.jp/meeting/janog8/program.html
てきとーに引用してみる
---------------------------------------
まず、なぜ“なめてんじゃねー”というほど複雑なのかを説明したいと思います。
”Multicast　Mechanism”ClassDタイプ、インターネットスタンダードマ
ルチキャストのメカニズムを説明します。ジョインしてくる人に、ダイナ
ミックにマルチキャストをしてあげようというコンセプト。ひとつの配送
木ごとに経路エントリーをひとつ。配送木が通っているところには、すべ
てルータの上にエントリがなくてはいけないのが、難しい原因となってい
る。配信をやっている間中、KeepAliveをしてくるし、送信者が変わると
配信経路エントリは別に必要になり全体として膨大な情報が必要。しかも
それぞれが頻繁に変更を起こす。”なめてんじゃねー”というのが納得で
きる。
”グループ数スケーラビリティ問題”
スケーラビリティをざっくりいうと、100万グループを持つとなると、
１００万経路を保持しないといけないし、それらにKeep　Aliveをしないといけない。。。
それをさばけるルータはほんとうに実現可能なのか？
マジでできるのか、できると思って良いのか？
”トンネルによるMulticast展開”
では、マルチキャストの展開をどうしていくか。
充分ひろいネイティブなMulticast backboneは残念ながら存在しないので、nativeな小さいネットをユニキャストで結ぶ。トンネリングなので、
構造が複雑になってしまう。
オペレーションも複雑になり、それが、アカデミックにしか広がっていかない理由になっている。

26 ：

Wid●か。。。う〜む笑
高品質リアル映像を流す網とか、バックボーンの帯域計算がチャネル基本で
計算できるというのはうれしいと思うぞ。。
>>16　おさらい
棒社配信サーバとかではCH(MluticastGroupAddress)をかぶらない様に管理して、
動作例、C社IPTVなら、ClientがまずサーバにユニキャストでCH対応Groupアドレス
を教えてもらって、その後IGMPでルータにそのグループに参加を認めてもらう。
同じ網に、チャネル管理するサーバが乱立して、ダブって放送チャンネルがかぶ
った場合は。。。放送事故(別映像がさぶみになるこうか)なんでしょうか？
経験者おられます？どうなんのか知らん。

27 ：

>>26
つーか、そういうことがおきたらそれはネットワークの設計ミス。

28 ：

>>27
いま一般的例C社とか機器では如何にNW設計されておられます？
ネットワーク(ルータ？)で特定CH、配信できるI/Fを限定
するとかなんでしょうか？

29 ：

>>28
違う配信元が同じGroupで存在しないように設計しなければならない。
ルータではなくてMulticastネットワークの設計の問題。

30 ：

>>29
となると、おれは商用、キャリア考え。
その設計ミスとか悪意呼の発生は網提供における前提です。
きみはMboneなど実験への有志・参加団体の考えなのかな？
MBoneとかは実際そうやって管理してるのかね？
なんかすごいと思うが。。。

31 ：

いろんな意見をありがとう！
>>25
そもそも、マルチキャストが提唱されてから、
Mboneで実験使用を重ねてきて、現在の形に落ち着いて来たわけだが、
そもそも、Mboneのコンセプトが問題だったのか？
1)Mboneは、世界規模のネットワークを想定していない
2)商用的に利用する事を考えていない
まぁ、この辺だろうな。
>>5が書いているように、コンテンツ・サービス・プロバイダーが
いないから、マルチキャストが使われないのか？
それとも、マルチキャストのコンセプトが間違っていたのか？

32 ：

>31
おっしゃるように、そもそものコンセプトが実用と離れたところに
あったと思われ。ルータ屋や、オペレータからみると、ふざけてんじゃ
ねー、でしかないです。

33 ：

>>32
だとしたら、マルチキャストに未来はあるのだろうか？

34 ：

たぶん、コンテンツデリバリ系に収束するんじゃないだろうかな。
管理可能、設計可能、課金可能だし。

35 ：

>>30
そもそも僕は広域網でMulticastは使い物にならないと思ってる。
現実にGroupを一意に管理する方法が無い以上、閉塞網で運用せざるを
えず、同じポリシーで運用される閉塞網同士を Tunneling 等で相互接続する
ことはあっても、IP AddressのようにどこにいてもreachableなMulticastネット
ワークは現在は構築できない。

36 ：

そういえばIIJ4Uが一般ユーザ向けにマルチキャストやってるな。一応。
>>33
とりあえずはコンテンツデリバリ系でしのいで、
究極的にはP2Pでマルチキャストのようなものが
実現されていくと思う。あとXCAST。
つまり、余程大きな改良がない限り、
現状のグループマルチキャストに未来はないと思う。

37 ：

>36
激しく同意。WIDE系の人と話してると、結構フレームになるポイントだが。

38 ：

uuu

39 ：

うーん、ネットワークの負荷もあるけど、ぶろーどばんどとかで、1.5Mbpsだ8Mbpsだ
とかでマジでストリームとか見られると出すサーバもシャレにならないのでは？
って、考えるとマルチキャストもいいのではないですかね？シロウト的すぎ？

40 ：

結局今の所、マルチキャストはインターネット網では今の所使い物にならないという理解で間違ってないでしょうか？

41 ：

　　　　　　　　　　　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣＼
Λ＿Λ　　|　君さぁ　こんなスレッド立てるから　　　　　　　　 　|
（　´∀｀）＜　厨房って言われちゃうんだよ　　　　　　　　　 　 　|
（ ΛΛ つ ＞―――――――――――――――――――‐＜
　( ﾟДﾟ) ＜　おまえのことを必要としてる奴なんて　　 　　　　　 |
　/つつ　　|　いないんだからさっさと回線切って首吊れ　　　 　|
　　　　　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_／
(-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ…
(∩∩) (∩∩) (∩∩)
(-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ…
(∩∩) (∩∩) (∩∩)
(-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ…
(∩∩) (∩∩) (∩∩)

42 ：

（＾＾）

43 ：

MulticastのIXにおけるsource discoveryはどのポリシーで進むのだろう？

44 ：

（＾＾）

45 ：

（＾＾）

46 ：

47 ：

48 ：

ＩＰインフラで放送しようって時代だから、使うんじゃねえの？マルチたんﾊｱﾊｱ。

49 ：

50 ：

マルチキャストなのにオンデマンド。
http://www.sony.co.jp/Products/magnacast/
売れてんのかな？

51 ：

52 ：

今後の活動どうしよ

53 ：

54 ：

　　　 　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

55 ：

56 ：

>>52
J/Splash ってまだあるんですか？
もしあるなら参加してデジタルTV放送を受信したいです。
デジタルラジオ放送実験も始まったしこれからはIPマルチキャストの時代ですね。

57 ：

>>56
J/SplashのMulticastIXはもうないね、M-bone-JPは
まああると言えばあるけれど…
グローバルマルチキャストネットワークはスケールし
ない、J/SplashやJP-Mboneに関わってつくづく思ったね。
ビジネスとして、Multicastが成り立ちえるのは、閉域網
だけだと思う。

58 ：

つまりYahooBB最高、とそういいたいわけですか。

59 ：

地域IP網最高、と。
いつやるかと思っていたけど、Flets.NETでましたな。

60 ：

>>59
それって、IPv4/6 Multicastでけるの？

61 ：

MBONEのtunnelについて聞きたいんですが、
　　　　　　　　　　　　　　|←---------------- tunnel ----------------→|
| host Ａ |------| mrouted A |-----( Internet )-----| router |-----| mrouted B |---| host B |
　　↑　　　　　　　　　　↑　　　　　　　　　　　　　　　 　↑　 　　↑　　　　　　↑　　　　 　　　↑
　　Ｇ　　　　　　　　　　 Ｇ　　　　　　　　　　　　　　　　 Ｇ　 　　 P P P
＊host A側のルーターは省いてあります。
＊Ｇ：グローバルアドレス　　　Ｐ：プライベートアドレス
−−設定(/etc/mrouted.conf)−−
mrouted A:
tunnel <mrouted A> <mrouted B> metric 1 threshold 1
mrouted B:
tunnel <mrouted B> <mrouted A> metric 1 threshold 1
このような環境で二つのmrouted間のトンネリングは可能でしょうか？
host B側のルーターで、ＮＡＴを使用しています。
マルチキャストルーティングプロトコルはＤＶＭＲＰで、
mroutedにはお互いにＤＶＭＲＰ−probeのメッセージが届いています。
しかし、mrouted Bのアドレスがプライベートアドレスであるために、
うまくＭＢＯＮＥを構築することができません。
やはり、このような環境ではＭＢＯＮＥを構築することができないのでしょうか？
もし、何か方法があればよろしくお願いします。

62 ：

ずれたのでもっかい。
MBONEのtunnelについて聞きたいんですが、
　　　　　　　　　　　　　　|←---------------- tunnel ----------------→|
| host Ａ |------| mrouted A |-----( Internet )-----| router |-----| mrouted B |---| host B |
　　↑　　　　　　　　　　↑　　　　　　　　　　　　　　　　　 　↑　 　　↑　　　　　　↑　　　　 　　　↑
　　Ｇ　　　　　　　　　　 Ｇ　　　　　　　　　　　　　　　　　　 Ｇ　 　　 P　　　　　　 P 　　　　　　　　P
＊host A側のルーターは省いてあります。
＊Ｇ：グローバルアドレス　　　Ｐ：プライベートアドレス
−−設定(/etc/mrouted.conf)−−
mrouted A:
tunnel <mrouted A> <mrouted B> metric 1 threshold 1
mrouted B:
tunnel <mrouted B> <mrouted A> metric 1 threshold 1
このような環境で二つのmrouted間のトンネリングは可能でしょうか？
host B側のルーターで、ＮＡＴを使用しています。
マルチキャストルーティングプロトコルはＤＶＭＲＰで、
mroutedにはお互いにＤＶＭＲＰ−probeのメッセージが届いています。
しかし、mrouted Bのアドレスがプライベートアドレスであるために、
うまくＭＢＯＮＥを構築することができません。
やはり、このような環境ではＭＢＯＮＥを構築することができないのでしょうか？
もし、何か方法があればよろしくお願いします。

63 ：

>>62
図がずれてしまいすいません。。。。

64 ：

>>35
>現実にGroupを一意に管理する方法が無い
一意に管理しなくてもＳＳＭ（Source-Specific Multicast）を使えば、
たとえグループアドレスが重なっていても、ソースアドレスは違うはずだから、
問題ない。
それとも、セッションの広報面で？
>>62
mroutedに限ったことじゃなくて、6to4トンネルやIPsec(トンネルモード)でも同じことが言えるんだが、
トンネリングする区間にＮＡＴを使用することは無理。
ＮＡＴは上位層のプロトコルまで世話を見てくれないからね。

65 ：

メリットなし

66 ：

>>64
SSMで今迄のマルチキャストグループの大きな問題が解決する事が
出来るのは分かるけれど、ルータにソースごとに枝狩りされた
木構造の情報を持てるようにしておくってのは、グローバルインター
ネットの規模では常識的に考えて無理そう。

67 ：

SSMで今迄のマルチキャストグループ？

68 ：

一度、mrouted Bをグローバルアドレスにして以下のような接続にしてやってみたのですが、
二つのmroutedの区間はtunnelすることができません。
map-mbone localhost　としてみると　[1/1/tunnel/down]と出てしまいます。
インターネットを介すと何か特別な設定なんかがいるのでしょうか？
　　　　　　　　　　　　|←----------- tunnel -----------→|
| host Ａ |------| mrouted A |-----( Internet )-------| mrouted B |---| host B |
　　↑　　　　　　　　　↑　　　　　　　　　　 　　　　　　 　　↑　　　　　　　↑
　　Ｇ　　　　　　　　　 Ｇ　　　　　　　　　　　　　　　　　 Ｇ　 　　 　　Ｇ
＊関係のないルーターは省いてあります。
＊Ｇ：グローバルアドレス

69 ：

IGMPのプロトコルフィルタにひっかかってるとか？

70 ：

>>69
ＩＧＭＰのプロトコルフィルタが原因でした。

71 ：

rd5y

72 ：

age

73 ：

http://www.nec.co.jp/press/ja/0503/1102.html
マルチキャスト通信における自律的な通信品質管理を実現

74 ：

誰か技術面から突っ込んでくり。
【通信】NEC、テレビ放送を超える高品位なインターネット放送システムを開発 [03/14]
http://news18.2ch.net/test/read.cgi/bizplus/1110771275/

75 ：

76 ：

>74
ネットワーク機器ではすでに実装済み。
新しくも何ともない。
こういうのにだまされるのはユーザは大体検討つきますよ。

77 ：

バックアップ用ISDN回線の待機系ルータでIGMPとDVMRPを有効にしたら
発呼しまくるんですけど何とかなりませんか？

78 ：

>77
turn off.

79 ：

Ciscoの資格でやたらPIM-SMを推奨してるけど実際のとこどうなの？

80 ：

ネットワーク関係の仕事から離れて早８年、
mboneはどうなったの？
検索しても古い情報しかヒットしなくて。

81 ：

てす

82 ：

結局あーだこーだと知恵捏ね繰り回して遊んでるだけかい

83 ：

IPv6のマルチキャストが話せない機器はｺﾞﾐ。
Ciscoマンセー！

84 ：

本国で上手くいってるなら
日本の状況なんかにいちいち合わせてられない
外国ゲーの宿命

85 ：

test

86 ：

test

87 ：11/08/09

test