[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-inetutils] multihost variant of rsh

From: Alain Magloire
Subject: Re: [bug-inetutils] multihost variant of rsh
Date: Mon, 23 Dec 2002 22:30:36 -0500 (EST)

> Not exactly a bug but I didn't know where else to send this.

Very interesting.

I will take a closer look when I have more time to the ftp
site you quoted.  Thanks for the notes.

> I have placed a hacked up version of the rsh from inetutils
> 1.4.07 in this directory:
>   ftp://saf.bio.caltech.edu/pub/software/linux_or_unix_tools/
> It can perform the following functions (which are really handy
> when you have a lot of nodes to work on):
>   rsh node1,node2,node3...,nodeN command #run command on all nodes
>   rsh -f file_of_nodes.txt command #ditto, names from a file
>   rsh -zf file_of_nodes.txt /etc/rc.d/init.d/xinetd restart
> -z kills all IO.  It lets rsh start up jobs and not have to
> wait around for them to finish.  This is the fastest way I know
> of to start jobs on remote systems.  It is very handy in
> cases like the one shown.
> There are some limitations.  For instance, this is completely
> undefined:
>   cat file | rsh -f file_of_nodes.txt command 
> since command on one node might read more or less data
> than command on another node.  In most cases command will
> consume all of stdin (since it won't exit until it hits EOF)
> and that will leave nothing for the other nodes.
> This also doesn't work presently:
>   rsh address@hidden,address@hidden command
> although it could be made to work with a little effort.
> This version of rsh can also read from Unix message
> queues take that data, instead of stdin, and send
> that to a single node.  You can test that capability
> easily enough with the command line program "msgqueue.c"
> also present in that directory.
> The need to read from message queues may
> be a bit obscure but I'm going to use this
> functionality to test methods of command fan out. 
> That is, an internal node in a tree structured computing
> grid might have one uplink and two down links.  Then
> the fanout system would be started something like this:
>   msgqueue -k 1 -c #message queue for uplink
>   msgqueue -k 2 -c #message queue for downlink1
>   msgqueue -k 3 -c #message queue for downlink2
>   msgqueue -k 4 -c #message queue for fanoutd
>   # start next 4 as daemons
>   daemon rsh -k 1 uplinknode msgqueue -k 4 -send 
>   daemon rsh -k 2 leafnode1  msgqueue -k 4 -send
>   daemon rsh -k 3 leafnode2  msgqueue -k 4 -send
>   daemon fanoutd
> The fanout daemon on each node reads messages
> from queue 4 and directs messages up via queue 1
> or down via either 2 or 3. This could also be
> accomplished with a single queue and 4 message types.
> Regards,
> David Mathog
> address@hidden
> Manager, Sequence Analysis Facility, Biology Division, Caltech
> _______________________________________________
> Bug-inetutils mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-inetutils

au revoir, alain
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!

reply via email to

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