[En-Nut-Discussion] Timing and Receiving Data Problem for TCPServer

[Thiago A. Corrêa]

Hi there,

   I really hope that I'm not fueling this into the off-topic badlands
*smile*
   Dusan, you are right about the Nagle algorithm, it's purpose is to hold
the data a little bit in hope to fill in a full MTU, making the most
efficient use of the physical layer. But one has to keep in mind that TCP is
stream oriented, regardless of how one sends the data, it can be sliced and
reassembled along the way. This is particularly true when in the middle of
the way you pass thru a network with a different MTU, say ATM. One can never
assume to be able read a full application level "packet" in a single TCP
read call. Among other things, the most obvious is that TCP doesn't know
about your higher level protocol. I'm sure that in most cases, specially in
heterogeneous networks one is *lucky* enough to get it all in one read call.
Albeit, that should never be assume to always hold true :)

   The only guarantees you have is that either you get all the data in the
correct order (as opposed to UDP), or an error occurs. There is none about
boundaries. Using TCP_NODELAY will only trade throughput with some less
latency, but won't guarantee application layer "packets" in a single read,
unless they are all 1 byte long :)

   Well, anyway... I guess there isn't an implementation of the Nagle
algorithm in Nut, it is not lightweight AFAIK. But I can't say for sure.
Should be interesting to know though :D

Best Regards,
   Thiago A. Correa

On 2/5/07, Dusan Ferbas <dferbas at etech.cz> wrote:
>
> Hi,
>
> I disagree with this claim.
>
> Usually (Berkeley standard), you can set expedited and non expedited
> socket modes. Expedited means, that data, you sent from application
> layer, are immediately sent over a network. I.e. there is a packet
> that can be received e.g. by NutTcpReceive(...) call. I assume no
> streaming, as it is used e.g. in Nut/OS httpd example. The mechanism
> of buffering is called Nagle algorithm.
>
> I have an application of telnet server (Pacific Softworks TCP stack),
> where VT100 codes are used to format a screen - since 1999 :-),
> that's why it was ever implemented. And there is a need for immediate
> response. I achieve this with a call to set socket option API
> (IPPROTO_TCP layer, TCP_NODELAY option)
>
> Macro definition for TCP_NODELAY already exists in Nut/OS ...
>
> At 12:29 5.2.2007, you wrote:
> >From: "Clemens Kirchgatterer" <c.kirchgatterer at amatic.com>
> >...
> >maybe one thing that adds to the confusion is, like you correctly
> >pointed out, that TCP is a stream and not a packet oriented protocol to
> >begin with. so to clear this up: using tcp you can be sure, that you get
> >all your data, without corruption and in the right order. on the other
> >hand, you must check for message boundaries on the application level.
> >i.e. if you put first 3 bytes on the wire and then 5, you may get all 8
> >bytes in one read() on the receiver side, or 2 times 4 bytes or any
> >other combination that sums up to 8. :-)
> >
> >best regards ...
> >clemens
>
> Dusan
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>