lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [lwip-devel] Re: [task #7040] Work on tcp_enqueue


From: bill
Subject: RE: [lwip-devel] Re: [task #7040] Work on tcp_enqueue
Date: Thu, 29 Jan 2009 14:23:17 -0500

>To solve it at the application level, you must call tcp_write() with
>data lengths that are a multiple of the mss.

Thank you!  Exactly right.  If I add the second if to my tcp_sent callback
it works perfectly.  All packets are 1460 bytes with one trailing packet
less than 1460.

  if( tcp_sndbuf(pcb) >= dataLen )
    len = dataLen;
  else
    len = tcp_sndbuf(pcb);
  if( len > pcb->mss )
    len -= len % pcb->mss;

>
>Here is what happens in tcp_enqueue():
>
>if write-length >mss then
>  break into mss-sized segments
>end
>
>if last-unsent-segment + first-write-segment <= mss
>  concat onto last unsent segment
>else
>  start new segment
>end
>
>This means that every tcp_write() with more than mss bytes will always
>start a new segment.

Ok.  This makes sense.  Tcp_enqueue couldn't hang on to the last partial
piece unless tcp_write had a flag to signal a flush or "end of contiguous
data".  Someone like me using the example code above to call tcp_write in
the tcp_sent callback knows when the end of the data has been reached
because the sent callback has to determine that so implementing this flag in
the application is trivial.

Maybe the second if above should be included in the tcp_sent examples with a
comment // this test ensures full payloads will be transmitted.  Wouldn't
the netconn API benefit from this addition?

>For many small writes, this is OK: Small writes are concatenated as
>long as they fit in the last unsent segment.
>
>For large writes this is also OK: Each write creates a number of full
>segments + one partial. This leads to a small overhead, nothing to worry
>about.
>
>For just-over-mss sized writes this is really bad: Repeated writes of
>1461 bytes leads to alternating segments 1460 , 1, 1460, 1, ...
>
>A quick fix to tcp_enqueue() is relatively easy: When breaking the write
>data into segments, the first segment should be made small enough to fit
>at the end of the last unsent segment. The remaining segments should
>still be mss-sized.

I don't know the code that well to know where you mean - I'll look at it
since I'm on the trail and it's trivial to test the change.  If we have a
partial mss-worth of data at the end, if we leave it queued, will it get
sent if there is no following tcp_write?

Thank you!
Bill





reply via email to

[Prev in Thread] Current Thread [Next in Thread]