Richard H. wrote:
> Tauno Voipio wrote:
> 
>> Well - that's mis-using the keepalive probe. I'm using
>> in in my own TCP/IP embedded stack (which does not
>> claim any RFC compliance, it's server only).
> 
> 
> Yes, it would be.  It should also be fairly foolproof, but it will also 
> trip-up diag tools looking for re-transmissions, and will likely 
> increment the re-transmissions counter on the far-end device.
> 
> Do you find that normal keepalives are effective against Delayed ACKs? 
> (i.e., as above, but with your sequence# one less than the last ACK# 
> received)

The segment for tickling an ACK *is* a keepalive probe
without the advance byte but with the retarded sequence.
It's only not used in the keepalive purpose (once
every two hours).

The probes with advance bytes are for window probing
and they are not used here.

> Have you found any implementations where this was an exception, or where 
> it needs a byte of garbage data in the payload?

All the common implementations I've tested are happy with
the keepalive probes (Windows, Linux, Solaris, OS X).

---

An embedded TCP implementation has also to be quite
anti-social to hanging connections: there is simply
not enough storage available to allow for the luxury
of connections doing nothing.

It would need storage up to the peer window size
(up to tens of kilobytes) to get rid of the delay
caused by the delayed ACK. In many embedded systems
this is more than is available, especially as it
is needed for each active connection separately.

-- 

Tauno Voipio
tauno voipio (at) iki fi

To combat the Nagle algorithm, I split my response payload packet into 2
TCP packet xmits...

the 1st typically contains 1 byte (a bytecount in my case). I set the TCP
window size to 0 in this packet.

the 2nd contains the remainder of the data with the wondow size returned
to nominal.

To combat the Nagle algorithm, I split my response payload packet into 2
TCP packet xmits...

the 1st typically contains 1 byte (a bytecount in my case). I set the TCP
window size to 0 in this packet.

the 2nd contains the remainder of the data with the wondow size returned
to nominal.

Tauno Voipio wrote:
> Well - that's mis-using the keepalive probe. I'm using
> in in my own TCP/IP embedded stack (which does not
> claim any RFC compliance, it's server only).

Yes, it would be.  It should also be fairly foolproof, but it will also 
trip-up diag tools looking for re-transmissions, and will likely 
increment the re-transmissions counter on the far-end device.

Do you find that normal keepalives are effective against Delayed ACKs? 
(i.e., as above, but with your sequence# one less than the last ACK# 
received)

Have you found any implementations where this was an exception, or where 
it needs a byte of garbage data in the payload?

Richard

Richard H. wrote:
> Tauno Voipio wrote:
> 
>>    There is a trick
>>    to tickle the Windows stack to respond sooner by sending
>>    an extra ACK (toward Windows) with a slightly old sequence
>>    number.
> 
> 
> Ah yes, nice trick; I forgot about that one.  That should be a pretty 
> easy hack, no?
> 
> I'm not finding the details in a quick dig, but I recall that you would 
> send an ACK with the proper ACK number (i.e., all bytes received 
> to-date), but *incrementing* your sequence number by some amount to 
> suggest there's missing data - this is supposed to trigger the receiver 
> to react with a retransmission ACK to say "no, I'm missing that data, 
> here's what I've got so far, please re-send".
> 
> Does this sync with your understanding?  Any pointers to a more detailed 
> discussion or implementation?
> 
> I'm at a loss for where I heard this trick; either here in c.a.e, or 
> perhaps in Bentham's TCP/IP Lean book.
> 
> Richard

Well - that's mis-using the keepalive probe. I'm using
in in my own TCP/IP embedded stack (which does not
claim any RFC compliance, it's server only).

-- 

Tauno Voipio
tauno voipio (at) iki fi

Tauno Voipio wrote:
>    There is a trick
>    to tickle the Windows stack to respond sooner by sending
>    an extra ACK (toward Windows) with a slightly old sequence
>    number.

Ah yes, nice trick; I forgot about that one.  That should be a pretty 
easy hack, no?

I'm not finding the details in a quick dig, but I recall that you would 
send an ACK with the proper ACK number (i.e., all bytes received 
to-date), but *incrementing* your sequence number by some amount to 
suggest there's missing data - this is supposed to trigger the receiver 
to react with a retransmission ACK to say "no, I'm missing that data, 
here's what I've got so far, please re-send".

Does this sync with your understanding?  Any pointers to a more detailed 
discussion or implementation?

I'm at a loss for where I heard this trick; either here in c.a.e, or 
perhaps in Bentham's TCP/IP Lean book.

Richard

Repzak wrote:
> 
> I will just put in my bad light on the Uip tcp/ip stack, the problem is the 
> speed caused by windows uses 200mS to reply 1 ack package and the Uip canot 
> send multiple packages, it gives a maximum og less than 10kbyte/s both 10 
> connections of 5 kbyte/s is not a problem....
> 
> 
> Kasper

1. Congratulations!

2. The phenomenon is according to the RFC, called delayed ACK.
    Its purpose is to see if there is anything to send toward
    the embedded device along with the ACK. There is a trick
    to tickle the Windows stack to respond sooner by sending
    an extra ACK (toward Windows) with a slightly old sequence
    number.

    This is a common problem in embedded stacks, as smoother
    flow would need more buffers: everything not yet ACKed
    must be kept in the sending TCP's socket buffers. The
    space needed is pretty quickly excessive in a small
    embedded device.

HTH

-- 

Tauno Voipio
tauno voipio (at) iki fi

Repzak wrote:
> I will just put in my bad light on the Uip tcp/ip stack, the problem is  the
> speed caused by windows uses 200mS to reply 1 ack package

This is a standard TCP behavior called Delayed ACK; Windows is doing the 
right thing.  It's done to prevent 1:1 ACK traffic for every packet 
received.

There isn't a way for the sender to manipulate / disable Delayed ACK on 
the receiver.  However, if the Windows app is your own (i.e., not a 
browser client), configure it to send back a simple 1-byte NOP response 
whenever data is received - this will embed an ACK and boost your 
performance.


> and the Uip canot 
> send multiple packages, it gives a maximum og less than 10kbyte/s both 10 
> connections of 5 kbyte/s is not a problem....

Yep, this is a limitation of the transmitting IP stack - only one TCP 
packet can be outstanding.  IIRC, lwIP (by the same folks) does not have 
this TCP limitation.

Cheers,
Richard

"Dejan" <(remove)ddurdeni@zg.t-com.hr> wrote in message 
news:d95td5$7uf$1@ss405.t-com.hr...
> There are many freely available TCP/IP stakcs  (OpenTCP, lwIP, ethernut 
> etc.) as well as many commercial ones (NetX, CMX, ...) . I would 
> appreciate if you can comment on the performance of  TCP connections (as 
> well as UDP, if available). The type of micro used as well as CPU clock is 
> also usefull. This is not a school project nor market survey. I simply 
> want to see what can I expect from such solutions. Commercial ones usually 
> give memory footprints, but performace is never shown...Thank you in 
> advance.

Hey

I will just put in my bad light on the Uip tcp/ip stack, the problem is the 
speed caused by windows uses 200mS to reply 1 ack package and the Uip canot 
send multiple packages, it gives a maximum og less than 10kbyte/s both 10 
connections of 5 kbyte/s is not a problem....


Kasper
(hope it is readable, a litle drunk after the last examination in my 
education.... 2nd higest grade :) 

There are many freely available TCP/IP stakcs  (OpenTCP, lwIP, ethernut 
etc.) as well as many commercial ones (NetX, CMX, ...) . I would appreciate 
if you can comment on the performance of  TCP connections (as well as UDP, 
if available). The type of micro used as well as CPU clock is also usefull. 
This is not a school project nor market survey. I simply want to see what 
can I expect from such solutions. Commercial ones usually give memory 
footprints, but performace is never shown...Thank you in advance.

- Dejan