Igor Sysoev wrote:
On Thu, 14 Sep 2006, Ruslan Ermilov wrote:
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.
I think that setting syncookies only not globally, but on per port basis,
say, for HTTP would be helpfull. Setting it for other protocols, e.g, SSH,
rsync, SMTP, IMAP, POP3 may break them.
Syncookies are optional anyway and syncache is still there. I'm not
going to over-engineer this whole thing. The primary purpose of syn-
cookies is to be able to handle a large number of (potentially bogus)
connection attempts. With syncookies you are able to serve more
legitimate connections out of the bogus ones than with syncache only.
--
Andre
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
