Can I use broadcast or multicast for TCP?

Question

For Internet Protocol (IP) I can use multicast:

• in IPv4: Internet Group Management Protocol (IGMP)
• in IPv6: Multicast Listener Discovery

Also, in example, for UDP I can use:

• broadcast - to send packet to range of addresses
• multicast - to send packet to list of specified addresses

But can I use something of these for TCP?

Solution 1

No, you can't. TCP is a protocol for communication between exactly two endpoints. Compared to UDP it features reliable transport, that means, that packets get not only send, but it is expected that the peer acknowledges the receipt of the data and that data will be retransmitted if the acknowledgement is missing. And because Broadcast and Multicast only send but never receive data, the reliability of TCP cannot be implemented on top of these protocols.

Solution 2

I normally don't post here, but I just needed to add a little clarification to the reasoning here. Steffen's answer is correct. No, you cant! perfect. let me answer the rest to say UDP is the right Protocol for sending Multicast and broadcast messages. I I yell out Steffen name in a crowded room, do i want everyone to respond? No way! If TCP was used, Everyone will confirm my packet!

So item two to discuss is reliability.This muddies the answer.UDP is awesome. When people say UDP is unreliable, they don't mean its bad. all they mean is the packet for UDP multicast does not need to hear a response, to confirm delivery. UDP is also great for voice communication, as When I talk, those packets are getting across faster, because the listener should not be saying yes, I got that packet, for every word I say.

Finally this leads us to UDP being reliable. After I clear this up, go back and read the paragraph above this one again. UDP is not Reliable. This is a major difference between TCP and UDP. So here is the Deal, there is UDP and R-UDP. R-UDP is a Different RFC (see link at bottom) then UDP. That RFC is IETF apparently. There may be others. They point about the original answer is was right, but introduced information about UDP (RFC 2460) that was wrong. For Academic reasons, as well as just common semse

Read about R-UDP here RUDP does not appear to have a proper RDF. some RFC are used in its conceptualization, but it looks to be used by microsoft, who has sent IETF, some document to start an RFC process. that link is below:

http://www.ietf.org/proceedings/44/I-D/draft-ietf-sigtran-reliable-udp-00.txt

I addition, MS did publish some information below, along with a RUDP wiki:

http://www.viavisolutions.com/en-us/literature/microsoft-tv-test-application-notes-en.pdf

well Apparently my reputation has to be 10 to post more then two links--so wikipedia the other link look for R-UDP or RUDP

Comments

[Alex]

Thank you! And about the rest of what I wrote on the issue about UDP am I right?

[hagrawal]

+1 because answer is definitely correct but I am sure of reasoning, multicast/broadcast doesn't get any reply/response back, and here reply/response is the message, they only send some message don't expect any message back, it has nothing to do with IP packets delivery?

[Steffen Ullrich]

@hagrawal: before any packets are delivered on a TCP connection you have the three-way handshake between the client and the server. Also TCP is designed for reliability so you have ACK's to acknowledge that the packet was received. So there are actually lots of messages back, both for connection setup and packet sending. While you could design a protocol which does not need any messages back it would not be TCP then.

[Gilles Gouaillardet]

"No you cannot" was the right answer. The rest is very arguable imho. If you yell Steffen in a crowded room ... do you want everybody to respond (probably not) do you want to be sure everybody heard it ? maybe not. Asked differently do you want to be sure Steffen heard you ? (very likely yes) broadcast/multicast cannot use TCP, but they can use UDP, and by default, this is not reliable. Bottom line, it all depends on your application. Sometimes this is good enough, and some other times, reliable broadcast/multicast is mandatory.

[peterh]

@hagrawal It would be possible to extend TCP to allow multi-point communication. Essentially, the handshake and the ack-s should be extended to be capable to handle multiple points. But it wouldn't be TCP any more, it would be a protocol similar to tcp (...and to torrent). Nobody did it until now, but it would be possible.