[En-Nut-Discussion] Timing and Receiving Data Problem for TCPServer

[Jose Vicente Sanchez Ortega]

John:

The document which you have refered speaks about reordering at session
layer. None of the out of order packets are passed to the above layers
(actually because presentation or application layer would be unable to
distinguish about an out of order packet and a correct one. This is
precisely the advantage of TCP.


As you can read on RFC 793 (TCP) reliability requirements:

"  Reliability:

    The TCP must recover from data that is damaged, lost, duplicated, or
    delivered out of order by the internet communication system.  This
    is achieved by assigning a sequence number to each octet
    transmitted, and requiring a positive acknowledgment (ACK) from the
    receiving TCP.  If the ACK is not received within a timeout
    interval, the data is retransmitted.  At the receiver, the sequence
    numbers are used to correctly order segments that may be received
    out of order and to eliminate duplicates.  Damage is handled by
    adding a checksum to each segment transmitted, checking it at the
    receiver, and discarding damaged segments."

And:

" 2.6.  Reliable Communication

  A stream of data sent on a TCP connection is delivered reliably and in
  order at the destination."


Believe me. TCP ensures that packets are delivered on the same order that
they went sent.


Jose Vicente.




-----Mensaje original-----
De: en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de] En nombre de John Day
Enviado el: miércoles, 31 de enero de 2007 18:54
Para: Ethernut User Chat (English)
Asunto: Re: [En-Nut-Discussion] Timing and Receiving Data Problem for
TCPServer

At 05:30 AM 1/31/2007, you wrote:
>Hi, Thiago:
>
>I just would like to make a little precision. TCP packets always arrive in
>the same order they were delivered.

In fact not so. Whilst the ideal and efficient 
way is to have TCP handle everything in order it 
is not a requirement. TCP has the sequencing 
mechanism built in to it precisely so it can 
handle out of sequence arrivals. This apper: 
http://www.imconf.net/imw-2002/imw2002-papers/197.pdf 
is an interesting one on just what can happen in 
a non-monodic TCP environment. Any network which 
suffers packet los is likely to experience these problems.

John


>  On the other hand, it's UDP which
>doesn't make any warranty about this issue (packets can be lose or arrive
in
>a different order).
>
>Best regards,
>
>
>Jose Vicente.
>
>
>-----Mensaje original-----
>De: en-nut-discussion-bounces at egnite.de
>[mailto:en-nut-discussion-bounces at egnite.de] En nombre de Thiago A. Corrêa
>Enviado el: martes, 30 de enero de 2007 18:57
>Para: Ethernut User Chat (English)
>Asunto: Re: [En-Nut-Discussion] Timing and Receiving Data Problem for
>TCPServer
>
>Hi,
>
>     I'm sorry if I am wrong, but it seams from the description like a
common
>misconception about TCP streams. TCP is not packet oriented, it's a stream.
>There is no guarantee that you will be able to read all the data you want
in
>a single read (or NutTcpReceive) call. So you must do subsequent calls.
5000
>bytes is larger than the ethernet MTU, so it will be split in at the very
>least 3 ethernet frames which can arrive in distict times and even out of
>order. Of course this applies to not only ethernut, but anything using TCP.
>     Instead of inserting a delay, which in many cases can be suficient but
>also may not in others, you should check for the amount of data you
>received, and if it isn't enought, keep reading until you get it, or you
get
>a -1, which means the connection was lost.
>
>     So, something similar to:
>
>int cnt = 0;
>int index = 0;
>while ( cnt < 5000 )
>{
>if ( cnt = NutTcpReceive( socket, buffer + i, 5000 - i ) < 0 )
>     break; // lost connection
>i += cnt;
>}
>
>instead of simply NutTcpReceive( socket, buffer, 5000 ).
>
>Regards,
>    Thiago A. Correa
>
>On 1/30/07, MUHAMMAD AZEEM AZAM <muhammadazeemazam786 at yahoo.com> wrote:
> >
> > Hi
> > I
> > have to receive data from microcontroller.
> > Microcontroller is my server.
> > I have a TCP client (Blocking) on PC.
> > I have a program that have several buttons.
> >
> >   when i press one button my client(button has both send and receive
> > functions)
> > a) sends data to microcontroller.
> > b) microcontroller compares it and then process the request.
> > c) if the process is send data back to client it sends me data.
> >
> >   Now the problem is that when i have to receive 5000 Bytes of data, i
> > Receive only 536 Bytes.
> > when i use "Sleep(5000)" before Receive function  then i get all the
data.
> > but this delay is too much for me.
> >
> >   From micrcontroller i am sending the whole (both these techniques)
> > a) array of 5000 Bytes
> > b) buffer using malloc of 5000 Bytes.
> >   does anybody has idea how can i solve this problem
> >
> >   Thanks in Advance for Help
> > Bye
> >
> >
> >
> > ---------------------------------
> > It's here! Your new message!
> > Get new email alerts with the free Yahoo! Toolbar.
> > _______________________________________________
> > http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> >
>_______________________________________________
>http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>
>_______________________________________________
>http://lists.egnite.de/mailman/listinfo/en-nut-discussion

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion