Re: [lwip-users] packet order with tcp_recv

[Grimes, Bob]

Well explained, Z...

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Radouch, Zdenek
Sent: Wednesday, September 10, 2014 11:26 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] packet order with tcp_recv

Please be careful distinguishing between packets/datagrams and the TCP data 
stream.

TCP provides a reliable byte-stream service. That is it establishes a logical 
connection between two endpoints, and gives you interfaces to read or write 
data to and from these endpoints. 
What is guaranteed is that the data written to one side can be read on the 
other side, the order of bytes being the same.

Note well that in TCP there is no concept of packets - you can write X and then 
Y bytes on one side and then read M and N bytes on the other side where X!=M 
and Y!=N. TCP guarantees that X+Y == M+N and that the order of all bytes 
written is the same as those read.

So the "in-order delivery" in TCP refers to the bytes NOT packets.

When referring to TCP packets, we are referring to the actual packets or 
datagrams that travel on the network. First of all we do not, in general, know 
the sizes of these packets as they do not have to reflect the sizes of the 
"writes" or "sends" (X,Y) on the transmit side. Secondly, these are IP packets, 
and as such they can get lost, duplicated, etc., and thus may need to be 
retransmitted, but could be lost again etc..
The TCP engine handles all of this for us, delivering the data stream through a 
high-level interface.

If you are using a "packet" interface" you are effectively looking "under the 
hood" and thus must be quite aware if the packets on this interface are ordered 
or not, hence the original question posted here.

So, whether or not tcp_recv callback will deliver the packets in the correct 
order has nothing to do with the fact that "TCP is connection-oriented and 
offers its Clients in-order delivery", it is a design decision reflecting 
desired semantics of this interface.

Hope this helps clarifying the issue.

Cheers,
-Z


> -----Original Message-----
> From: address@hidden [mailto:lwip-
> address@hidden On Behalf Of Noam
> weissman
> Sent: Wednesday, September 10, 2014 3:06 AM
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] packet order with tcp_recv
> 
> Hi,
> 
> Check this:
>    http://stackoverflow.com/questions/1691179/is-tcp-guaranteed-to-
> arrive-in-order
> 
> " TCP is connection-oriented and offers its Clients in-order delivery."
> 
> Even if data is lost or resent tcp_recv will and should be called in 
> an ordered manner.
> 
> This is what I know. If someone knows otherwise please explain.
> 
> BR,
> Noam.
> 
> 
> 
> -----Original Message-----
> From: address@hidden [mailto:lwip-users-
> address@hidden On Behalf Of Richner Simon
> Sent: Wednesday, September 10, 2014 9:44 AM
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] packet order with tcp_recv
> 
> I think I found the answer in the lwip options:
> 
> /**
>  * TCP_QUEUE_OOSEQ==1: TCP will queue segments that arrive out of 
> order.
>  * Define to 0 if your device is low on memory.
>  */
> 
> I didn't analyze the code, but to my understanding this means: If this 
> flag is set (default), then lwip will queue out of order segments and 
> wait for the missing segment, before calling tcp_recv. In this case 
> the application doesn't need to worry about out of order packets.
> 
> Please let me know  if I'm mistaken.
> 
> Cheers, Simon
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: address@hidden [mailto:lwip-
> address@hidden Im Auftrag von Radouch,
> Zdenek
> Gesendet: Dienstag, 9. September 2014 19:20
> An: Mailing list for lwIP users
> Betreff: Re: [lwip-users] packet order with tcp_recv
> 
> > Packets will be received in the order they were sent.
> 
> No, TCP packets are IP datagrams that can be lost, duplicated, or that 
> can arrive out of order. That is, they won't necessarily arrive in the 
> order they were sent. The TCP input module (tcp_in.c) does the 
> necessary ordering (it either passes the packet to the user or queues 
> it to be passed in later) and Simon's question is whether the tcp_recv 
> callback is delivering packets in order they were received or in a 
> sorted order (the reconstructed data stream).
> 
> Unfortunately I am not familiar with that callback so I don't know the 
> answer :-(.
> 
> Cheers,
> -Z
> 
> 
> > -----Original Message-----
> > From: address@hidden 
> > [mailto:lwip-
> > address@hidden On Behalf Of Noam
> > weissman
> > Sent: Tuesday, September 09, 2014 11:49 AM
> > To: Mailing list for lwIP users
> > Subject: Re: [lwip-users] packet order with tcp_recv
> >
> > Hi,
> >
> > In TCP there should not be such an issue. Packets will be received 
> > in the order they were sent.
> >
> > TCP is a stream.
> >
> > BR,
> > Noam.
> >
> > -----Original Message-----
> > From: address@hidden
> > [mailto:address@hidden On Behalf Of 
> > Richner Simon
> > Sent: Tuesday, September 09, 2014 3:30 PM
> > To: Mailing list for lwIP users
> > Subject: [lwip-users] packet order with tcp_recv
> >
> > Hi all,
> >
> > I have a basic question about tcp_recv:
> >
> > Let's say I have some MBs of data I send to the lwip stack. If (for 
> > whatever reason) tcp packets arrive out of order, will the stack 
> > sort this out for me and call the tcp_recv callback with packets 
> > sorted in correct order? Or do I have to check the sequence number 
> > myself to make sure I put data back together in correct order?
> >
> > Thanks for your help
> > Simon
> >
> > _______________________________________________
> > lwip-users mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/lwip-users
> >
> >
> >
> >
> **********************************************************************
> > *
> > *
> > ************
> > This footnote confirms that this email message has been scanned by 
> > PineApp Mail-SeCure for the presence of malicious code, vandals & 
> > computer viruses.
> >
> **********************************************************************
> > *
> > *
> > ************
> >
> >
> >
> >
> >
> >
> >
> **********************************************************************
> > *
> > *************
> > This footnote confirms that this email message has been scanned by 
> > PineApp Mail-SeCure for the presence of malicious code, vandals & 
> > computer viruses.
> >
> **********************************************************************
> > *
> > *************
> >
> >
> >
> >
> > _______________________________________________
> > lwip-users mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> 
> 
> **********************************************************************
> *
> *************
> This footnote confirms that this email message has been scanned by 
> PineApp Mail-SeCure for the presence of malicious code, vandals & 
> computer viruses.
> **********************************************************************
> *
> *************
> 
> 
> 
> 
> 
> 
> **********************************************************************
> *
> *************
> This footnote confirms that this email message has been scanned by 
> PineApp Mail-SeCure for the presence of malicious code, vandals & 
> computer viruses.
> **********************************************************************
> *
> *************
> 
> 
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users