On 09/26/2013 11:44:42 AM, [email protected] wrote:
On Wed, Sep 25, 2013 at 05:57:49PM +0900, Ashwini Sharma wrote:
> Hi Rob, list,
>
> Attached is the implementation of tcpsvd and udpsvd.
> Both the commands are handled in the same file and support __IPv4__
and
> __IPv6__.
>
> Let me know for any comments and add it to the hg.
>
> regards,
> Ashwini
Ok, now that job hunting's out of the way and I no longer feel like
doing nothing but play skyrim with the rest of the time, I need to deal
with the design issues raised by this submission.
> /* tcpsvd.c - TCP(UDP)/IP service daemon
> *
> * Copyright 2013 Ashwini Kumar <[email protected]>
> * Copyright 2013 Sandeep Sharma <[email protected]>
> * Copyright 2013 Kyungwan Han <[email protected]>
> *
> * No Standard.
>
> USE_TCPSVD(NEWTOY(tcpsvd, "^<3c#=30<1C:b#=20<0u:l:hEv",
TOYFLAG_USR|TOYFLAG_BIN))
> USE_TCPSVD(OLDTOY(udpsvd, tcpsvd, OPTSTR_tcpsvd,
TOYFLAG_USR|TOYFLAG_BIN))
>
> config TCPSVD
> bool "tcpsvd"
> default y
> help
> usage: tcpsvd [-hEv] [-c N] [-C N[:MSG]] [-b N] [-u User] [-l
Name] IP Port Prog
> udpsvd [-hEv] [-c N] [-u User] [-l Name] IP Port Prog
>
> Create TCP/UDP socket, bind to IP:PORT and listen for incoming
connection.
> Run PROG for each connection.
Out of curiousity, what does this do that the netcat "server options"
can't do?
Ah. Change user after bind, provide a limited number >1 of
connections,
and set environment variables.
And I see that the command is from ipsvd, not homegrown.
That's the part that really makes me uncomfortable. If this was a
standalone command pair, fine. It duplicates stuff netcat already does
without sharing code with it, having separate tcpd and udpd variants
instead of it just being a flag is a bit silly, but those aren't really
a big deal.
But this is related to a half-dozen other commands that Denys decided
he liked and glued onto busybox, including a whole new init system
that's not what android does, not what ubuntu does, not what redhat
does, and not the conventional sysv one either, and of course unrelated
to the "oneit" that's already in there. And if I say yes to this, how
do I say no to all those _other_ commands? This seems like one of those
"camel's nose under the tent flap" things...
Also, it means being tied to an external command's syntax when that
command does a _lot_ of different things which should probably be more
generic:
Now, the second question...could any of this be shared with netcat?
> IP IP to listen on, 0 = all
> PORT Port to listen on
> PROG ARGS Program to run
Usually the non-option arguments are explained in the initial
paragraph, and then the options get one per line in something like
alphabetical order. The existing initial paragraph is pretty good and
already explains these, but the "Port" vs "PORT" don't quite line up,
so something like:
usage: tcpsvd [-hEv] [-c N] [-C N[:MSG]] [-b N] [-u USER] [-l NAME]
IP PORT COMMAND...
Listen for incoming connections on IP:PORT and run COMMAND to
service each connection.
(The ALL CAPS signifies things that aren't literally supplied but are
values replaced by the user.)
> -l NAME Local hostname (else looks up local hostname in
DNS)
Two questions:
1) Why does it care?
2) If it does care, why would it ever use a different value than the
one returned by "hostname"?
> -u USER[:GRP] Change to user/group after bind
Which requires root access. (Binding to a low port does, up through...
8192 these days? Something like that. But the higher ports don't.)
There should be a general wrapper to do this. In theory you can do this
with "su -c". In practice there should be a less awkward way to do that
which doesn't require a shell invocation to re-parse the command line.
I suppose the toybox su could go su user[:group] [COMMAND...] and exec
the command line as the user? The whole "do a thing then exec the rest
of the command line" wrapper pattern is already fairly well established
by nice, chroot, xargs, time, timeout, detach, nohup, setsid, and of
course netcat.
> -c N Handle up to N (> 0) connections simultaneously
> -b N (TCP Only) Allow a backlog of approximately N TCP
SYNs
First makes sense. The second is a touch micromanaging, but ok.
> -C N[:MSG] (TCP Only) Allow only up to N (> 0) connections
from the same IP
> New connections from this IP address are closed
> immediately. MSG is written to the peer before
close
Simultaneous connections? Connections over time?
I'm looking at this and going "can this plumbing be re-used to
implement httpd" (which is what I was already thinking about the need
to genericize the netcat stuff)?
> -h Look up peer's hostname
Why? (Can't the command do it?)
> -E Don't set up environment variables
What environment variables is this referring to?
> -v Verbose
Again, can't the command do that?
> */
On a cursory inspection, it doesn't look bad, though I have a
suspicion
it could be more concise.
I want to implement portions of it differently, but it's embedded in
another command's expectations which is embedded in a suite of other
commands which I'll then be expected to merge if I take this one...
Rob
_______________________________________________
Toybox mailing list
[email protected]
http://lists.landley.net/listinfo.cgi/toybox-landley.net
