マルチキャスト技術の今後
■ このスレッドは過去ログ倉庫に格納されています
0001名無し君
01/11/23 20:01ID:WWj2CW2uマルチキャストの入り込む余地はあるのか?
そもそも、マルチキャストは帯域を守り、サーバーへの負荷の削減を
ISPにとっては美味しい技術であるが、
受信者側から見たら、別にユニキャストでもマルチキャストでも
変わらない。
また、ISP側から見ても、ルーターの変革が必須であるし、
NATとの相性が悪いなど、問題は山積みである。
今度、IPv6が台頭してマルチキャスト技術は
再注目されるのか?
マルチキャストの今後を考えたい。
諸君らの、有意義な考えを聞かせて欲しい。
0002名無し君
01/11/23 20:03ID:WWj2CW2uサーバーへの負荷の削減を→サーバーへの負荷を削減できるなど、
0003anonymous@
01/11/23 20:12ID:???>ISPにとっては美味しい技術であるが、
>受信者側から見たら、別にユニキャストでもマルチキャストでも
>変わらない。
サーバ負荷が下がるってのは利用者のメリットにはならんの?
受信者側の内部LANに複数のユーザがいれば、上位Linkの帯域を節約できるし
マルチキャストで提供可能なサービスをユニキャストで流すことのほうが犯罪かと、、、
確かにネットワーク機器がきっちり対応してくれないと苦しいけど
00041
01/11/23 20:29ID:WWj2CW2uサーバーの負荷が下がるってのは、受信者側のメリットにはならないんじゃないかな?
まぁ、負荷が下がる事で遅延が押さえられたりするのは、有効ではあるけれど。
>受信者側の内部LANに複数のユーザがいれば、上位Linkの帯域を節約できるし
そうだな。
つまりこれは、ISP(というか、同一ドメイン内)のメリットであって、レシーバーにはそういう部分は見えないから、
ユニキャストでも、マルチキャストでもいいのよ。
>マルチキャストで提供可能なサービスをユニキャストで流すことのほうが犯罪かと、、、
>確かにネットワーク機器がきっちり対応してくれないと苦しいけど
言ってることは激しく同意だけど、
問題は、なんでマルチキャストが有効だとわかっていて、
ここまで整備が整わないのか?
つまり、マルチキャストは根本的に問題を抱えているのか?
って事なんだな。
マルチキャストが有効であるなら、ISPは、積極的にマルチキャストルータを整備するべきだけど、
それを行わないのは、
1)新技術がまだ浸透してない→これから整備が進む?
2)マルチキャストの有効性が見いだせない→バックボーンが太くなってきて、ユニキャストでも今後数年は事足りる?
3)経済的な問題→整備するのにお金が無い?
とまぁ、こんな感じっす。
この板の住民はどういう考えを持っているよ?
コンテンツプロバイダが存在しないということでは。
Ciscoなんかは大規模コンテンツはMulticastではなくてCDN薦めているし。
0006hage
01/11/23 23:27ID:???マルチキャスト使われてお客さんの帯域消費減って
減速オーダとかされるのはイヤーンなりよ。
ユニキャストでバンバン帯域使ってもらって
増速オーダカモーン!
0007sag
01/11/24 00:15ID:???0008名無しさん
01/11/24 02:07ID:NghHC/i+(゚∀゚)イイ!!
0009ananiiremasu
01/11/24 03:01ID:???P2P モドキやりたいねぇ。いや、ほんとにイントラだったら
使いどころたくさんあると思うけど、なかなかコボラーたちに
は受け入れがたいもんがあるようだね。
0010ananiiremasu
01/11/24 03:31ID:3CK+47BM1)全マシンにパケット送るのでネットワーク負荷が高い。
→マルチキャストの仕組みを知らないだけ。
2)パケロスや化けを検知できないので信頼できない。
→確認・リトライ手順とサムチェックを定義する。
1)はまだ良いよ。10Base-T のリピータハブの仕組みと
合わせて説明してやるとたいてい納得するんだけど、2)
が受け入れがたいらしいね。「UDP は信頼できない」が
定説として張り付いているらしい。
・アプリケーションサーバの起動・終了通知
・サーバ起動監視 (全アプリケーションサーバへの一斉 Ping)
・負荷テストツールの一斉開始 (200 台にアプレット表示させて
一台からよーいドン)
・定番のメッセージツール
今までにマルチキャスト使ったツールはこんなかな。
他に何か面白いもの作ってる人いる?
00121
01/11/24 04:36ID:7zKnBF8zなるほどね。
コンテンツプロバイダーの問題かぁ。
たとえばさ、アスキーがインターネットラジオやってるけれど、
あれはかなりの視聴者がいると思うんだけど、
パイオニアにはなれないかなぁ。
CNNなんかは、動画ストリーミングをおこなってるしね。
スターダストとか、利用してる人はいるかな?
>>6
面白い考えだなぁ。
でも、視野が狭いとも思えるわな。
>>9
具体案が聞きたいね。
00131
01/11/24 04:43ID:7zKnBF8z>1)全マシンにパケット送るのでネットワーク負荷が高い。
> →マルチキャストの仕組みを知らないだけ。
全マシンにパケットを送るってのは、
DVMRPのようなデンスモードでのルーティングプロトコルの事を言ってるのか?
まぁ、確かに一時的に高負荷になるわな。
リピーターハブ云々のクダリは、よくわからんが、説明が聞きたい気もするな。
>2)パケロスや化けを検知できないので信頼できない。
> →確認・リトライ手順とサムチェックを定義する。
これは、要するにTCPが利用できないって事だな。
ACK集約が起こるからね。
じゃぁ、UDPしか利用できないのかというと、
そういうわけでもなくて、リライアブルなトランスポートプロトコルが
整備されているから、今後のマルチキャスト利用の動機付けになるかな。
>・アプリケーションサーバの起動・終了通知
・サーバ起動監視 (全アプリケーションサーバへの一斉 Ping)
・負荷テストツールの一斉開始 (200 台にアプレット表示させて
一台からよーいドン)
・定番のメッセージツール
このあたりは、現場の声って感じで、なかなか興味深いっすなぁ。
>・サーバ起動監視 (全アプリケーションサーバへの一斉 Ping)
これに関しては、意味無いね。
送ったらPingが帰ってくるわけだし、帰ってくるのを受け止める余裕があるなら無理して使う必要はないかな。
たいしてバンド幅を使わないものに対して、グループ管理したりするほうが
大変そうだ。
引き続き、面白い情報を待つ!
0015ananiiremasu
01/11/24 05:18ID:3CK+47BM> 言ってるのか?
すまん、ネットワーク詳しくないのでよく分からん。前の話のは、
ログイン時に保存しといた IP アドレスにユニキャストで投げま
くるようなものと考えて。
> 送ったらPingが帰ってくるわけだし、帰ってくるのを受け止める
> 余裕があるなら無理して使う必要はないかな。
サーバの台数や IP アドレスがあらかじめわかっている場合はね。
マルチキャストの利点に「相手のアドレスや台数がわからなくても
サービス開始していれば見つけられる」というのがあるっしょ
(JINI とかでネットワーク上のサービスを LOOKUP するのはこれだ
わな)。サーバの台数増やした時やテスト用サーバが立った時、音声
応答等の別目的サーバが立ったときなんか、クライントをわざわざ
設定しなおさなくても良いので、監視クライアントがどこで何台
立っててもかまわない構成に出来るから。
まぁ金融システムみたいな莫迦みたいに巨大なシステムは、どこで
どんな製品がポートリスニングしてるか分かんないから、いきなり
マルチキャストでパケット投げるのはチト怖いもんがあるけどな。
とりあえず企業イントラではそれほど制約なく使えるけど、あまり
有効に使われてないってのが現状かな。
00161
01/11/24 05:32ID:7zKnBF8zなるほど。
言われてみて納得のサービスだな。
俺は、IPマルチキャストアドレスの割り当てに詳しくないのだが、
たしか、固定に割り当てるのではなく、DHCPのように
空いてるアドレスをその都度割り当てるという事らしいのだが、
このシステムでは、アドレスの割り当てはどうしてるのだ?
00171
01/11/24 05:34ID:7zKnBF8z金融システムとかだと、閉じた空間でのネットワークになりそうだしな。
技術者達よ、マルチキャストの話を聞かせれ!
0018ananiiremasu
01/11/24 05:51ID:???使ってやるけどな。先の Ping で使ったのは 228.100.100.1/2950
だったよ。
http://java.sun.com/products/jdk/1.2/ja/docs/ja/api/java/net/MulticastSocket.html
まぁ企業イントラだと動画のブロードキャスト配信なんて無いから
サービスの LOOKUP が使われどころというところかな (サービスが
ファイルだと P2P ファイル交換になるかな)。
0019anonymous@ N030063.ppp.dion.ne.jp
01/11/24 06:07ID:HUw8ulV2ユニキャストだとステートレスにルーティングできるけど、
マルチキャストの場合は木を維持しなきゃならないからね。
現状のユニキャストだけでもイッパイイッパイなのに、
さらに負荷のかかるマルチキャストはかなりキツい。
マルチキャストについては、よいチュートリアルがあるぞ>1
http://www.soi.wide.ad.jp/iw2000/iw2000_tut/slides/13/index_bar.html
002019
01/11/24 06:26ID:???00211
01/11/24 06:38ID:lZz9dTzv(・∀・)イイ!!線をついてきたな。
おっしゃるとおりに、ルーターへの負荷はかかるようだ。
つまりだな、ここで問題となることは、
ルータでのある程度の負荷と、帯域の温存とのトレードオフなのだな。
さらに言うと、パケットのフォワーディグ以上に、
IGMPでのホスト・ルーター間でのやりとりに、えらい負荷がかかるようだ。
IGMP Queryを60秒に1回出すわけで、なんだか
本当に帯域削減なってんのかよ&ルーターに負荷かかりすぎー!って感じだな。
貼ってるリンクのサイトは、以前に全部プリントアウトして
熟読したよ。
でも、有意義な情報ありがとう。
00221
01/11/24 06:49ID:lZz9dTzvプログラムを組む人では無いので、
っていうか、学生なんだけど、
その辺の話は、なかなか疎いのよ。
クラスD云々ってのは、なによ?
閉じたネットワークでの構築か?
オープンなネットワークか?
そもそもIANAで、IPv4でのマルチキャストアドレスは、
初っぱなが1110*.*.*で始まるアドレスにするという風に決められた
背景があるわけだな。
0023ananiiremasu
01/11/24 07:16ID:???今まで使って覚えただけだから良い勉強になったよ。
0025nobody
01/11/24 14:50ID:???http://www.janog.gr.jp/meeting/janog8/program.html
てきとーに引用してみる
---------------------------------------
まず、なぜ“なめてんじゃねー”というほど複雑なのかを説明したいと思います。
”Multicast Mechanism”ClassDタイプ、インターネットスタンダードマ
ルチキャストのメカニズムを説明します。ジョインしてくる人に、ダイナ
ミックにマルチキャストをしてあげようというコンセプト。ひとつの配送
木ごとに経路エントリーをひとつ。配送木が通っているところには、すべ
てルータの上にエントリがなくてはいけないのが、難しい原因となってい
る。配信をやっている間中、KeepAliveをしてくるし、送信者が変わると
配信経路エントリは別に必要になり全体として膨大な情報が必要。しかも
それぞれが頻繁に変更を起こす。”なめてんじゃねー”というのが納得で
きる。
”グループ数スケーラビリティ問題”
スケーラビリティをざっくりいうと、100万グループを持つとなると、
100万経路を保持しないといけないし、それらにKeep Aliveをしないといけない。。。
それをさばけるルータはほんとうに実現可能なのか?
マジでできるのか、できると思って良いのか?
”トンネルによるMulticast展開”
では、マルチキャストの展開をどうしていくか。
充分ひろいネイティブなMulticast backboneは残念ながら存在しないので、nativeな小さいネットをユニキャストで結ぶ。トンネリングなので、
構造が複雑になってしまう。
オペレーションも複雑になり、それが、アカデミックにしか広がっていかない理由になっている。
0026まるちゃん
01/11/24 15:53ID:???高品質リアル映像を流す網とか、バックボーンの帯域計算がチャネル基本で
計算できるというのはうれしいと思うぞ。。
>>16 おさらい
棒社配信サーバとかではCH(MluticastGroupAddress)をかぶらない様に管理して、
動作例、C社IPTVなら、ClientがまずサーバにユニキャストでCH対応Groupアドレス
を教えてもらって、その後IGMPでルータにそのグループに参加を認めてもらう。
同じ網に、チャネル管理するサーバが乱立して、ダブって放送チャンネルがかぶ
った場合は。。。放送事故(別映像がさぶみになるこうか)なんでしょうか?
経験者おられます?どうなんのか知らん。
つーか、そういうことがおきたらそれはネットワークの設計ミス。
0028まるちゃん
01/11/24 16:15ID:???いま一般的例C社とか機器では如何にNW設計されておられます?
ネットワーク(ルータ?)で特定CH、配信できるI/Fを限定
するとかなんでしょうか?
違う配信元が同じGroupで存在しないように設計しなければならない。
ルータではなくてMulticastネットワークの設計の問題。
0030まるちゃん
01/11/24 17:15ID:???となると、おれは商用、キャリア考え。
その設計ミスとか悪意呼の発生は網提供における前提です。
きみはMboneなど実験への有志・参加団体の考えなのかな?
MBoneとかは実際そうやって管理してるのかね?
なんかすごいと思うが。。。
00311
01/11/24 17:21ID:GRLZGA04>>25
そもそも、マルチキャストが提唱されてから、
Mboneで実験使用を重ねてきて、現在の形に落ち着いて来たわけだが、
そもそも、Mboneのコンセプトが問題だったのか?
1)Mboneは、世界規模のネットワークを想定していない
2)商用的に利用する事を考えていない
まぁ、この辺だろうな。
>>5が書いているように、コンテンツ・サービス・プロバイダーが
いないから、マルチキャストが使われないのか?
それとも、マルチキャストのコンセプトが間違っていたのか?
0032nobody
01/11/24 17:44ID:???おっしゃるように、そもそものコンセプトが実用と離れたところに
あったと思われ。ルータ屋や、オペレータからみると、ふざけてんじゃ
ねー、でしかないです。
00331
01/11/24 18:00ID:GRLZGA04だとしたら、マルチキャストに未来はあるのだろうか?
0034nobody
01/11/24 18:21ID:???管理可能、設計可能、課金可能だし。
そもそも僕は広域網でMulticastは使い物にならないと思ってる。
現実にGroupを一意に管理する方法が無い以上、閉塞網で運用せざるを
えず、同じポリシーで運用される閉塞網同士を Tunneling 等で相互接続する
ことはあっても、IP AddressのようにどこにいてもreachableなMulticastネット
ワークは現在は構築できない。
0036anonymous
01/11/24 20:08ID:???>>33
とりあえずはコンテンツデリバリ系でしのいで、
究極的にはP2Pでマルチキャストのようなものが
実現されていくと思う。あとXCAST。
つまり、余程大きな改良がない限り、
現状のグループマルチキャストに未来はないと思う。
0037nobody
01/11/24 20:39ID:???激しく同意。WIDE系の人と話してると、結構フレームになるポイントだが。
0038anonymous@ 218.45.66.58.eo.eaccess.ne.jp
02/01/19 22:56ID:???0039koge
02/01/28 00:15ID:???とかでマジでストリームとか見られると出すサーバもシャレにならないのでは?
って、考えるとマルチキャストもいいのではないですかね?シロウト的すぎ?
0040ななし
02/07/03 23:59ID:5G6dwULJ0041名無しさん
03/01/03 01:48ID:???Λ_Λ | 君さぁ こんなスレッド立てるから |
( ´∀`)< 厨房って言われちゃうんだよ |
( ΛΛ つ >―――――――――――――――――――‐<
( ゚Д゚) < おまえのことを必要としてる奴なんて |
/つつ | いないんだからさっさと回線切って首吊れ |
\____________________/
(-_-) ハヤクシンデネ… (-_-) ハヤクシンデネ… (-_-) ハヤクシンデネ…
(∩∩) (∩∩) (∩∩)
(-_-) ハヤクシンデネ… (-_-) ハヤクシンデネ… (-_-) ハヤクシンデネ…
(∩∩) (∩∩) (∩∩)
(-_-) ハヤクシンデネ… (-_-) ハヤクシンデネ… (-_-) ハヤクシンデネ…
(∩∩) (∩∩) (∩∩)
0042山崎渉
03/01/15 22:21ID:???0043nothing
03/03/08 02:45ID:V2fmH/8S0044山崎渉
03/03/13 17:03ID:???0045山崎渉
03/04/17 12:20ID:???0046あぼーん
NGNG0047あぼーん
NGNG0048?
03/05/22 20:15ID:???0049あぼーん
NGNG0050anonymous@ usen-219x120x44x141.ap-US.usen.ad.jp
03/05/23 00:06ID:lKz/ZRN/http://www.sony.co.jp/Products/magnacast/
売れてんのかな?
0051あぼーん
NGNG0052J/Splash
03/06/15 06:37ID:???0053あぼーん
NGNG0054ぼるじょあ ◆yBEncckFOU
03/08/02 05:26ID:???ピュ.ー ( ・3・) ( ^^ ) <これからも僕たちを応援して下さいね(^^)。
=〔~∪ ̄ ̄ ̄∪ ̄ ̄〕
= ◎――――――◎ 山崎渉&ぼるじょあ
0055あぼーん
NGNG0056_
03/10/12 05:34ID:???J/Splash ってまだあるんですか?
もしあるなら参加してデジタルTV放送を受信したいです。
デジタルラジオ放送実験も始まったしこれからはIPマルチキャストの時代ですね。
0057PWD
03/10/13 21:06ID:???J/SplashのMulticastIXはもうないね、M-bone-JPは
まああると言えばあるけれど…
グローバルマルチキャストネットワークはスケールし
ない、J/SplashやJP-Mboneに関わってつくづく思ったね。
ビジネスとして、Multicastが成り立ちえるのは、閉域網
だけだと思う。
0058名無しだよもん@カラアゲうまうま
03/11/27 14:29ID:???0059名無しだよもん@カラアゲうまうま
04/01/17 09:21ID:05dKMRvRいつやるかと思っていたけど、Flets.NETでましたな。
0061デフォルトの名無しさん
04/01/28 11:41ID:+cQjExNv|←---------------- tunnel ----------------→|
| host A |------| mrouted A |-----( Internet )-----| router |-----| mrouted B |---| host B |
↑ ↑ ↑ ↑ ↑ ↑
G G G P P P
*host A側のルーターは省いてあります。
*G:グローバルアドレス P:プライベートアドレス
−−設定(/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側のルーターで、NATを使用しています。
マルチキャストルーティングプロトコルはDVMRPで、
mroutedにはお互いにDVMRP−probeのメッセージが届いています。
しかし、mrouted Bのアドレスがプライベートアドレスであるために、
うまくMBONEを構築することができません。
やはり、このような環境ではMBONEを構築することができないのでしょうか?
もし、何か方法があればよろしくお願いします。
0062デフォルトの名無しさん
04/01/28 11:43ID:???MBONEのtunnelについて聞きたいんですが、
|←---------------- tunnel ----------------→|
| host A |------| mrouted A |-----( Internet )-----| router |-----| mrouted B |---| host B |
↑ ↑ ↑ ↑ ↑ ↑
G G G P P P
*host A側のルーターは省いてあります。
*G:グローバルアドレス P:プライベートアドレス
−−設定(/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側のルーターで、NATを使用しています。
マルチキャストルーティングプロトコルはDVMRPで、
mroutedにはお互いにDVMRP−probeのメッセージが届いています。
しかし、mrouted Bのアドレスがプライベートアドレスであるために、
うまくMBONEを構築することができません。
やはり、このような環境ではMBONEを構築することができないのでしょうか?
もし、何か方法があればよろしくお願いします。
0063デフォルトの名無しさん
04/01/28 11:44ID:???図がずれてしまいすいません。。。。
0064名無しさん
04/01/28 17:38ID:+cQjExNv>現実にGroupを一意に管理する方法が無い
一意に管理しなくてもSSM(Source-Specific Multicast)を使えば、
たとえグループアドレスが重なっていても、ソースアドレスは違うはずだから、
問題ない。
それとも、セッションの広報面で?
>>62
mroutedに限ったことじゃなくて、6to4トンネルやIPsec(トンネルモード)でも同じことが言えるんだが、
トンネリングする区間にNATを使用することは無理。
NATは上位層のプロトコルまで世話を見てくれないからね。
0065anonymous@ 220.110.160.231
04/01/28 21:08ID:???0066フォン・リヒトフォーフェン
04/01/28 21:18ID:???SSMで今迄のマルチキャストグループの大きな問題が解決する事が
出来るのは分かるけれど、ルータにソースごとに枝狩りされた
木構造の情報を持てるようにしておくってのは、グローバルインター
ネットの規模では常識的に考えて無理そう。
0067anonymous@ p2019-ipbf308osakakita.osaka.ocn.ne.jp
04/01/28 21:23ID:5Frvj4gm0068デフォルトの名無しさん
04/01/28 22:48ID:dL5SWo5D二つのmroutedの区間はtunnelすることができません。
map-mbone localhost としてみると [1/1/tunnel/down]と出てしまいます。
インターネットを介すと何か特別な設定なんかがいるのでしょうか?
|←----------- tunnel -----------→|
| host A |------| mrouted A |-----( Internet )-------| mrouted B |---| host B |
↑ ↑ ↑ ↑
G G G G
*関係のないルーターは省いてあります。
*G:グローバルアドレス
0069anonymous@ AIRH032110024.ppp.infoweb.ne.jp
04/01/28 23:37ID:???0070デフォルトの名無しさん
04/01/29 20:57ID:???IGMPのプロトコルフィルタが原因でした。
0071デカ丸 ◇HJszsgpjak
04/06/14 00:39ID:???0072anonymous@ AIRH03234008.ppp.infoweb.ne.jp
04/07/12 19:26ID:y8U/xeFv0073な
05/03/14 17:37:28ID:sVRmOY1Wマルチキャスト通信における自律的な通信品質管理を実現
0074遊動人
05/03/15 04:21:08ID:cInAqAs5【通信】NEC、テレビ放送を超える高品位なインターネット放送システムを開発 [03/14]
http://news18.2ch.net/test/read.cgi/bizplus/1110771275/
0076T
2005/11/27(日) 22:06:47ID:???ネットワーク機器ではすでに実装済み。
新しくも何ともない。
こういうのにだまされるのはユーザは大体検討つきますよ。
0077anonymous@ acspro002082.adsl.ppp.infoweb.ne.jp
2006/03/18(土) 02:42:29ID:vq2Po3a9発呼しまくるんですけど何とかなりませんか?
0078to
2006/03/19(日) 17:27:08ID:???turn off.
0079SAN-FRAN
2006/04/09(日) 23:56:37ID:???0080anonymous@ 219.117.195.12.user.rb.il24.net
2006/09/24(日) 00:12:40ID:YcwLg0kMmboneはどうなったの?
検索しても古い情報しかヒットしなくて。
0082anonymous@195.122.231.222.megaegg.ne.jp
2009/08/22(土) 10:16:48ID:HDm8GbsJ0083ccna
2009/10/23(金) 22:16:27ID:???Ciscoマンセー!
0084anonymous@p92e3ab.chibnt01.ap.so-net.ne.jp
2010/11/10(水) 12:48:52ID:???日本の状況なんかにいちいち合わせてられない
外国ゲーの宿命
■ このスレッドは過去ログ倉庫に格納されています