[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: network time service, non-blocking & general TCP multiplexing issues
From: |
Neil R. Ormos |
Subject: |
Re: network time service, non-blocking & general TCP multiplexing issues |
Date: |
Wed, 11 May 2022 11:07:51 -0500 (CDT) |
Andrew J. Schorr wrote:
> 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.
In the example program, if a read timeout were set
for the
getline client < server ,
would that allow the connect status to be polled without
blocking? Or would the gawk-select extension still be
required?