Reputation: 2717
I need to write a client server application in perl. Many clients will send requests and will be handled via server.
What is best approach to develop such client server application. I searched web and found LWP and IO::Socket as possible contenders.
What is best approach to handle multiple clients? Is this to fork seperate process or use threads to handle many clients.
This is my first time with client-server programming on perl so confused.
Upvotes: 1
Views: 398
Reputation: 53488
OK, so - the problem with handling multiple concurrent clients is that you need to handle the asychronous incoming data. Normally - reading from a socket (or filehandle) is a blocking operation, which means one client will 'shut out' the others.
There's two major approaches to handling this - one is to read in a nonblocking fashion from your file descriptors, using something like IO::Select
and can_read
- then you test which of your sockets has pending IO, process it and repeat.
From the docs:
use IO::Select;
use IO::Socket;
$lsn = IO::Socket::INET->new( Listen => 1, LocalPort => 8080 );
$sel = IO::Select->new($lsn);
while ( @ready = $sel->can_read ) {
foreach $fh (@ready) {
if ( $fh == $lsn ) {
# Create a new socket
$new = $lsn->accept;
$sel->add($new);
}
else {
# Process socket
# Maybe we have finished with the socket
$sel->remove($fh);
$fh->close;
}
}
}
Or you can multiprocess using threads
or forks
- when you do this, you 'split' your process, and run separate instances, each responsible for a single client.
Which of these approaches you take depends very much on what you're trying to accomplish. fork
is especially good for fast efficient start up, because it's implemented natively on POSIX operating systems. However it's not as friendly for doing interprocess communication (IPC) so if your clients need to communicate... personally, I wouldn't.
As noted in the comments - some basic forking code can be found in perlipc
Threading is similar to forking - it's not recommended by the perl documentation, because it's not lightweight. But it does make the process of communicating between your threads quite a bit easier. I would suggest if you do this, you look at threads
, threads::shared
and Thread::Queue
.
Using a non blocking read approach means you can potentially do all this without having to fork or thread at all, but it only really works if you're doing 'little' things each iteration - each incoming client will stall whilst you process the next, which can mean more latency. (This may not matter though).
Perlmonks has some more examples of different client types: http://www.perlmonks.org/?node_id=436988
Upvotes: 4