On Wednesday, May 29, 2002, at 10:35 , John Hennessy wrote:

> Hi, I am looking for a good IO::Handle example for a simple client and
> server.
>
> I have checked the perlipc document but must still be missing
> something. It echoes data back to client ok but I simply need to have the 
> server listening for client connections and print the data to another
> filehandle. Bi-directional support is not required.


somewhere's on or about page 18 or so of the perldoc perlipc
is where I'm looking at the handy dandy server side play....

where you will find code of the form:


          for ( $waitedpid = 0;
                accept(Client,Server) || $waitedpid;
                $waitedpid = 0, close Client)
          {
              next if $waitedpid;
              logmsg "connection on $NAME";
              spawn sub {
                  print "Hello there, it's now ", scalar localtime, "\n";
                  exec '/usr/games/fortune' or die "can't exec fortune: $!"
;
              };
          }

well note that is essentially an 'autonomouse' sub that is
being passed to 'spawn' .... hence you could diddle that
to be more what you want - vice the spawn function:


          sub spawn {
              my $coderef = shift;

              unless (@_ == 0 && $coderef && ref($coderef) eq 'CODE') {
                  confess "usage: spawn CODEREF";
              }

              my $pid;
              if (!defined($pid = fork)) {
                  logmsg "cannot fork: $!";
                  return;
              } elsif ($pid) {
                  logmsg "begat $pid";
                  return; # I'm the parent
              }
              # else I'm the child -- go spawn

              open(STDIN,  "<&Client")   || die "can't dup client to stdin"
;
              open(STDOUT, ">&Client")   || die "can't dup client to stdout"
;
              ## open(STDERR, ">&STDOUT") || die "can't dup stdout to 
stderr";
              exit &$coderef();
          }

which is a really lovely way to stay with the whole process of
having the children of your server cope with the client so that
your server can get back to the next request for service...

note that it is calling the logmsg function - which really all
you want in some senses. So your spawned code might actually
'read the stdin' for the messages from the client, thank the
client politely, close the connection to the client and
exit gracefully....

ciao
drieux

---


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to