I am going through a networking book and it says that if we broadcast, message will reach to every hub/switch and will spread like tree. i.e. if we ignore timeout, broadcast will reach to all PCs in world?
if 'not', what stops switches from so?
if 'yes' is it feasible?
If everything is a pure switch/hub with no processing or blocking rules or VLAN translations, then yes a broadcast packet would reach everything.
However, in the real world, this is not the case. Most telecommunication providers prevent broadcast from going up into their network for security reasons. Additionally, networks may be subdivided into virtual LANs (VLANS) preventing endpoints on one VLAN from communicating with endpoints on other VLANs.
This is even before routers and gateways enter the mix, each of which may have it's own broadcast blocking rules.
Related
I'm currently working a network protocol which includes a client-to-client system with auto-discovering of clients on the current local network.
Right now, I'm periodically broadsting over 255.255.255.255 and if a client doesn't emit for 30 seconds I consider it dead (then offline). The goal is to keep an up-to-date list of clients runing. It's working well using UDP, but UDP does not ensure that the packets have been sucessfully delivered. So when it comes to the WiFi parts of the network, I sometimes have "false postivives" of dead clients. Currently I've reduced the time between 2 broadcasts to solve the issue (still not working well), but I don't find this clean.
Is there anything I can do to keep a list of "online" clients without this risk of "false positives" ?
To minimize the false positives, due to dropped packets you should alter a little bit the logic of your heartbeat protocol.
Rather than relying on a single packet broadcast per N seconds, you can send a burst 3 or more packets immediately one after the other every N seconds. This is an approach that ping and traceroute tools follow. With this method you decrease significantly the probability of a lost announcement from a peer.
Furthermore, you can specify a certain number of lost announcements that your application can afford. Also, in order to minimize the possibility of packet loss using wireless network, try to minimize as much as possible the size of the broadcast UDP packet.
You can turn this over, so you will broadcast "ServerIsUp" message
and every client than can register on server. When client is going offline it will unregister, otherwise you can consider it alive.
When a host sends out a broadcast, how does it calculate the number of packets (same) that it needs to send out so that all the other hosts on the same LAN would receive it? For example, when a host boots up, it sends a DHCP broadcast to all the other hosts in the LAN. How can it determine the number of packets (same) to send?
Ok, double checked with wikipedia. You mention both "broadcast/multicast" in your title, but they're significantly different from each other.
There is no calculation for broadcast. The answer is, you don't know, or care, how many other hosts are out there. You send a single packet to the broadcast address, and it's the responsibility of every host listening to act on the packet that was sent. On a Class C subnet, such as a 192.168.x.x, the broadcast address is 192.168.x.255.
With multicast, the originating host still only needs to send out one packet, so again, no calculation of total packets is needed. From wikipedia:
Multicast uses network infrastructure efficiently by requiring the
source to send a packet only once, even if it needs to be delivered to
a large number of receivers. The nodes in the network take care of
replicating the packet to reach multiple receivers only when
necessary.
I'm looking to write a toy application for my own personal use (and possibly to share with friends) for peer-to-peer shared status on a local network. For instance, let's say I wanted to implement it for the name of the current building you're in (let's pretend the network topology is weird, and multiple buildings occupy the same LAN). The idea is if you run the application, you can set what building you're in, and you can see the buildings of every other user running the application on the local network.
The question is, what's the best transport/network layer technology to use to implement this?
My initial inclination was to use UDP Multicast, but the more research I do about it, the more I'm scared off by it: while the technology is great and seems easy to use, if the application is not tailored for a particular site deployment, it also seems most likely to get you a visit from an angry network admin.
I'm wondering, therefore, since this is a relatively low bandwidth application — probably max one update every 4–5 minutes or so from each client, with likely no more than 25–50 clients — whether it might be "cheaper" in many ways to use another strategy:
Multicast: find a way to pick a well-known multicast address from 239.255/16 and have interested applications join the group when they start up.
Broadcast: send out a single UDP Broadcast message every time someone's status changes (and one "refresh" broadcast when the app launches, after which every client replies directly to the requesting user with their current status).
Unicast: send a UDP Broadcast at application start to announce interest, and when a client's status changes, it sends a UDP packet directly to every client who has announced. This results in the highest traffic, but might be less likely to annoy other systems with needless broadcast packets. It also introduces potential complications when apps crash (in terms of generating unnecessary traffic).
Multicast is most certainly the best technology for the job, but I'm wondering if the associated hassles are worth avoiding since this is just a "toy application," not a business-critical service intended for professional network admin deployment and configuration.
I have an application that is sending some UDP packets using multicast. I looked at the network traffic and there seems to be a lot of ancillary packets related to using multicast. I don't totally understand it, but does multicast by nature result in MORE network traffic. If so how can I throttle this down?
x
Other than the Multicast group join/remove messages, there are no ancillary messages created from you sending multicast data.
However, NIC's, routers, switches, printers, etc. all usually send some kind of multicast traffic, which is probably what you are seeing if you record the traffic.
In short, you need the networking equipment that forwards traffic between the client nodes to take care of this. Those vary depending on the network topology but would normally be:
Ethernet switches
IP routers.
Switch / router (implements functionality of a switch & router)
There are multicast control protocols such as IGMP but of course the source nodes and/or intermediate nodes (e.g. switches) must comply to these control protocols.
And YES multicast result in more network traffic : this is why plain Ethernet hubbing is practically extinct and additions to IEEE Ethernet such as VLANs are prevalent nowadays.
This is probably best addressed on some other sites (maybe this SO-style site PacketDrop).
LLC packets means you probably have sub-netting on your local segment, usually this doesn't mean extra packets though. You should change the network to a full class C if you want to remove LLC. On regular packets LLC or SNAP adds a 8-byte header.
http://ckp.made-it.com/ieee8022.html
I'm attempting to send multichannel audio over WiFi from one server to multiple client computers using UDP broadcast on a private network.
I'm using software called Pure Data, with a UDP broadcast tool called netsend~ and netreceive~. The code is here:
http://www.remu.fr/sound-delta/netsend~/
To cut a long story short, I'm able to achieve sending 9 channels to one client computer in a point-to-point network, but when I try to do broadcast to 2 clients (haven't yet tried more), I get no sound. I can compress the audio and send 4 channels compressed (about 10% size of uncompressed) over UDP broadcast to 2 clients successfully. Or I can send 1 channel over UDP broadcast to 2 clients, with some glitches.
The WiFi router is a Linksys WRT300N. All computers are running Windows XP. The IP addresses are 192.168.1.x, with subnet mask 255.255.255.0 and the subnet broadcast address: 192.168.1.255.
I'm curious - what happens to UDP broadcast packets in the router?
If I have a subnet mask of 255.255.255.0, then does the router make 254 packets for every packet sent ot the broadcast address?
My WiFi bandwidth is at least 100Mbps, but I can't seem to send audio of more than around 10Mbps over UDP broadcast to multiple clients.
What's stopping me from sending audio up to the bandwidth limit of the WiFi?
any suggestions for socket code modifications, network setups, router setups, subnet modifications... all very much appreciated!
thanks
Nick
Your problem is caused by the access point's rate control algorithm. With unicast the access point tracks what data rate every particular receiver can reliably receive at, and sends about that rate. With multicast the access point does not know which receivers are interested in the data, so simple access points send the data at the slowest possible rate (1Mb/s). Better implemented access points may send the data at the rate that the slowest connected client is using, and the best access points use IGMP snooping to see who's receiving each IP multicast stream, and they will choose the slowest rate out of the receivers for that stream.
The simplest solution is to not use multicast when you have a small number of WiFi receivers.
Are all parties connected via WiFi or is the sender using a
wired connection to the Access Point? Broadcast data will
be transmitted as unicast data from a station to an access
point and the access point will then retransmit the data
as broadcast/multicast traffic so it will use twice the
on-air bandwidth compared to when the sender sits on the
wired side of the AP.
When sending a unicast frame the AP will wait for an ACK
from the receiving station and it will retransmit the
frame until the ACK arrives (or it times out). Broadcast/multicast
frames are not ACKed and therefore not retransmitted.
If you have a busy/noisy radio environment this will
cause the likelyhood of dropped packets to increase,
potentially a lot, for multicast traffic compared to unicast
traffic. In an audio application this could certainly be audible.
Also, IIRC, broadcast/multicast traffic does not use the
RTS/CTS procedure for reserving the media which exarbates
the dropped packets problem.
It could actually be the case that multiple unicast streams
work better than a single multicast stream under less-than-ideal
radio conditions given that the aggregated bandwidth is
high enough.
If you can I would suggest that you use wireshark to sniff
the WiFi traffic and take a look at the destination address
in the 802.11 header. Then you can verify if the packets
are actually broadcast or not over the air.
Your design is failing due to a common misconception with WiFi speeds. With 802.11n the number 300mb/s is the link speed, not the actual bandwidth available for user data or even the IP layer. The effective bandwidth is closer to 40mb/s best case, have a look at the FAQ on SmallNetBuilder.com that discusses this in further detail.
http://www.smallnetbuilder.com/wireless/wireless-basics/31083-smallnetbuilders-wireless-faq-the-essentials
I'm curious - what happens to UDP broadcast packets in the router? If I have a subnet mask of 255.255.255.0, then does the router make 254 packets for every packet sent ot the broadcast address?
No the "router" doesn't make 254 individual packets. Furthermore, I suspect the protocol leverages "multicast" addresses rather than using a "broadcast" address.
Since broadcast/multicast traffic can easily be misused, there are many networking equipment that limit/block by default such traffic. Of course, some essential protocols (e.g. ARP, DHCP) rely on broadcast/multicast addresses to function and won't be blocked by default.
Hence, it might be a good thing to check for multicast/broadcast control knobs on your router.