[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: why multicasting is working?

Please read Multicast-HOWTO.gz! Especially:

...
1.1. What is Multicast.

Multicast is... a need. Well, at least in some scenarios. If you have
information (a lot of information, usually) that should be transmitted
to various (but usually not all) hosts over an internet, then
Multicast is the answer. One common situation in which it is used is
when distributing real time audio and video to the set of hosts which
have joined a distributed conference.

Multicast is much like radio or TV in the sense that only those who
have tuned their receivers (by selecting a particular frequency they
are interested on) receive the information. That is: you hear the
channel you are interested in, but not the others.
...
About ethernet layer:

2.4.3. Mapping of IP Multicast Addresses to Ethernet/FDDI addresses.

Both Ethernet and FDDI frames have a 48 bit destination address field.
In order to avoid a kind of multicast ARP to map multicast IP
addresses to ethernet/FDDI ones, the IANA reserved a range of
addresses for multicast: every ethernet/FDDI frame with its
destination in the range 01-00-5e-00-00-00 to 01-00-5e-ff-ff-ff (hex)
contains data for a multicast group. The prefix 01-00-5e identifies
the frame as multicast, the next bit is always 0 and so only 23 bits
are left to the multicast address. As IP multicast groups are 28 bits
long, the mapping can not be one-to-one. Only the 23 least significant
bits of the IP multicast group are placed in the frame. The remaining
5 high-order bits are ignored, resulting in 32 different multicast
groups being mapped to the same ethernet/FDDI address. This means that
the ethernet layer acts as an imperfect filter, and the IP layer will
have to decide whether to accept the datagrams the data-link layer
passed to it. The IP layer acts as a definitive perfect filter.
...
About the kernel:

3. Kernel requirements and configuration.

Linux is, of course (you doubted it?), full Level-2 Multicast-
Compliant. It meets all requirements to send, receive and act as a
router (mrouter) for multicast datagrams.

If you want just to send and receive, you must say yes to "IP:
multicasting" when configuring your kernel. If you also want your
Linux box to act as a multicast router (mrouter) you also need to
enable multicast routing in the kernel by selecting "IP:
forwarding/gatewaying", "IP: multicast routing" and "IP: tunneling",
the latter because new versions of mrouted relay on IP tunneling to
send multicast datagrams encapsulated into unicast ones. This is
necessary when establishing tunnels between multicast hosts separated
by unicast-only networks and routers. (The mrouted is a daemon that
implements the multicast routing algorithm -the routing policy- and
instructs the kernel on how to route multicast datagrams).
...
All my systems (router too!) have this all options about multicasting disabled! But, however, 
they support multicasting!
And you can read about Mbone. And more about ethernet layer you can read from sources: 
/usr/src/linux/Documentation/networking/multicast.txt

Mike Mestnik wrote:


--- Oleg Butorin <lists@mega-casino.ru> wrote:


Mike Mestnik wrote:


I'm not an expert on MC, but I'd think 224.0.0.1 would be routed to

your

default route.  Then the pkt would get multicasted and you would

receve

multiple responces.
Yes, but I received responces from the systems where multicasting disabled in the kernel. 
There is no difference on the end points, only the routing.  In MC the
routers must(MAY) take one packet and pass on multiple packets.  If a
No, the great feature of multicasting is to send only ONE packet to multicast address and other computers, who "subscribed" to this address, will receive this packet! 
I don't see what your saying/mean.  This subscription happens in place X,
if it happens on the recever then how dose the sender know who should get
the packet.  If it happens on the sender, why is there a MC ip.  Given all
the avalible info only the routers need to know anything about
subscriptions.  The router takes the MC packet and sends a copy to each of
it's directly upstream routers(or clients) that have subscriptions.
The sender just sends a PKT to the MC ip, no special software is needed. The recever needs only to subscribe, this is no specialer then sending an 
MC paket.  So it's clear that only the routers need special software, for
the end points there is nothing special about them.
For example (only in theory, I didn't set up this), I have 3 computers in my LAN: two workstations 
and one router. Multicasting disabled on all computers.
1. I send packet to address 224.0.0.254
2. This is multicast address, that's why on the network interface layer packet will have special destination MAC
No, this would mean all interface would have to be in promiscus mode. This would not be secure!!! 

Unless you mean MAC BC or MAC unicast, but not a MAC that isn't your own.
3. All hosts will receive this packet. There is no work for router in this case. Multicast packet will be delivered like broadcast. 
I don't think MC packets will use BC, only unicast pkts should be
deliverd.  If you want todo BC filetransfers there are other programs for
this.
4. In this stage I have a question. If system has multicasting enabled, it will unpack the packet with the special MAC and then will decide to answer to this packet or deliver it to the application. But I have multicasting disabled, and don't understand 
why kernel receive the packet with the special MAC and multicast IP.

The NIC will drop the special MAC and not forward it to the PCI(or system)
bus unless in promiscuos mode.  When a router sends an MC packet to more
then one host on the same subnet, a single unicast pkt is deliverd to
each.  The only saving here is the trip from the internet to the route and
only if it supports MC.

There is no ETHERNET support for MC, none, nada, zip.  MC is a newer proto
then ethernet and I don't think any replacement for eth will solve this
non-problem.
5. If router has option to route multicast packets, then the packet can be routed to the another network or multicast enabled router. 


normal router gets a MC packet it's likely just going to pass it to the
default route.



Normal router does nothing with the multicast packets.


IIRC kernel level MC support is only for if you want to be on Mbone,

not

if you want to use it as a client/server.


But the option called "IP: multicasting" and help:

This is code for addressing several networked computers at once,
enlarging your kernel by about 2 KB...


It also says if you wish to participate in Mbone.  The code dose allow

for

your computer to send more then one MC packet, but a normal kernel will
still send pakets to ANY IP 0.0.0.0 - 255.255.255.255.
Sorry, I don't understand, what do you mean "to send more then one MC packet"? 
All kernels can send packets to anywhere, the question is:
why it receive the alien packet???


And Mbone is the standard network, that supports multicasting
(routers, 
computers...).
As I understand, there is no special support for Mbone, this is
support 
for Multicasting.


That's correct, but without MC enabeled routers your one packet will

end

up going to a router with no default route and then you will get a
netunreach ICMP.
I don't speak about option "IP: multicast routing". It is clear, that this option for routing! 

Best regards,
Oleg.





		
_______________________________
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com
Reply to: