How to control a background job

[Bill Cox]

Hi.

I could use some advice on the best way to control a background job.
The interface to the job has two goals: first, to allow for text based
control; second to allow a simple interface that nicer GUI could drive
(which I don't intend to write). What's the best way to do it?

The job I'd like to conntrol is btslave, a BT client that typically will
run in the background. It's primary job is helping your normal BT
client download faster (as a slave repeater). It needs to be told when
to join a torrent, or it wont know that you're downloading. Right now,
I kill the job, and restart it with the torrent file name on the command
line.

Several options come to mind:

I could just parse user commands from the command line, like ftp.
However, as a demon running in the background, I don't know how to get
access to stdin and stdout. I could also use a config file, and send a
SIGHUP signal to btslave to have it re-read it. That's not very user
friendly. I could support a telnet port, and get access to a command
line interface that way. I could support a ssh connection directly to
btslave. Is this hard? Portable? I could provide an http interface,
the way swat does. That's a lot of work. I could support a command
line interface, but enable one copy of btslave to control another over a
TCP connection.

There are other permutations. How would you guys do it?

Thanks,
Bill





Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Nick Johnson]

Post by Bill Cox
Hi.
I could use some advice on the best way to control a background job.
The interface to the job has two goals: first, to allow for text based
control; second to allow a simple interface that nicer GUI could drive
(which I don't intend to write). What's the best way to do it?
The job I'd like to conntrol is btslave, a BT client that typically will
run in the background. It's primary job is helping your normal BT
client download faster (as a slave repeater). It needs to be told when
to join a torrent, or it wont know that you're downloading. Right now,
I kill the job, and restart it with the torrent file name on the command
line.
I could just parse user commands from the command line, like ftp.
However, as a demon running in the background, I don't know how to get
access to stdin and stdout. I could also use a config file, and send a
SIGHUP signal to btslave to have it re-read it. That's not very user
friendly. I could support a telnet port, and get access to a command
line interface that way. I could support a ssh connection directly to
btslave. Is this hard? Portable? I could provide an http interface,
the way swat does. That's a lot of work. I could support a command
line interface, but enable one copy of btslave to control another over a
TCP connection.
There are other permutations. How would you guys do it?

Assuming this is on *nix, I would have the daemon process create a
(datagram?) unix socket in an agreed location (/var/run or /tmp,
typically), and issue commands to it over that. The executable could
either daemonise itself or send instructions to an already daemonised
process over the socket, depending on the command line parameters
provided. The existence of the socket can also be used to prevent more
than one daemon starting, if that's desired.

-Nick Johnson



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Kenneth Porter]

I could support a telnet port, and get access to a command line interface
that way. I could support a ssh connection directly to btslave.

You could go raw TCP (you don't need full telnet). Instead of ssh, allow
binding the TCP port to a specific interface, so the user can bind to
127.0.0.1, and then you can use a regular ssh client to tunnel to it. Also
consider a Unix socket (or for Win32, a named pipe).

Both of these give you a raw byte stream over which you can send a simple
command stream.

I could provide an http interface, the way swat does. That's a lot of
work.

Depends on how fancy you get. You don't have to implement a fancy graphical
system. Unreal Tournament (the game) has a pretty nice web admin interface
that's not that big a chunk of code. Embedded web servers can be pretty
tiny. The hardest part is probably the URL parser, and if you've already
got to write a command parser, you're most of the way there.



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

[Iain Wade]

Post by Bill Cox
There are other permutations. How would you guys do it?

run a copy of btlaunchmanycurses.py in a screen and detach it.

to run a torrent file, move it to the directory btlaunchmanycurses.py
is watching.
to remove a torrent, move it out of the directory btlauchmanycurses.py
is watching.
to list torrents, do an ls or the directory btlaunchmanycurses.py is watching.

a web interface could easily perform these actions ...

--Iain



Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
BitTorrent-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/