Re: [PATCH] bash: add socket server support

[Cedric Blancher]

On 13 November 2013 15:46, Joel Martin <github@martintribe.org> wrote:
> Irek,
>
> Great feedback. Comments inline.
>
> On Wed, Nov 13, 2013 at 6:39 AM, Irek Szczesniak <iszczesniak@gmail.com>wrote:
>
>> ':' in *any* Unix paths is not wise because its already used by $PATH.
>>  Likewise ';' is already occupied by version file systems.
>>
>
> I had considered that issue when I was trying to come up with a alternate
> syntax. A colon often precedes listening port numbers in various
> representations so that was why it seemed attractive. After considering it
> back and forth, eventually I decided that since /dev/tcp/* is in effect a
> URL rather than a file path, it should be an issue to include a colon.
> However, I'm not stuck on a colon by any means. Perhaps a dot or dash
> instead?
>
>
>> The other problems I see is:
>> How can the script get access to the data returned by accept()? Unlike
>> ksh93 bash4 has no compound variables yet.
>> How can the accept() socket be passed to a child process so that
>> request processing can be passed to a fork()ed child process?
>
>
> The accept socket is not exposed to the script by this change.

Why?

What happens if someone wishes to set more flags on that socket? Or
wishes to have the per-accept() data, like the requester address? Not
all protocols (say, NFS or non-krb5 rsh protocols) embed the request
address in the request itself, and if you look at the Apache archives
it can even be considered an attack of the address from accept() and
in the request do not match (requester spoofing attack).

So far I can see the server socket you implemented is only barely
enough to do a HTTP server, and not even an good one.

Another consideration is that your design is incompatible with SCTP,
which could be implemented alongside TCP support quite easily.

So much for the criticism.

Maybe a better way would be to implement something which creates a
server socket for accept, and then have a poll builtin (coincidentally
ksh93v- has a very nice poll(1) implementation) which can be used to
wait both on the accept socket and the sockets returned by accept. If
the accept sockets returns an event you could use something like
/dev/tcpserver/nextaccept to open to obtain the next socket returned
by accept(), and store the accept() data in an env variable.

Ced
-- 
Cedric Blancher <cedric.blancher@gmail.com>
Institute Pasteur