Reason: data rate constraints inherent in TCP protocol. Congestion Control?
Reason: TCP to a large group would be one-by-one unicast, highly inefficient and too much load on the sender. Reason: TCP has more data-overhead in the form of non-payload data. * TCP header is typically 20 bytes vs 8 bytes for UDP
* Receiver need to acknowledge
If you receive seq #13 before 11, receiver will detect a gap between 10 and 13 and send retransmission request to the exchange. If 11, 12 come later, they will be discarded.
https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml shows a few hundred big companies including exchanges. For example, one exchange multicast address 22.214.171.124 falls within the range
126.96.36.199 to 188.8.131.52 Inter-continental Exchange, Inc.
It’s educational to compare with a unicast IP address. If you own such an unicast address, you can put it on a host and bind an http server to it. No one else can bind a server to that uncast address. Any client connecting to that IP will hit your host.
As owner of a multicast address, you alone can send datagrams to it and (presumably) you can restrict who can send or receive on this group address. Alan Shi pointed out the model is pub-sub MOM.
http://www.diffen.com/difference/TCP_vs_UDP is relevant.
FIFO — TCP; UDP — packet sequencing is uncontrolled
Virtual circuit — TCP; UDP — datagram network
Connectionless — UDP ; TCP — Connection-oriented
With http, ftp etc, you establish a Connection (like a session). No such connection for UDP communication.
Retransmission is part of — TCP; UDP — application layer (not network layer) on receiving end must request retransmission.
To provide guaranteed FIFO data delivery, over unreliable channel, TCP must be able to detect and request retransmission. UDP doesn’t bother. An application built on UDP need to create that functionality, as in the IDC (Interactive Data Corp) ticker plant. Here’s one simple scenario (easy to set up as a test):
- sender keeps multicasting
- shut down and restart receiver.
- receiver detects the sequence number gap, indicate message loss during the down time.
- Receiver request for retransmission.
Every multicast address is a group address. In other words, a multicast address identifies a group.
Sending a multicast datagram is much simpler than receiving…
 http://www.tldp.org/HOWTO/Multicast-HOWTO-2.html is a concise 4-page introduction. Describes joining/leaving.
 http://ntrg.cs.tcd.ie/undergrad/4ba2/multicast/antony/ has sample code to send/receive. Note there’s no server/client actually.
Here are my server and client, slightly modified from http://www.linuxhowtos.org/C_C++/socket.htm. It worked on my Ubuntu laptop, after a bit of tweaking (time well spent!). Fortunately, most of the includes are automatically available on Ubuntu.
It shows the Bind->Listen… sequence on the server side.
It shows hot to convert PID to string and append it to a cStr….
http://en.wikipedia.org/wiki/Multicast shows(suggests?) that broadcast is also time-efficient since sender only does one send. However, multicast is smarter and more bandwidth-efficient.
IPv6 disabled broadcast — to prevent disturbing all nodes in a network when only a few are interested in a particular service. Instead it relies on multicast addressing, a conceptually similar one-to-many routing methodology. However, multicasting limits the pool of receivers to those that join a specific multicast receiver group.
(Note virtually all MC apps use UDP.)
To understand MC efficency, we must compare with UC (unicast) and BC (broadcast). First we need some “codified” metrics —
- TT = imposing extra Traffic on network, which happens when the same packet is sent multiple times through the same network.
- RR = imposing extra processing workload on the Receiver host, because the packet is addressed TO “me” (pretending to be a receiver). If “my” address were not mentioned in the packet, then I would have ignored it without processing.
- SS = imposing extra processing workload by the Sender — a relatively low priority.
Now we can contrast MC, UC and BC. Suppose there are 3 receiver hosts to be notified, and 97 other hosts to leave alone, and suppose you send the message via —
- UC – TT not RR — sender dispatches 3 copies each addressed to a single host.
- BC – RR not TT — every host on the network sees a packet addressed to it though most would process then ignore it, wasting receiver’s time. When CEO sends an announcement email, everyone is in the recipient list.
- MC – not RR not TT. However, MC can still flood the network.
These are the 2 main usages of IP multicast. In both, Lost packets are considered lost forever. Resend would be “too late”.
I think some of the world’s most cutting-edge network services — live price feed, live event broadcast, VOD — rely on IP multicast.
Multicast is more intelligent data dissemination than broadcast, and faster than unicast. Intelligence is built into routers.
I believe JMS publish is unicast based, not broadcast based. The receivers don’t comprise an IP broadcast group. Therefore JMS broker must deliver to one receiver at a time.