Menu
I'm writing a server/client system in C, which uses BSD Sockets under a TCP connection. The server is multi-threaded, with each connection running in its own receptor. Each client does a good job talking with the server on a one-to-one basis, sadly I can't think of a way to implement a SendToAll() function, for instance, if client A does something that requires sending a packet to all of the clients. How would I do this?
I was considering implementing a queue in every receptor, and any broadcast gets sent to those queues; when the receptor sends out a new packet, it adds that message onto the packet as well, if that makes any sense.
But yeah, is there any way to broadcast via TCP, like you can via UDP?
233
Why does TCP not support multicast and broadcast? Well this is pretty simple … TCP is a connection oriented protocol. Multicast and broadcast do not really make sense for a connection oriented protocol as it would not be the same on every connection.
TCP doesn't support Broadcasting. UDP supports Broadcasting. TCP is used by HTTP, HTTPs, FTP, SMTP and Telnet. UDP is used by DNS, DHCP, TFTP, SNMP, RIP, and VoIP.
The TCP/IP protocol Stack is not compliant with the OSI model. In the TCP/IP stack this layer is actually called the internet layer. TCP requires the creation of a socket connection before data can flow. That is absolutely impossible with broadcast or multicast.
Multicasting is also a one-way connection, so it cannot be transported via TCP, which requires confirmation of connectivity. Multicasting, by its very nature, is only sent via UDP (so make sure those UDP ports are open). FIGURE 4.11. Multicasting uses a single stream for each host.
As everyone has said that is not possible with TCP, it is unicast only. However there are implementations of reliable multicast, which should give you multicast with the reliability of TCP. See wikipedia, especially Pragmatic General Multicast.
106
No, there isn't. For example, the concept of window size and how it's adjusted becomes completely meaningless if you're trying to talk to multiple parties.
It might be possible to create a new protocol that shared many of the attributes of TCP while allowing multicast. But I think it would be highly problematic. For example, the speed at which recipients received data would be constrained by the limitations of the slowest receiver. The sender has to manage buffer space so that even the slowest receiver can get re-transmissions if necessary.
No, I think protocols for doing multicast are always going to have to be very special purpose and focused on the exact problem at hand. Something generalized and TCP-like just isn't feasible.
There are ways to do reliable multicast bulk data transfer. The basic idea is to use erasure codes to continuously transmit information in a sort of loop. Then a recipient can just start receiving packets until they have enough to reconstruct the original file.
But these don't seem to fit your scenario all that well.
21
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
