Irek,
Great feedback. Comments inline.
On Wed, Nov 13, 2013 at 6:39 AM, Irek Szczesniak <iszczesn...@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. The call
blocks until a connection is accepted and that inbound connection is bound
to the file descriptor (right after the accept socket is closed). To handle
multiple connections the script can spawn a handler subshell (with a dup of
the descriptor), and immediately close the socket and establish a new
listening socket. For example:
while true; do
exec 5<> /dev/tcp/localhost/:7777 || die 1
(
while read -u 5 -r LINE; do
echo "Echo: ${LINE}" >&5
done
) &
# Close the socket
exec 5>&-
done
Admittedly, there is a very small window when an incoming connection might
get rejected while the handler is being spawned. However, with this model
the implementation is very straight forward and the interface it exposes is
basically the same as creating an outgoing socket. But the point here is
about adding a very useful utility to bash, not about allowing a bash
script to implement a high performance and fully robust server.
Regards,
Joel Martin (kanaka)
