On Friday, May 10, 2002, at 10:41 , Simon K. Chan wrote:
[..]
> I've never tried something like this before, so
> my apologies if it's "easy"
the problem is that it 'looks easy' - and actually is a
part of why there is so much 'network code' in the Net::*
section - to try and deal with the problem.
> We all know about the system command:
>
> my $program = "some_script.pl";
> system("perl",$program);
>
> This would execute the program some_script.pl
> on the current host.
depending upon the remote host's OS and security
configurations you could also do
my $cmd = "rsh -l $user $farhost $script"
system($cmd);
and use a 'remote shell' approach.
> But what if I wanted to run a script on
> another host? Should I create a socket?
most likely a socket will get created.... either
by you or by the code that you call.
> use IO::Socket;
> my $socket = IO::Socket::INET->new(PeerAddr => "$remote_host",
> etc.
let us say that you do the
perldoc -m Net::Telnet
you will find embedded in the bowls our old friends:
## Turn on timer.
local $SIG{'__DIE__'} = 'DEFAULT';
local $SIG{ALRM} = sub { die "timed-out\n" };
alarm $timeout;
## Lookup server's IP address.
$ip_addr = inet_aton $host
or die "unknown remote host: $host\n";
## Create a socket and attach the filehandle to it.
socket $self, AF_INET, SOCK_STREAM, 0
or die "problem creating socket: $!\n";
## Open connection to server.
connect $self, sockaddr_in($port, $ip_addr)
or die "problem connecting to \"$host\", port $port: $!\n"
;
};
alarm 0;
Yup - looks like a socket level connection...
as you notice it is trying to connect to $port - so you can
get around that part of the process by targetting things other
than the named telnet daemon.
> I'm trying to run a BLAST program on the
> other machine.
Not sure what a 'blast' programme is - nor what OS you
are dealing with on both ends of the play....
So if you don't have the basic solutions of things like
rsh/ssh usable on both ends, and you don't want to run
it as a stock Net::Telnet style connection - you then
also want to deal with whether or not you want to build
both the client and the server - so that you have a fixed
target on the far host to 'bridge' for you - and allow
access to the output of this 'blast' programme.
One strategy on that side of course is to play the good
old fashion 'hey kids, building a webserver is not that
complex' - in lieu of a full apache install - and so
spin up your 'server' on REMHOST to do the bridge work
in the classical HTTP model - at which point your
client side can then work with the standard
use CGI qw/:standard/;
use URI;
use LWP::UserAgent;
so that you have a one size fits all "all singing all dancing"
multiple threat piece of code like:
http://www.wetware.com/drieux/src/unix/perl/UglyCode.txt
granted - if this 'blast' programme can be registered as a
'network service' = such that it will be invoked by what
ever the equivolent of inetd is on the remHost's OS - then
the simple socket connection and rewhacking that occurs
with things like portmapper can be of some fun for the
coding and maintenance of socket level connections.
Please do let us know how you wish to proceed.
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
