General Question About UDP Message Broadcasting

[quantass]

I have implemented UDP broadcasting in code so that i can "broadcast" my message to 200-300 pc's in my company's intranet. There can be 3 Sender computers (computers that broadcast out to Receivers), and Receiver computers that number in the 200+ range. However, i am in a situation where i need to have those 200+ Receivers pcs ( those that receive that broadcast message) to respond back to the Sender to let it know that that PC is alive, OR another likely possibilty...to broadcast out to a listening sender machine to let that sender know that it originally missed the original broadcast made by that sender so that the sender can find out the proper message for it to send to that new Receiver computer.

My question is ... if i have multiple Receiver computers broadcasting back onto a certain listening port (that the Sender machiens are listening on) at the same time will each and every UDP broadcasting message be received successfully onto the Sender machine even though multiple Receiver machiens were broadcasting at the same time out onto the same port OR will there be packet collisions and messages WILL be lost and thus only some messages MAY make it to those listening Sender machines (if at all)?

I am trying to figure out the best way to reduce large amounts of network traffic (this is why i am resorting to using UDP broadcasting) so that i dont have to speak to each sender/receiver out there.

Hope this makes sense. And if there are net resources on a detailed look on udp broadcasting (e.g. collision problems when multi-broadcasting from two different systems) id love to hear it.

Thanks BIG TIME!

[Mercantilum]

I guess your data link layer is Ethernet which takes care of preventing packets collisions on a single wire.
Even if UDP is said as "unreliable" (because there is not ack/resend and error detection defiend at the transport layer) - especially on a LAN - you should receive the packets. The network equipments (router / switch / hub) may drop some packets if they are overloaded (ie if their internal buffer is not able to contain all the traffic driven to a -e.g.- given port). Well, nowadays it should not happen often (depends on your network though).

In the case of your question I recommend some tests (as the answer depends on too many parameters) ; send continuously (during 1 minute) UDP packets containing an increasing number and check on 2 pcs that they receive everything (be careful to ensure that the sender pc buffer is not getting full!). If the test is unsuccessful try the same but a packet is sent every second (not continuously).

[quantass]

thanks for the feedback...hey, maybe by explaining what exactly i am doing you can see if my logic makes sense or if there are alternatives i can consider...

Here is what i want to do, so things are clear...Sorry for the length but i want you to understand the situation:

o There are two tools...a Sender and a Receiver. There "can" be more than 1 Sender . There WILL be many Receivers...about 200-300 computers. The Sender and Receivers are all witihin an INtranet.


o I have it so that the Sender simply sends out a basic message to the Receiver computer to display on his/her screen such as "Transfer all calls to Jersey". Because i want to send to hundreds of Receiver machines and the message is basic (simple text but that text can rangfe from a few words to 10kb in size) i decided to just UDP Broadcast it...

o The messages that are displayed on the Receiver computers do not get dismissed until the Sender computer tells it to hide/disappear.

o The problem arises when say new Receiver computers appear (e.g. a person logs onto a computer) "after" that broadcast message had been sent out. One solution could be to have the Sender computer reboradcast the message every 5 mins so that any new computers that appear after the broadcast will be informed eventually.

o However, As i said above, there can be multiple Sender computers. Because this is possible i want to have these Sender computers to be synched so that each Sender tool knows exactly what messages have been sent out. So if one sender broadcasts out a message all other Senders know about it. I was thinking that these Sender computers could have their own broadcast port that they communicate on..So when one sender sends out a message to the receivers it also sends out a broadcast msg to just the other senders to let them know that this happened.

o Interestingly, when one or more Receivers change their state (for example, the computer is logging out) i would like this Receiver computer to inform all the Senders that, that particular Receiver computer is changing its state (in this case, shutting down). If i were to go with the scenerio i described above, if there were a broadcast listening address that all the Senders were listening on then that particular Receiver machine could broadcast this "change state" messagfe onto this port and all the Senders would be immediately informed of this.

o I was thinking i could do all of this via TCP but the overhead involved by communicating to hundreds of computers one-by-one instead of broadcasting (since TCP doesnt support broadcasting) would be a nightmare on bandwitdh for the network.

o Because the Sender tool can be shutdown but still have the Receiver computers still showing a message on their screens then On Startup the Sender tool has to get an up-to-the-minute list of what each of the Receiver machines are displaying and so to do this, on startup the Sender tool broadcasts out a message to identifiy if their are other already running Sender tools. If there are then it asks one of these Sender tools to give this Sender tool an up-to-date list of what Receivers exist and what message theya re currently showing on screen. If no other Sender tool is running then this Sender broadcasts out a basic message to find all listening Receiver machines. Those receiver machines, upon getting this message reply back to that Sender machine letting it know what message it is showing. A list is now built up on this Sender machine on what Receivers are alive and what they are showing. Because there are hundreds of Recviever machiens that could be replying back i figure i will have each Receiver machine randomize a time from 0 secs to 2 mins on when it should reply back to that Sender's message so that the network isnt bogged down by all those machines calling back to that sender.

o The Sender tool not only can broadcast to "ALL" but should have the ability to broadcast to a selective cluster of computers based on what the user (of that Sender tool) selects. In this case of selectiveness i might as well use TCP to communicate to those computers since broadcasting would be out of the question.

o I like the idea of Broadcasting because of the low overhead in bandwidth usage and the realitive speed of transmissons. And udp's apckets are just so **** tiny compared to tcp. I just dont want to bog the intranet with constant talkback with all these computers and so the idea of broadcasting when i need to communciate would help reduce the load, as well as having other Sender tools update each other.

Is there a better way to do this? Should i just make the entire thing TCP and have my Sender tool just communicate to each Receiver one-by-one? I need to have these messages arrive instantly on all computers at once (just as udp broadcasting seems to do) and so TCP seems unlikely. Can someone tell me a better logic on how i could accomplish what i want to do?

[Mercantilum]

UDP broadcast alternative : there is multicast ; a configuration of your router (if it supports multicast) to send to multiple addresses. It is quite hard to implement and probably too complex for your simple messages - see this.

selective broadcast : as you probably know already UDP broadcast can be restrained to a subnet - if you LAN is configured as several pcs each one in a subnet, you can easily implement the UDP selective broadcast - see that. To my mind, as the packets are tiny and not that numberous, you better configure the client to drop the non expected packets. E.g. your paquets starts with a string "All ..." or "G1,2..." and each client is assigned a group number. When a packets comes it checks if it is either "All" or "Gx" where x is its group. In this case you don't have to cut your LAN in networks (a network interface not in promiscuous mode works this way).
By the way some routers are configured to filter the flooding udp broadcast (255.255.255.255)...

Startup and shtudown : the client which just boot should simply inform the servers that it's alive now, the server should send back all relevant information. Also when a client is going to shut down it should inform the servers. As you said, the clients may inform the servers about other relevant information (what they want to receive etc... it's a "subscription".

About the strategy : in your case it sounds fair to go for UDP broadcast. What I would add is a simple ACK in the protocol. When a server sends some information it expects a "Ack" from the client. I fit didn't receive a Ack from the client within 10 seconds it can check that the client is alive (ping) and - if yes - resend the data. The data being numbered the clients don't process twice the packet (in case it was received two times) and the Ack gets the same number so that the server knows which packet was received. The Ack is sends using a directed UDP packet.

[quantass]

Thanks very mcuh Mercantilum your input has been very useful.. I've rated you

[quantass]

Mercantilum, Quick Question for ya...

Can you tell me, is "Broadcasting" more intense on a network when used then say if i already knew the ip address of the computer i want to communicate to and just sent a message directly to that computer right away? I am just wondering how Boradcasting works....does it send just one message out and all the computers connected to that network just see that datagram on the network because since it has the special "broadcast" address each computer knows it is a message for them (the NIC will read a message from the network directed to its IP address or the broadcast address)? Or does the switch/router/whatever make duplicates of this datagram and spread it to each computer inside that network (i.e. translates the 255.255.255.255 broadcast address to the approparate destination -> each host computer... so if there are 200 host computers that 1 broadcast message gets converted to 200 datagrams that are sent -- one for each host computer inside that network)?

Thanks for the clarification

[Mercantilum]

1. How does it worked usually on a LAN (a few years ago :
- you send a packet (udp tcp whatever) to a given computer (not broadcast) on the same network
- the packet reaches a hub to which are connected 20 other computers
- all 20 computers receive the packet
- 20 of which 19 will discard the packet
- one will read the packet

Using a switching hub (same network):
- same as above, except that only one computer will receive the packet (the 19 others don't even receive it so don't have to discard it)

Sending to another network:
- after the hub or switching hub you reach a router which work is to route the packet to another network
- if hub: the 20 other computers receive the packet and all of them discard it
- if switching hub : none of the 20 comp receive the packet
(as sent to another network)
- the router transfers the packet to another hub/switch where is the "another" network then same as 1. ...

2. Sending UDP directed (not broadcast) : same as above

3. Sending UDP broadcast : same as above except that
- switching hubs will transfer the packet to all 20 other comps
(hub will do it as usual)
- the 20 other comps will accept the packet (while there may be no application to process it -> packet refused)

4. to answer your questions
- the network interface does not understand the IP protocol (osi layer 3) it will however drop directed traffic on the same network which is directed to other MAC addresses
- 255.255.255.255 is actually usually prohibited
- you can however use, .eg. 20.255.255.255 to send to the whole class A network 20 ... in theory. On the Internet, forget it ... your packet will have been dropped from the near nodes. On the LAN it should work (if your routers let it go).
- yes a broadcast is more network consuming as all computers (on the subnet where you broadcast) will receive the packet, however non concerned ones will drop it (typically if your application listening on one given port is not running on them)
- however broadcast packets are not duplicated. The network equipments (switches routers) simply let them go instead of discarding them. So "does it send just one message out and all the computers connected to that network just see that datagram on the network because since it has the special "broadcast" address?" answer is yes.

So depending on the number of clients, you may choose directed traffics (few clients) or broadcast (a lot). However if your packets are small and you don't flood the LAN every 1/1000 sec, go for broadcast. But it all depends on your config anyway ... if all clients are connected to chained Hubs all will receive the packets anyway and will have to drop them...

Have a look to
- osi layers
- IP and mac addresses