I'd like to thank you all for the input, although it really did not help much on getting those ducks in a row... :)
This multicast stream is for market data, flowing from Brazil to the US, and although UDP was really not designed to ensure ordered, error-free packets, it looks like that the people who designed the market data protocols either missed it or did not consider the traffic going overseas, for one. The bad part is that I believe my customers (and the boss) won't take "that's how UDP works" for an answer. Although there's TCP Replay for the multicast streams, it is somewhat "delayed" from the realtime data and that puts them behind other competitors. On Mon, Sep 12, 2011 at 6:45 PM, Nick Hilliard <[email protected]> wrote: > On 12/09/2011 21:08, Lamar Owen wrote: > > Quoting RFC 768 (User Datagram Protocol): > > "This protocol provides a procedure for application programs to > > send messages to other programs with a minimum of protocol mechanism. > > The protocol is transaction oriented, and delivery and duplicate > > protection are not guaranteed. Applications requiring ordered reliable > > delivery of streams of data should use the Transmission Control Protocol > > (TCP) [2]." > > I would be interested to hear your opinion on how tcp over multicast would > work. > > But I agree with your general point that it's a bit much to expect an > application to work where it depends on intercontinental multicast to work > flawlessly and where the upper levels of the application don't even > tolerate out of order packets. "Be liberal in what you expect. Be > conservative in what you send". > > Nick > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
