[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: network time service, non-blocking & general TCP multiplexing issues
From: |
Andrew J. Schorr |
Subject: |
Re: network time service, non-blocking & general TCP multiplexing issues |
Date: |
Wed, 11 May 2022 11:50:48 -0400 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Wed, May 11, 2022 at 11:46:28AM -0400, Andrew J. Schorr wrote:
> We have discussed in the past possibly patching the TCP implementation to
> remedy this flaw, but nobody has invested the time and effort to fix this. We
> would need to come up with a separate naming convention for these TCP
> multiplexing sockets so as to avoid breaking existing code.
N.B. in an email from April , 2016, Arnold proposed the "inetserv" namespace:
On Mon, Apr 04, 2016 at 10:54:58PM +0300, Aharon Robbins wrote:
> I think this is actually rather easy to solve, by introducing
> a new namespace:
>
> server = "/inetserv/tcp/8080/0/0"
> while (1) {
> # wait for a client to connect
> getline client < server
> # at this point, client contains the handle for the connected socket,
> # something like "/inet/tcp/8080/client-host/client-port", and the
> server
> # socket should still be open to accept new connections!
> while ((client |& getline x) > 0)
> printf "client %s says: %s\n", client, x
> close(client)
> }
> close(server)
>
> To read handles it's better (IMHO) to use a < redirection, since
> it's a one way communication.
If you add the select extension to the mix, you could then build a true
multiplexing TCP server.
It's been on my to-do list for years. Sigh. But if somebody is eager
to do this, a patch would be welcomed.
Regards,
Andy