It's my understanding that IP multicasting works by receivers joining IP multicast groups with IGMP messages, senders sending to those addresses, and routers addressed in that way duplicating the message and sending to all receivers in the group.
I've never elected to join a multicast group. What software that I might use would likely join a group on my behalf? Do commonly-used programs often send to multicast addresses on my behalf? What tools, especially command-line tools, expose this information? Something similar to what ipcs provides for shared memory, what ps provides for processes, etc. I'm especially interested in linux or OSX environments.
Use
netstat -g
NB there is no duplication. If a router has members inside, it propagates the datagram, once, on the inside LAN.
Related
Pardon my limited knowledge in networks.
I am trying to setup two small programs as client and server, which join to a particular multicast group. The servers sends some arbitrary data to the group and the client receives the data as it listens to the group.
This of course is possible with UDP programs which I have already done. However I need to work with MAC addresses instead of IPs. And I have a few questions regarding this:
Is it possible to fix a range of MAC addresses for my multicast application ? As I understand, the least significant bit of the first octet in the MAC address signifies if it is multicast or not. So the multicast MAC should look like 01:*:*:*:*:* . So I guess, there should be some way to use a wide range of MAC addresses (except for those reserved).
Many places it is written as All multicast MAC addresses begin with: 0100.5e . Is it always true? AFAIK this prefix is fixed in the MAC address which leaves space for the rest of the IP address bits to be mapped here. But what if my application doesn't care about IP addresses and listens to multicast groups based on MAC addresses (if it is possible) ?.
Can't I keep the first octet as 01 and use a wide range for my multicast addressing ?
How to send packets to a multicast group and listen to a multicast group only based on MAC addresses and irrespective of IP ? i.e. the multicast group addresses are defined based on MACs.
I hope my questions made sense.
If you are not using IP (or UDP on top of that) then the default way of mapping IP addresses to mac addresses have probably no added value for you. These mappings are specified for example in:
http://en.wikipedia.org/wiki/IP_multicast#Layer_2_delivery
rfc1112 https://www.rfc-editor.org/rfc/rfc1112 paragraph 6.4
If you insist on using layer2 and multicasting it will probably be sufficient to send out frames with the LSB of the first octet set (the multicast bit, ref: http://en.wikipedia.org/wiki/File:MAC-48_Address.svg ). And put your own mapping on top of that. But you should take into account that:
you probably need to force your NIC to pass the data, often NIC's filter out frames they are interested in hardware. And these filters are typically set when joining a group or e.g. when setting the ALLMULTI flag).
There is probably networking equipment in the middle and some pseudo-intelligent switches may refuse to forward data unless they have seen IGMP joins (ref igmp snooping).
And you code will obviously need to deal with raw layer 2 sockets to read out the data.
Considering the ease of just using UDP this may be a lot of work.
If you have a switch with at least one subscriber to a multicast address, how much additional load would each additional subscriber add?
Example:
You have a 10G switch (with IGMP) with 10 servers and no other activity.
When Server1 subscribers to a 1G multicast feed, the switch will have 1G of load.
What would the load be after Server2 and Server3 subscribed?
Obviously traffic to the switch would not increase, but what about the switch's internal load?
Houw would the answer be different without IGMP?
The whole idea of multicast is that it is efficient. The presence of one subscriber downstream causes the switch to send an IGMP join request of its own upstream and pass incoming multicasts downstream, without duplication. The addition of further downstream subscribers has no effect at all except to increment an internal subscriber count for that group. When that goes back to zero it sends an IGMP leave request of its own upstream.
I don't know what you mean by 'without IGMP'. There is no such thing as UDP multicast without IGMP. It is a contradiction in terms.
Firstly, some background information for you.
The traditional definition of routers and switches are along the lines of:
Router: a device capable of routing a packet form one IP subnet to a different IP subnet
Switch: a device capable of switching a packet within the same IP subnet
However, this traditional definition no longer holds these days because we have switches that can route traffic from one IP subnet to another IP subnet and even perform complex operations such as QoS at wire speed.
Therefore it is often easier to redefine Routers and Switches as follows:
Router: a device that uses the CPU to route packets, often inspects parts of packets that are higher up the OSI layer.
Switch: a device with ASIC(s) (a.k.a switching chips) that switches/routes traffic at full wire speed. What this means is that if the switch has 24 1Gbps ports, it will be able to switch 24Gbps bi-directional traffic without dropping any packets.
Now, to answer your question, it is important to determine whether the ASIC in your switch is capable of handling multicast traffic or not. If so, adding "load" really isn't an issue, as long as you ensure that each switch port is not congested (e.g. 2Gbps of traffic trying to egress out of 1Gbps port). If the ASIC in your switch is NOT capable of handling multicast traffic, it is highly likely that the switch will simply send all multicast traffic up to the CPU. Then it would be up to the software to determine where each packet goes. CPUs on switches are not powerful, because their primary role isn't to route/switch packets, but to manage the switch (e.g. configure the ASIC so that packets get switched properly). Therefore, if your switch is sending packets up to the CPU, the switch will struggle. You won't get anywhere near 1Gbps of multicast via the CPU.
Without IGMP, switches, by default, will flood out the traffic on all ports. Again, this is not a problem for the switch itself because it can handle this at wirespeed. It may cause problems for other parts of the network because traffic is needlessly being duplicated.
The reason for this long answer is because the phrase "10G switch" in your example is quite misleading, and it led me to believe that you maybe thinking that a powerful CPU sits at the center of the switch that is capable of performing 10Gbps bi-directional switching. This is simply not the case, and talking about "load" on a switch therefore often makes little sense.
I hope this helps.
I am designing a system which has multiple small embedded systems hosts communicating in a LAN. UDP multicast fits nicely for my purpose.
But I am worried about multicast support in commonplace routers. I need to deploy the system to normal households equipped with a Wifi router, so I could encounter any kind of routers. I will use UDP broadcast if multicast will be more trouble than benefit.
To decide, I am thankful for any data or experience on multicast support in today's commonplace routers:
Do all consumer routers sold today support multicast reasonably? Limitation to LAN is not an issue for me, I do not need multicast across the Internet.
How about older routers?
Are there any big issues in commonplace multicast implementations I need to be aware of (e.g. packet drops, configuration issues, etc.)?
Are you talking switches or routers? In a consumer setting I suspect switches. My experience is that they all support multicast, though not at wire speed. Also the cheap ones tend to broadcast any multicast traffic to all ports (no IGMP snooping). Packet loss is definitely something you need to deal with, it can and will happen even on 'professional' networking gear.
Edit: as long as you are in switched network, you typically don't need to configure anything.
In many scenarios the equipment either does not support IGMP spoofing, or it is off by default. There are two problems:
Any wireless interface can be saturated by the traffic.
Poorly configured units may inadvertently route traffic out the default gateway stalling legitimate traffic.
In either case, you will have your equipment discarded as the cost of investigation will almost certainly outweigh the benefit received.
If your traffic has a limited rate and you are not concerned about the WiFi impact, you could use the local broadcast address to ensure delivery to recipients, without impacting on the routed communications.
You could install a discovery mechanism into your nodes it may be worthwhile to implement a unicast overlay to ensure that traffic does not have inadvertent impact.
A single larger group of customers with some non-compliant devices requesting support will swamp any costs associated with development or additional traffic caused by not implementing true multicasting.
In worst case scenarios, when the routers don't allow multicast traffic, I would encapsulate the multicast packets into a unicast IP address. This way the routers would handle them as normal unicast data. You might want to check mrouted .
Good luck
2 computers are in different subnets.
Both are Windows machines.
There are 2-5 IGMP-ready routers between them.
They can connect each other over multicast protocol (they have joined the same multicast group and they know about each other's existance).
How to establish a reliable TCP connection between them without any public server?
Programming language: C++, WinAPI
(I need a TCP connection to send some big critical data, which I can not entrust to UDP)
You haven't specified a programming language, so this whole question may be off-topic.
Subnets are not the problem. Routability is the problem. Either there is routing set up or there isn't. If they are, for example, both behind NAT boxes, then you're at the mercy of the configuration of the nat boxes. If they are merely on two different subnets of a routed network, it's the job of the network admin to have set up routing. So, each has an IP address, and either can address the other.
On one machine, you are going to create a socket, bind it to some port of your choice, and listen. On the other, you will connect to the first machine's IP + the selected port.
edit
I'm going to try again, but I feel like there's a giant conceptual gap here.
Once upon a time, the TCP/IP was invented. In the original conception, every item on the network has an IPV4 address, and every machine could reach every other machine, via routing, except for machines in the 'private' address space (10.x, etc).
In the very early days, the only 'subnets' were 'class A, class B, class C'. Later the idea of subdividing a network via bitmasks was added. The concept of 'subnet' is just a way of describing a piece of network in which all the hosts can deliver packets to each other by one hop over some transport or another. In a properly configured network, this is only of concern to operating system drivers. Ordinary programs just address packets over the network and they arrive.
The implementation of this connectivity was always via routing protocol. If you have a (physical) ethernet A over here, and a (physical) ethernet B over there, connected by some sort of point-to-point link, the machines on A need to know where to send packets for B. Or, to be exact, they need to know where to send 'not-A' packets, and whatever they send them needs to know where to send 'B' packets. In simple cases, this is arranged via explicit configuration: routing rules stuffed into router boxes or even computers with multiple physical interfaces. In more complex cases, routing boxes intercommunicate via protocols like EGP or BGP or IGMP to learn the network topology.
If you use the Windows 'route' command, you will see the 'default route' that the system uses to send packets that need to leave the local subnet. It is generally the address of the router box responsible for moving information from the local subnet to everywhere else.
The whole goal of this routing is to arrange that a packet sent from a.b.c.d to e.f.g.h will get there. TCP is no different than UDP, except that you can't get there by multicast or broadcast: you need to know the exact address of your correspondent.
DNS was invented to allow hosts to learn each other's IP addresses without having human being send them around in email messages.
All this stops working when people start using NAT and firewalls to turn off routing. The whole idea of NAT is that the computers behind the NAT box are not addressable at all. They all appear to have one IP address. They can send stuff out, but they can only receive stuff if the NAT box has gone to extra trouble to map them a port.
From your original message, I sort of doubt that NAT is in use here. I just don't understand your comment 'I don't have access to the network.' You say that you've sent UDP packets here and there. So how did you do that? What addresses did you use?
Hi i am on creating streaming application. in that i am using IP Multicasting.
Tell me how to validate the client before adding it in the group.
is that anything i have to do with IGMP?
You don't do it with your application.
IGMP is an internet layer protocol, it may not even reach your application.
Whenever a unit wants to receive multicast to a certain address, it sends an IGMP request to join a group. A router receives the request and remembers that this user wants to belong to this group.
Whenever the router receives a multicast packed destined for that address, it routes it to all the group members, possibly taking some access control restrictions into account.
All group manupulation is performed by routers. You just send your UDP packets to a multicast address (that is 224/4), and the routers decide whether to route it to a subscriber.
If you want to limit destinations where your multicast packets go, you do it on routers.
You should understand though, that the word "routes" above means that the router emits the packet into appripriate interface with a multicast destination address in Ethernet header and multicast destination address in IP header. An Ethernet switch attached to the interface, if any, will distribute the packet over all active ports. Since it knows nothing about internet routing, it will just see the broadcast/multicast bit set in the Ethernet header and act accordingly.
There are, though, some link layer devices (Ethernet switches) who peek into network layer headers and limit multicast to the subscribed units. That is called IGMP snooping. Some of them can also be capable to control access.
OK, there is a legitimate need to control who can join a multicast group. The only way I can see that being done is by filtering IGMP packets inbound on the router interfaces. This would work if the list of "allowed subscribers" is sufficiently static, but if there's a lot of changes, it would rapidly become untenable.
If (and only if) there's administrative control all the way down to a "customer-placed" router, I suspect something could be done there, to limit the groups that device has visibility of, but that is heavily dependent of environment (in a "broadband and multicast video from a single provider" scenario, a contractual requirement for using a provider-managed DSL router would be possible).
In addition to Quassnoi's comments on how multicast works, I have to wonder... Why do you want to restrict multicast membership and/or validate the recipient before having it added to the group?