Re: TCP listenall

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
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: TCP listenall
    ... of the patch is at the end of this email. ... The idea of a TCP socket which magically loses its TCP semantics is ... immediately know which is the listenall socket without having to ...
    (freebsd-net)
  • Re: [PATCH] OpenBSD Networking-related randomization port
    ... licensing issues need to be resolved before a patch can go in. ... - Changes the TCP ISN generation algorithm. ... the only change is whether the IDs used are simply incrementing ...
    (Linux-Kernel)
  • Re: Socket stuck with puts over ADSL line
    ... gets stuck with the puts command within the filevent writeable ... Is the socket configured as -blocking 1? ... local buffer would fill rapidly, ... buffered portion across the WAN as its own TCP packet, ...
    (comp.lang.tcl)
  • [RFC] implement "blackhole" option for TCP and UDP
    ... The patch below is an RFC only. ... interface option for IPv4 TCP and UDP protocols, ... ICMP port unreach (for UDP) or RST (for TCP) packet is generated. ...
    (Linux-Kernel)
  • Re: network programming: how does s.accept() work?
    ... The articles and books I've read all claim that the server ... port 5053 is a 'listening' port only. ... the server creates a new socket for communication between the client ... on the network, and in the RFCs which define the TCP protocol (UDP too, but ...
    (comp.lang.python)