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

reply via email to

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