Sorry for coming in late in the thread, but If you control both the
source and destination of the traffic, you could consider some sort of
encapsulation within another protocol, perhaps ipsec, but again, that
does delay the data, essentially with the encapsulation and
decapsulation time, but *might* give you more control as to keeping it
in order. However if all of the UDP data is currently taking the same
path to get to the destination, just arriving out of order for some
reason, this likely will not help.
On 09/12/2011 04:47 PM, Persio Pucci wrote:
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/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
