TCP issue with large packet under RTEMS
João Rasta
freakforever at gmail.com
Wed Feb 9 17:10:53 UTC 2011
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> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20110209/24e5e8c6/attachment-0001.html>
More information about the users
mailing list