[ECOS] TCP/IP Stack packet regrouping

[ECOS] TCP/IP Stack packet regrouping

[Trenton D. Adams]

I'm curious as to what happens if I send 30K worth of data in one send?
Will it all send at one time?
What happens if I receive 30K of data, will it receive all 30K at one
time?
If not, in blocking mode it will most likely appear to happen all at one
time right?
In non blocking mode will I have to do a loop until all the data has
been sent/received while adjusting the buffer pointer?


p.s.
I know that the packets may be received in any order, and that they
won't all come in at the same time.  I don't actually want to know what
happens at this low of a level.  I just want to know from a programmer's
perspective.

Re: [ECOS] TCP/IP Stack packet regrouping

[Grant Edwards]

On Mon, Jul 16, 2001 at 01:51:55PM -0600, Trenton D. Adams wrote:

> I'm curious as to what happens if I send 30K worth of data in one send?
> Will it all send at one time?

Probably not.  If you're using Ethernet, only ~1500 bytes at a
time can be sent.

> What happens if I receive 30K of data, will it receive all 30K
> at one time?

Probably not.

> If not, in blocking mode it will most likely appear to happen all at one
> time right?

Probably not. If you're using Ethernet, it will come in 1500
bytes at a time.

> In non blocking mode will I have to do a loop until all the data has
> been sent/received while adjusting the buffer pointer?

Correct.  You must do that in blocking mode also.

> p.s.
> I know that the packets may be received in any order, and that they
> won't all come in at the same time.  I don't actually want to know what
> happens at this low of a level.  I just want to know from a programmer's
> perspective.

From a programmer's perspective, TCP is a reliable stream of
bytes.  If you get the bytes, you will get the bytes in the
right order with no corruption or duplication.

The size of the chunks you get from read() is undefined.  Some
programs assume that a write of <1500 bytes will result in a
corresponding read() of the same number of bytes.  Those
programs work on some platforms and networks and not on others.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] TCP/IP Stack packet regrouping

[Jonathan Larmour]

"Trenton D. Adams" wrote:
> 
> I'm curious as to what happens if I send 30K worth of data in one send?
> Will it all send at one time?

Not necessarily - it may depend on window size negotiation, fragmentation,
MTUs etc. It _may_ send all at one time, but I wouldn't rely on it.

At a high level it will all send, yes.

> What happens if I receive 30K of data, will it receive all 30K at one
> time?

If you are sure that a single 30K TCP packet has been received, then yes,
you should. But it's probably not portable to rely on it, and it's very
difficult to be sure you would have received a single 30K packet.

> If not, in blocking mode it will most likely appear to happen all at one
> time right?

Not necessarily. read() can return early if _some_ data is available.

> In non blocking mode will I have to do a loop until all the data has
> been sent/received while adjusting the buffer pointer?

Yes.
 
Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions    http://www.redhat-techworld.com/

RE: [ECOS] TCP/IP Stack packet regrouping

[Trenton D. Adams]

  > 
  > > If not, in blocking mode it will most likely appear to 
  > happen all at 
  > > one time right?
  > 
  > Not necessarily. read() can return early if _some_ data is 
  > available.

Are you saying that read () will return if ONLY some of the data is
there, but will complete successfully if it's all there?


So, to summarize what you said.

Sending generally will send it all at once, and there's no need for a
loop for the outgoing buffer?
Receiving I should always do the loop just in case?

RE: [ECOS] TCP/IP Stack packet regrouping

[Gary Thomas]

On 16-Jul-2001 Trenton D. Adams wrote:
>   > 
>   > > If not, in blocking mode it will most likely appear to 
>   > happen all at 
>   > > one time right?
>   > 
>   > Not necessarily. read() can return early if _some_ data is 
>   > available.
> 
> Are you saying that read () will return if ONLY some of the data is
> there, but will complete successfully if it's all there?
> 
> 
> So, to summarize what you said.
> 
> Sending generally will send it all at once, and there's no need for a
> loop for the outgoing buffer?
> Receiving I should always do the loop just in case?

Yes, these comments are accurate, but only for TCP connections.  Other
types of connections will have completely different behaviour/semantics.

RE: [ECOS] TCP/IP Stack packet regrouping

[Trenton D. Adams]

  > On 16-Jul-2001 Trenton D. Adams wrote:
  > >   > 
  > >   > > If not, in blocking mode it will most likely appear to 
  > >   > happen all at 
  > >   > > one time right?
  > >   > 
  > >   > Not necessarily. read() can return early if _some_ data is 
  > >   > available.
  > > 
  > > Are you saying that read () will return if ONLY some of 
  > the data is 
  > > there, but will complete successfully if it's all there?
  > > 
  > > 
  > > So, to summarize what you said.
  > > 
  > > Sending generally will send it all at once, and there's 
  > no need for a 
  > > loop for the outgoing buffer? Receiving I should always 
  > do the loop 
  > > just in case?
  > 
  > Yes, these comments are accurate, but only for TCP 
  > connections.  Other types of connections will have 
  > completely different behaviour/semantics.
  > 

Thanks for that, I'm going to be using TCP! :)

Re: [ECOS] TCP/IP Stack packet regrouping

[Jonathan Larmour]

"Trenton D. Adams" wrote:
> 
>   >
>   > > If not, in blocking mode it will most likely appear to
>   > happen all at
>   > > one time right?
>   >
>   > Not necessarily. read() can return early if _some_ data is
>   > available.
> 
> Are you saying that read () will return if ONLY some of the data is
> there, but will complete successfully if it's all there?

read() can return if some or all of the data is there. In both cases it
will return the number of bytes actually read.
 
> So, to summarize what you said.
> 
> Sending generally will send it all at once, and there's no need for a
> loop for the outgoing buffer?

Yes.

> Receiving I should always do the loop just in case?

Yes.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions    http://www.redhat-techworld.com/

Re: [ECOS] TCP/IP Stack packet regrouping

[Grant Edwards]

On Mon, Jul 16, 2001 at 02:33:31PM -0600, Trenton D. Adams wrote:
>   > 
>   > > If not, in blocking mode it will most likely appear to happen
>   > > all at one time right?
>   > 
>   > Not necessarily. read() can return early if _some_ data is
>   > available.
> 
> Are you saying that read () will return if ONLY some of the data is
> there, but will complete successfully if it's all there?

When you call read in blocking mode, it will return "n" when
   1) there is some data available: n>0
   2) there is an error: n<0
   3) the connection has been closed: n==0

> So, to summarize what you said.
> 
> 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.

> Receiving I should always do the loop just in case?

Yes -- for both read and write.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] TCP/IP Stack packet regrouping

[Jonathan Larmour]

Grant Edwards 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.

Oops, yes you're right. I misremembered from the top of my head evidently.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions    http://www.redhat-techworld.com/

RE: [ECOS] TCP/IP Stack packet regrouping

[Trenton D. Adams]

  > On Mon, Jul 16, 2001 at 02:33:31PM -0600, Trenton D. Adams wrote:
  > >   > 
  > >   > > If not, in blocking mode it will most likely appear 
  > to happen
  > >   > > all at one time right?
  > >   > 
  > >   > Not necessarily. read() can return early if _some_ data is
  > >   > available.
  > > 
  > > Are you saying that read () will return if ONLY some of 
  > the data is 
  > > there, but will complete successfully if it's all there?
  > 
  > When you call read in blocking mode, it will return "n" when
  >    1) there is some data available: n>0
  >    2) there is an error: n<0
  >    3) the connection has been closed: n==0
  > 
  > > So, to summarize what you said.
  > > 
  > > 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?  

  > > Receiving I should always do the loop just in case?
  > 
  > Yes -- for both read and write.
  > 


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?


    >> 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.
  > Oops, yes you're right. I misremembered from the top of my head
evidently.
  >
  >Jifl

Did you actually misremember, or am I now screwing with your head? LOL


How do I find out what the maximum message size is?

Re: [ECOS] TCP/IP Stack packet regrouping

[Grant Edwards]

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

Re: [ECOS] TCP/IP Stack packet regrouping

[Grant Edwards]

On Mon, Jul 16, 2001 at 03:44:40PM -0600, Trenton D. Adams wrote:

> 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?

It does appear that a write on a TCP socket under Linux will
block until all of the data is sent -- I tried a single write()
with block sizes up to 16MB, and it blocked until all data was
sent. However, if a signal comes along, the write() gets
interrupted and it returns a partial value.

-- 
Grant Edwards
grante@visi.com

RE: [ECOS] TCP/IP Stack packet regrouping

[Trenton D. Adams]

  > On Mon, Jul 16, 2001 at 03:44:40PM -0600, Trenton D. Adams wrote:
  > 
  > > 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?
  > 
  > It does appear that a write on a TCP socket under Linux will
  > block until all of the data is sent -- I tried a single write()
  > with block sizes up to 16MB, and it blocked until all data was
  > sent. However, if a signal comes along, the write() gets
  > interrupted and it returns a partial value.
  > 

You mean an OS signal like SIGHUP or something?

Re: [ECOS] TCP/IP Stack packet regrouping

[Grant Edwards]

On Mon, Jul 16, 2001 at 04:35:20PM -0600, Trenton D. Adams wrote:
>   > On Mon, Jul 16, 2001 at 03:44:40PM -0600, Trenton D. Adams wrote:
>   > 
>   > > 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?
>   > 
>   > It does appear that a write on a TCP socket under Linux will
>   > block until all of the data is sent -- I tried a single write()
>   > with block sizes up to 16MB, and it blocked until all data was
>   > sent. However, if a signal comes along, the write() gets
>   > interrupted and it returns a partial value.
>   > 
> 
> You mean an OS signal like SIGHUP or something?

Yes.  I wrote a test program that did an alarm(1) [with a
handler that did a printf()/return], and then did a
write(s,buf,16*1024*1024).  The write returned after about 800K
bytes had been written.

-- 
Grant Edwards
grante@visi.com

RE: [ECOS] TCP/IP Stack packet regrouping

[Trenton D. Adams]

  > 
  > >   > > 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 THINK this is the opposite of the Linux version.  The Linux TCP
version is APPARENTLY atomic.
I used to know what this means in computer terms, but I can't remember.
Can you explain the ATOMIC thing to me?

  > > 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....
  > 

Although it may not be derived from the sources, the docs say it
"conforms to" 4.4BSD.  Whether this just means the parameter list, or in
fact the way it works as well, I don't know.

  > >   > 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.  :)
  > 

I just looked, and it bases it on if_mtu if it's a broadcast packet.  I
don't understand the code below though because I don't know what ip_off
or IP_DF are.  I might look them up at a later time though.  I'm
primarily doing documentation/design for networking right now so I don't
have time for this at the moment.

	if (ip->ip_off & IP_DF) {	// Line 847 of ip_output.c
		error = EMSGSIZE;
		ipstat.ips_cantfrag++;
		goto bad;
	}
	len = (ifp->if_mtu - hlen) &~ 7;
	if (len < 8) {
		error = EMSGSIZE;
		goto bad;
	}

Re: [ECOS] TCP/IP Stack packet regrouping

[Grant Edwards]

On Mon, Jul 16, 2001 at 04:35:20PM -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 THINK this is the opposite of the Linux version.  The Linux
> TCP version is APPARENTLY atomic. I used to know what this
> means in computer terms, but I can't remember. Can you explain
> the ATOMIC thing to me?

I'm still not 100% sure that the eCos/BSD stack won't try to
loop until all of the data is sent.  I have a really tough time
reading C code that's indented that way.  I'm going to have to
re-indent the eCos sources and study it some more.

-- 
Grant Edwards
grante@visi.com

[ECOS] Simulation under CCS (Code Composer Studio)

[SEBASTIEN ANDRE]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

Hi all,

So i create a simple programm compiled for ARM without eCos KERNEL !! a
base ARM code !!
I can simulate it under GDB correctly but i can't  simulate it with Code
Composer Studio TMS470Rxx !!
With time i find a way !! i must strip all information debug and after i
can load under CCS !!
But if i let some debug info the simulator hang !! (i try -ggdb,
-gdwarf-2, etc ..)

So the next step i had make it to try to load an eCos Program !! under
GDB it load correctly
and the entry point is the vector functions (the simaltion is not
correct because thay are no hardware simulation but the code is
correctly loaded)
But with CCS i can't load it to !! if i strip information debug i have
an internal error #5 !! i can't load it !!

So what is wrong !!? CCS have a bug ? or i make a something wrong in the
build process !!! ?

I know this question is a CCS questions but i say it in this forums for
the case of somebody know this tools !!

best regards,
Sébastien.

Re: [ECOS] TCP/IP Stack packet regrouping

[Grant Edwards]

On Mon, Jul 16, 2001 at 03:44:40PM -0600, Trenton D. Adams wrote:

>> 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?

After reindenting uipc_socket.c and looking at it some more, it
looks like the outer do/while loop in sosend() is waiting until
all data has been sent (for a blocking, stream socket).

The inner do/while loop fills up the so_snd buffer until it's
full. After the inner loop has filled up the send buffer, the
outer loop repeats the inner loop.  There ought to be someplace
in there where the task blocks waiting for more room in the
send buffer, but I cant find it.

But, the comment at the top of sosend() reads:

 * Returns nonzero on error, timeout or signal; callers
 * must check for short counts if EINTR/ERESTART are returned.
 * Data and control buffers are freed on return.

If you can guarantee that no signals are going to happen, then
you souldn't have to check for short counts. I don't like to
depend on that assumption.

-- 
Grant Edwards
grante@visi.com

RE: [ECOS] TCP/IP Stack packet regrouping

[Trenton D. Adams]

  > 
  > On Mon, Jul 16, 2001 at 03:44:40PM -0600, Trenton D. Adams wrote:
  > 
  > >> 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?
  > 
  > After reindenting uipc_socket.c and looking at it some more, it
  > looks like the outer do/while loop in sosend() is waiting until
  > all data has been sent (for a blocking, stream socket).
  > 
  > The inner do/while loop fills up the so_snd buffer until it's
  > full. After the inner loop has filled up the send buffer, the
  > outer loop repeats the inner loop.  There ought to be someplace
  > in there where the task blocks waiting for more room in the
  > send buffer, but I cant find it.
  > 
  > But, the comment at the top of sosend() reads:
  > 
  >  * Returns nonzero on error, timeout or signal; callers
  >  * must check for short counts if EINTR/ERESTART are returned.
  >  * Data and control buffers are freed on return.
  > 
  > If you can guarantee that no signals are going to happen, then
  > you souldn't have to check for short counts. I don't like to
  > depend on that assumption.
  > 

I have now in fact tested eCos with a 40K string buffer.  I used strcat
() fill it with the same string + carriage returns over and over again.
I then used send () which in fact did send the entire text buffer.  So,
you are correct.

Now, about the signals thing!  Can eCos applications receive signals
like Linux does?  If not, then I don't care because my code has no need
to be portable to anything other than eCos.

Re: [ECOS] TCP/IP Stack packet regrouping

[Jonathan Larmour]

"Trenton D. Adams" wrote:
> 
> Now, about the signals thing!  Can eCos applications receive signals
> like Linux does?  If not, then I don't care because my code has no need
> to be portable to anything other than eCos.

Only if you want it to in general, and certainly not if POSIX compatibility
isn't included.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions    http://www.redhat-techworld.com/