TCP listenall
Bruce M. Simpson
bms at FreeBSD.org
Fri Oct 26 20:55:18 PDT 2007
Matus Harvan wrote:
> Hi,
>
> I was wondering if I could get some feedback about the patch and
> whether others think it could be committed. A slightly update version
> of the patch is at the end of this email.
>
I have mixed feelings about this patch.
The idea of a TCP socket which magically loses its TCP semantics is
unattractive -- SOCK_RAW is traditionally where we've put things which
don't fit the rest of the BSD socket API -- however in this case I don't
see we have much choice, if what we desire is the ability for a client
to establish a connection to any ephemeral port with the mtund returning
from an accept() as usual.
We are bending the rules of the usual TCP semantics here, but that is OK
because if we directed tlistenall to be a raw IP socket, we'd need a way
to say to TCP, 'I'd like to create a socket which is already in SYN_RCVD
state with a SYN whose mbuf has now gone to lunch', assuming we wish to
create TCP streams business as usual.
The relay port idea I pointed out in my message about udp catchall would
be especially applicable here -- we may not always want catchalls for
the entire 16-bit tcp port space.
listenallr is static and is going to get trashed by concurrent threads,
unless there is a serialization with a lock, which I don't see.
How will inp_tlistenall appear in netstat output? Perhaps assigning a
LISTEN_ALL state would be helpful for an administrator to clearly see
that a listenall socket is active? Perhaps checking for TCP_LISTENALL
set on an unbound socket in tcp_usr_listen() when listen() is called is
the way to go instead of, or in addition to, using inp_tlistenall?
Again, good work, but needs more polish before it can go into mainline
(IMHO).
best,
BMS
More information about the freebsd-net
mailing list