This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: TCP/IP Stack packet regrouping


  > 
  > >   > > 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;
	}


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]