Subject: Re: time of queued connections if not reaped...

From: der Mouse <[email-masked]>
Date: Sat, 3 Feb 2001 19:39:06 -0500 (EST)

>> [...] an interface that inserts the application between the receipt
>> of the SYN and the sending of the SYN|ACK.

I used something similar, way back when, albeit with DECnet rather than
TCP.  As I recall the interface, and mapping it into TCP terms, the way
it worked was that you set some socket option on the listening socket
(with setsockopt()) and then accept() returned a socket that was still
in SYN_RCVD, and you had to take explicit action to send the SYN-ACK
(which of course you had to do before you could do much more than
getpeername() on the new socket).

Of course, an application using this interface will be comparatively
easy to DoS with a synflood, but that's unavoidable.

> I don't know of any TCP implementation that withholds the SYN-ACK
> until the application accepts the connection.  I do know that if you
> experiment with such a strategy, you will find that BSD-based
> implementations of FTP will be unable to successfully establish a
> data connection.  It's been a long time since I stumbled into this,
> so the details are fuzzy, but basically you get into a deadlock where
> the client doesn't try to accept the data connection until it
> receives a message on the control connection, but the server doesn't
> send that message on the control connection until the data connection
> is established.

All this means is that the listening side (client for PORT style,
server for PASV style) mustn't turn on the relevant option on its data
connection socket.  Since most applications don't want this option, the
default should be off, which means that FTP code that's unaware of the
option will behave correctly.  If an FTP client or server is modified
to turn the option on, of course, it will have to also be modified to
avoid deadlocking as a result.  I don't consider this a problem.

If you try to change the system-wide default, well, you've introduced a
fundamental major change in the semantics of the interface, so it's no
surprise if unchanged code breaks.

					der Mouse

			       [email-masked]
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: [email-masked] (Jerry Toporek)
Date: Sat, 3 Feb 2001 17:38:56 -0800

> avoid deadlocking as a result.  I don't consider this a problem.

Sure...  As an option on the listener it should work fine, and isn't very
hard to implement.

jt