On Wed, Sep 13, 2006 at 10:31:43PM +0200, Andre Oppermann wrote: > Igor Sysoev wrote: > >Well, suppose protocol similar to SSH or SMTP: > > > >1) the client calls connect(), it sends SYN; > >2) the server receives SYN and sends SYN/ACK with cookie; > >3) the client receives SYN/ACK and sends ACK; > >4) the client returns successfully from connect() and calls read(); > >5) the ACK is lost; > >6) the server does not about this connection, so application can not > > accept() it, and it can not send() HELO message. > >7) the client gets ETIMEDOUT from read(). > > > >Where in this sequence client may retransmit its ACK ? > > Never. You're correct. There is no data that would cause a retransmit > if the application is waiting for a server prompt first. I shouldn't > write wrong explanations when I'm tired, hungry and in between two tasks. ;) > > This problem is the reason why we don't switch entirely to syncookies > and still keep syncache as is. > Perhaps it would be a good idea to remove net.inet.tcp.syncookies_only then? In any case, please don't forget to update the syncache(4) manpage to reflect your changes, and if you decide not to remove this sysctl, please add a warning of its potential to break a protocol.
Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer
pgpsBKFhWZqqs.pgp
Description: PGP signature
