What was the original purpose behind this "scalar" anyways?The print function forces list contexts on its arguments, but I think that example you were using wanted to take a single line from the socket and print it out. If you did not put scalar, the list context would have sucked all the input, and probably hang waiting for the peer to close communication (which triggers an EOF). You should substitute the print with some kind of grab in real world usage, unless you only want to print the data from the peer on the screen. To this extent, use my examples.
As for differencing the clients, you can use the accept method in list context to get the peer address, as of IO::Socket documentation; something like:
.my ($conn1, $peer1) = $sock->accept(); die "accept: $!" unless $conn1; # Now $peer1 tells you who is connected to $conn1
Update: sorry, I forgot about the closing question. Generally speaking, if all processes are on the same machine you could use multithreading to ease (and speed up) communications. There exist methods to share memory between threads, which makes communication as easy as reading and writing a variable... if you pay attention to synchronise the accesses to it :). But now I have a question: I thought you have to do this exercise only to test sockets, if you need it in the real world why don't you open the three files in a single process?!?
Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf
In reply to Re^5: sockets and such in Perl
by polettix
in thread sockets and such in Perl
by scotchfx
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |