アプリ版:「スタンプのみでお礼する」機能のリリースについて

マルチキャストとは、グループ内ブロードキャストと考えていのでしょうか?

そうなると、サーバからの送信のみでホストからの要求に対しての応答はどうなるのでしょうか?
TVやラジオなどのように情報の途中から取得するようなものなのでしょうか?


基本が間違っていたら、存分につっこんでください。(ToT)
よろしくお願いいたします。

A 回答 (4件)

マルチキャストはIGMP(Internet Group Management Protocol)というプロトコルを使って、ルータとホスト間でどのホストがグループに加入するか、しないかを制御します。


マルチキャストの利点は、余計な帯域を回線上で使わない、というのもありますが、一番大きな利点は受信したくないホストのCPU負荷を下げるというものです。
いったんIGMPでグループ化されると、そのグループへのアドレス(マルチキャストアドレス)宛てのパケットはルータから加入済みホストへ渡されます。

マルチキャストアドレスはクラスDの224.x.x.xのようなものです。ルータはネットワーク内でPIMやMOSPF, DVMRPなどのマルチキャストルーティングプロトコルによってルーティングを行います。レイヤ2においてはIPマルチキャストアドレス(224.x.x.x)をMACマルチキャストアドレス(01:00:5E:x:x:x)にマッピングしてホストに投げ、ホストがマルチキャストグループに加入していれば受信、していなければ破棄となります。

ホストからの要求というのは、送信先アドレスはサーバでしょうから、ユニキャストでしょうね。ホストからマルチキャストアドレス宛てには投げないと思うので。

「途中から取得」という表現がよくわかりませんが、おそらくマルチキャストでIP-TVのようなアプリケーションを流していたときにホストが途中から参加した場合、ということとしていいますと、「情報の途中から取得する」とおっしゃっているのは“そのとおり”になりますよ。
    • good
    • 0
この回答へのお礼

詳しい説明ありがとうございます。
「途中から取得・・・」求めていたのはまさに回答されたとおりです。

で、まだ頭が整理されていないので、間違いだらけかもしれませんが...
今内部LAN(マルチキャスト対応ルータやL3-SW)で
サーバ-複数クライアント間で大量のデータ転送が発生するので
マルチキャストはどうだろう?と思い調べているところです。

この場合、クライアントからの要求なのでユニキャストになるのですね。
「マルチキャストを通常の業務で活用する」それは難しいのでしょうか?(意味がない?)

お礼の欄で書く内容ではないですね ^ ^;)
すみませんでした。

回答を糧にいろいろと調べてみます。

お礼日時:2001/04/11 14:36

いえいえ、参考になれば幸いです。


ちなみにわたし、ネットワーク関連のメルマガを出しているのでよかったらお読みください。
http://www.mag2.com/m/0000063498.htm
まだ出したばかりで読者も少ないので、ただいま読者募集中なのです。。。^^;

参考URL:http://www.xai.nu/ipnet
    • good
    • 0
この回答へのお礼

早速拝見させていただきました。というか登録しちゃいました。
すばらしいメルマガですね。
現場にでると、基本がわかってなくてもなんとかなるもので...
ただ、障害発生時には、やはりネットワーク知識が重要となるんですよね。

これを見られている「自称:ネットワーク管理者」(自分もそうなのですが^ ^;)
ぜひお勧めいたします!

ありがとうございました。

お礼日時:2001/04/12 09:14

データが大量に発生しているという原因はわかっているのでしょうか?


たとえば、ブロードキャストトラフィックとユニキャストトラフィックの割合など。
根本的な問題がデータが大量に発生していてネットワーク負荷が重い、ということでしたら、ルータやスイッチを容量の大きいものに変えるとか、サブネットを切ってブロードキャストトラフィックを減らすということが考えられます。
ネットワークの規模がどれほどのものかわかりませんが、他にはルータに負荷がかかりすぎていて処理が遅いとか、余計なルーティングプロトコルを動かしていてトラフィックオーバヘッドが大きくなっている、などが考えられますね。
マルチキャストはやはりネットワーク特性よりもアプリケーション特性で選ぶものと思うので。
    • good
    • 0
この回答へのお礼

的確なご指摘ありがとうございます。

現状では他に影響がでるほと負荷がかかっていないので、
ネットワークの見直しは考えていませんでした。

マルチキャストの技術が使えるとなると将来性を考慮して、
導入検討をしてみようかと思った次第です。

★確かに、ネットワークが遅くなったら、マルチキャストよりも
 他にやることがありますよね ^ ^;)

ありがとうございました。

お礼日時:2001/04/11 16:53

ブロードキャスト … 全員(不特定)


マルチキャスト … 特定複数

という認識であれば、その特定複数を指して「グループ内」という
のもあながち間違いとも言いづらいですね。

決定的に違うのは大きな構成のネットワークを考えた場合に、
ネットワーク全体にかける負荷の違いがある、ということです。

ネットワーク内の特定複数に対して送信する必要があるが、その
相手は常に固定ではなく、時と場合に応じて変わる、ということを
考えた場合に、ブロードキャストではネットワーク全体に常に負荷が
かかりますが、マルチキャストの場合には、その経路だけに負荷が
かかるという違いがあります。


> サーバからの送信のみでホストからの要求に対しての応答はどうなる

アプリケーションの組方次第です。

例えば、館内放送で呼出しとその応答みたいなことを考えると
呼出しはマルチキャストで、「ここに居るよ」という応答を
ユニキャストで実装すれば良い。

特定小数のチャットみたいなアプリケーションであれば、
それぞれのクライアントにマルチキャストでの送信と
して実装する、みたいに。


いわゆる「情報用語辞典」みたいなところ(→参照URL)に載っている
説明では、ブロードキャストとの大きな違いは良く分かりませんね。

参考URL:http://www.e-words.ne.jp/view.asp?word=%83%7D%83 …
    • good
    • 0
この回答へのお礼

早速の回答ありがとうございます。
今現在もいろいろと勉強中です。

チャットの利用という意見でなんとなく利用価値がわかりました。
サーバ主体の配信システムでは「いまさら使い道がないのでは?」と思ってたのもので。

インターネット上ではなく、社内のネットワーク(特にWAN回線)上で
マルチキャストを導入する意味があるか検討しようかと思っています。

まわりの導入事例等を調べて、もっと勉強してみます。

お礼日時:2001/04/10 09:31

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!