[c-nsp] Troubleshoot UDP out-of-sequence
Walter Keen
walter.keen at RainierConnect.net
Mon Sep 12 19:56:06 EDT 2011
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<nick at foobar.org> 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 cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list