1. Are you planning on establishing the pipes once and or on demand? If the first, don't forget to deal with a box going down or loosing network connection and reconnecting.

2. Non-blocking waits are wonderful.

3. Not knowing if this is personal or business, are their any firewall issues? Is any data sentitive (cleartext passwords) to encrypt. This can be additional fun things to dabble in.

4. Can any of the back-end scripts be abused? If so, set up some sort of authentication. This could be combined with encryption from #3.

These aren't to scare you off, I really like pipes. Just some things that may apply, and you might want to explore. Go for it!

=Blue
...you might be eaten by a grue...

Hi,

I have answered some of your questions in my new post above, but I am not sure what you mean by a non-blocking wait.

• They're unidirectional
• They only work between processes running on the same machine

I wrote a tutorial about this sort of thing a while back, which includes a few caveats (<grouse>including one which no-one believes exists... If nothing else, the documentation tells you not to use buffered IO with select, so stop doing it, dammit</grouse> ahem). If your requirements are simpler, you can use the other tutorial

Run servers on the slave machines, and clients on the master machine (in case you didn't find that totally obvious...). If you can connect to the slaves from the outside world, you will need some sort of security - either block the port at your router or firewall, or just check the originating IP with a piece of code like:

# $sock is the socket: this will work if you aren't using IO::Socket:
($port, $iaddr) = sockaddr_in(getpeername($sock));
$peer_addr = inet_ntoa($iaddr); # String, numbers and dots notation

# Or, if you're using IO::Socket
$peer_addr = $sock->peerhost();
[download]

Andrew.

Something odd happened there... Who ate my cookie?

Hmm, I was editing that at www.perlmonks.org, where I have a cookie set, but it posted it at perlmonks.org, where I don't... Gah... Assuming this posts correctly, you'd better vote on this node to see that credit/shame gets to the right place...

Andrew.

AgentM Systems or Nasca Enterprises is not responsible for the comments made by AgentM- anywhere.

Thanks, I will go ahead with this, I couldn't find info on IPC::Message on CPAN, but I will look harder!

Damn! Sorry about that. i meant IPC::Msg.


AgentM Systems or Nasca Enterprises is not responsible for the comments made by AgentM- anywhere.

Hi,

Thanks for all your help,

This is (I hope) a clearer explanation of what I am thinking of doing:

I am going to set up the clients on the master machine and the servers on the slave machines as ahunter points out. But are they only for use on one machine? I get the impression from Win32::Pipe, that you specify a server for the pipe to reside on (if that's the right terminology), but you can access it on another networked machine.

I plan on setting up the pipes once, when the machine boots up, so I will have to think more about the machine going down or losing network connection. Thank you Blue.

I hope that my scripts will be secure - you shouldn't be able to get them to format the hard disks or anything. But I will try and impliment some sort of extra security.

I suppose I will have to work this one out by trial and error, but once the pipe is 'open' to the pipe, how can I make the server 'end' keep checking the pipe to see if anything is written at the other end? i.e. I don't want the server to accept the connection, try read what's coming down, but not find anything because it hasn't been sent yet.

e.g. in this example (from roth.net) - if the client doesn't send straight away won't the server end up with an empty variable for $In?...



    if( $Pipe->Connect() )
    {
      my $In;
      
      $User = ( $Pipe->GetInfo() )[2];
      print "Pipe opened by $User.\n";
      
      $In = $Pipe->Read();
      
      print "Client sent us: "$In";
      
      print "Disconnecting...\n";
      $Pipe->Disconnect();
    }
[download]


Thanks for all your help.