46

For Internet Protocol (IP) I can use multicast:

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?

Alex
  • 12,578
  • 15
  • 99
  • 195

3 Answers3

99

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 acknowledgment 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.

BinaryButterfly
  • 18,137
  • 13
  • 50
  • 91
Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • Thank you! And about the rest of what I wrote on the issue about UDP am I right? – Alex Jan 21 '14 at 19:58
  • +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? – hagrawal7777 Oct 29 '16 at 21:16
  • @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. – Steffen Ullrich Oct 30 '16 at 05:05
  • @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. – peterh Jan 12 '18 at 09:03
  • how do you comment on this "Broadcasting and multicasting millions of clients using TCP" https://sudeepdasgupta.medium.com/broadcasting-and-multicasting-millions-of-clients-using-tcp-5794d784829a – LIU YUE Mar 02 '23 at 03:10
  • @LIUYUE: Nothing to comment here. It does not implement "real" broadcasting, it just implements a subscribe and publish scenario with many subscribers and on publisher. – Steffen Ullrich Mar 02 '23 at 07:38
  • oh ok, now I also figure it out, thanks for your confirmation – LIU YUE Mar 03 '23 at 02:15
10

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

user8524012
  • 101
  • 1
  • 2
  • 1
    "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. – Gilles Gouaillardet Aug 27 '17 at 17:02
-1

From my point of view when TCP protocol is accessed it should always be for unicasting,i.e. for single host and single server specified.As for example if we want to send a folder by mailing to a specific person a point to point connection will be established,but if there are many in cc or bcc,UDP will be there hence multicasting.

So my inference is TCP cannot be used for multicasting.

Suindu De
  • 1