TCP issue with large packet under RTEMS

[Yann Sionneau]

Hi Joao,

The fact that recv() can return before receiving everything you expect, 
and is non-blocking, is the standard way of functionning for recv().

This is the POSIX way, if you do man recv on a Linux system for example 
you will see that this behaviour is documented.

This is the correct behaviour of recv(), you have to run it inside a 
loop if you want to be sure to receive all the data you need.

On Linux there is a flag MSG_WAITALL that you can pass to recv() to make 
it wait untill it receives the amount of data you tell him to get. I 
don't know if it is implemented in RTEMS TCP/IP protocol stack.

Regards,

Yann Sionneau

Le 09/02/11 17:10, João Rasta a écrit :
> Hi Joel, Eric,
>
> I followed Eric's suggestion and it worked. I thought that read() should
> be automatically blocking untill all numelements passed to the read()
> function were read. I wonder why read() exits without this condition to
> fulfill..
>
> Joel, how can i increase the TCP/IP stack size in order to get more
> performance out of the read routine? I mean, using only one system call
> to get the whole data would be perfect. Previously the application did
> not lock, it simply returned the read with less bytes than the buffer
> size and continued executing.
>
>
> Thanks a lot.
>
> Best,
> JM
>
> On Wed, Feb 9, 2011 at 4:55 PM, Eric Norum <wenorum at lbl.gov
> <mailto:wenorum at lbl.gov>> wrote:
>
>     TCP (SOCK_STREAM) receivers always need to expect to have to
>     complete their reads in multiple operations -- you need to put your
>     read call in a loop:
>
>             char *buf;
>             ssize_t nleft, nread;
>             .
>             .
>             .
>             buf = .....
>             nleft = .....
>             while (nleft) {
>                     nread = read(sd, buf, nleft);
>                     if (nread < 0)
>                             error......
>                     if (nread == 0)
>                             end-of-file......
>                     buf += nread;
>                     nleft -= nread;
>             }
>
>     On Feb 9, 2011, at 8:36 AM, João Rasta wrote:
>
>      > Hi,
>      >
>      > I'm using RTEMS 4.10 and GRETH MAC in order to exchange data with
>     a client PC via TCP. I have a LEON-3 based processor architecture. I
>     can successfully attach the GRETH ethernet driver using the RTEMS
>     driver manager and exchange small ammounts of data. However, when i
>     need to transfer an image array (436160Bytes) from the PC to the
>     RTEMS system, the read() call only returns 17508Bytes read instead
>     of 436160Bytes .
>      >
>      > The send() directive in the PC side returns the correct number of
>     bytes sent so the problem must be on the RTEMS side. The read buffer
>     has the correct size.
>      >
>      > 1) Is there any programmable limitation related to the number of
>     bytes to receive? Since i'm using a TCP socket, there is no apparent
>     reason for byte loss i guess..
>      >
>      > 2) In what circumstances should read() from a TCP socket return
>     less bytes than the ones sent?
>      >
>      >
>      > Best,
>      > JM
>      >
>
>     --
>     Eric Norum
>     wenorum at lbl.gov <mailto:wenorum at lbl.gov>