I got an assignment to implement unicast, multicast and broadcast in UDP or TCP in java, so I searched for it and I only got UDP implementation of multicast.
My question is following:
Is there multicast possible in TCP?
Network Engineering Stack Exchange is a question and answer site for network engineers. It only takes a minute to sign up.Sign up to join this community
In a word: NO
Multicast is a one-to-many system. TCP requires a one-to-one handshake to synchronize counters (sequence numbers) to ensure reliable transport. This cannot be done with many receivers as the sender has no way to know how many receivers there are and thus how many ACKs to expect, or what to do if one of the receivers disappears mid-transfer, etc.
Think of multicast as a speaker in a lecture hall. They don't know how many people are supposed to be there, nor care if some are late or leave. Nor do they know (or care) if everyone in the hall is hearing everything they say.
No. Even though TCP is composed of two separate sender/receiver relationships, the communication needs to be one-to-one and bidirectional.
But there are protocols which implement reliable transport over multicast, but they often use an inverse tree (publisher becomes consumer, and vice-versa) for negative acknowledgements. They are very different from TCP.
If "Multicast in TCP" means "TCP over Multicast IP", the answer is NO and I can undersign the excelent answer by Ricky Beam, 5 years ago.
If "Multicast in TCP" means a multicast service or application using TCP, it is possible. It would allow a single sender (caster) to send a data stream to multiple receivers using multiple TCP connections over unicast IP. This can be done at application level, in a new transport layer or even at TCP level by an element that can be called an "Multicaster TCP proxy". Neither of these solutions would require to change the TCP/IP stack implementation.
well unlike all of the other answer you have already received (and probably will receive) :
TCP is a stream-oriented protocol hence logical connections between request & response have to be established - in the case of multicast at least one important information is missing : the recipient address. Without that, quite a few algorithms (if not all) will stop working.
The solution seems to be horribly complex - one would need to incercept all (!) of the packets at the network layer on all sides (weird people call it "internet layer") hence create an entirely new protocol which actually just maps against a real one. Plus : your multicast traffic will not be routed beyond your local network border, literally all ISPs will refuse these packets.
Also : the multicast sender will have to deal with n answers to each of these transmissions - which will reduce the bandwidth gain significantly, in fact it will most definitely also increase processing time and probably overstress most NIC processing chips.
That might be a very cool experiment, though - you will need advanced programming skills and a LOT of knowledge about computer networks, operating systems and network standards :)