This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: TCP/IP Stack packet regrouping
- To: "Trenton D. Adams" <tadams at extremeeng dot com>
- Subject: Re: [ECOS] TCP/IP Stack packet regrouping
- From: Grant Edwards <grante at visi dot com>
- Date: Mon, 16 Jul 2001 17:10:45 -0500
- Cc: 'Jonathan Larmour' <jlarmour at redhat dot com>,'eCos Discussion' <ecos-discuss at sourceware dot cygnus dot com>,'Gary Thomas' <gthomas at redhat dot com>
- References: <20010716162741.A11222@visi.com> <000801c10e40$84c95f50$090110ac@TRENT>
On Mon, Jul 16, 2001 at 03:44:40PM -0600, Trenton D. Adams wrote:
> > > Sending generally will send it all at once, and there's no need
> > > for a loop for the outgoing buffer?
> >
> > No, that is not generally true. For small blocks, it will
> > _usually_ be true. For large blocks of data, you will have
> > to check the return value from write() in a loop. The
> > values of "small" and "large" vary from platform to platform.
> >
>
> Ok, who's actually correct here? Who's the one that wrote the TCP/IP
> stack? Are they listening?
I didn't write it, but I'm reading it. :)
In the eCos/BSD stack, it looks to me that send() is only
"atomic" if the PR_ATOMIC flag is set in the protosw struct for
the protocol associated with a socket. That flag isn't set for
SOCK_STREAM. It is set for SOCK_DGRAM and SOCK_RAW. Of
course, I could be misreading the code. But that does jibe with
what I've always been told regarding checking the return value
from a write() on a TCP socket.
> I'm reading the Linux documentation on send (), and it says
> that a send () call will block if "the message does not fit
> into the send buffer of the socket". Which tells me it that it
> is sending the information all at once (from the programmer's
> perspective). It also says that if it's to big to pass through
> the underlying protocol, it will return with an error of
> EMSGSIZE. Is this correct or not?
Good question.
Linux's TCP stack is not derived from BSD sources, and it may
behave differently. We can either start reading the source
code or gen up a program that tries to write a huge block of
data....
> > Oops, yes you're right. I misremembered from the top of my head
> > evidently.
>
> Did you actually misremember, or am I now screwing with your head? LOL
>
> How do I find out what the maximum message size is?
Another good question. :)
--
Grant Edwards
grante@visi.com