[Top][All Lists]

[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]