Fredde87 has asked for the wisdom of the Perl Monks concerning the following question:

Hi Guys, I am trying to write a simple socket server which will accept multiple connections. I have this code code below which opens a socket and allows multiple connections. At the moment it only posts back to all the connected clients what someone has sent. But I am going to add switch statements here to perform various tasks depending on what the client sends. This all works great but the problem I have is creating some sort of a child process running on the side which is an infinite loop. The infinite loops role is to send out a keep alive signal on the socket to all the clients every X seconds. How do I do this? I am new to perl but I understand that I someone need to share $read_set to the child process? I tried IPC::Shareable but that failed so I am guessing I need to do something with pipe maybe? Can you please advice how I best accomplish this. Thanks! 
#!/usr/bin/perl -w
#
# Socket for communication
 
# Libraries
use IO::Socket;
use IO::Select;
use IO::Handle;
 
my @sockets;
my $s = new IO::Socket::INET (
                        LocalHost => '192.168.0.1',
                        LocalPort => '1234',
                        Proto => 'tcp',
                        Listen => 16,
                        Reuse => 1,
                        );
die "Could not create socket: $!\n" unless $s;
 
$read_set = new IO::Select(); # create handle set for reading
$read_set->add($s);           # add the main socket to the set
 
while (1) {
        my ($rh_set) = IO::Select->select($read_set, undef, undef, 0);
        foreach $rh (@$rh_set) {
                if ($rh == $s) {
                        # Client has connected
                        $ns = $rh->accept();
                        $read_set->add($ns);
                } else {
                        $buf = <$rh>;
                if($buf) {
                        # Client has sent something
                        $buf =~ s/\n|\r//g;
                        my @sockets = $read_set->can_write();
                        foreach my $sck(@sockets){print $sck "Hi every
+body, I just received the following for one of you: $buf\r\n";}
                }
                else {
                        # Client has disconnected
                        $read_set->remove($rh);
                        close($rh);
                        }
                }
        }
}

[download]

Replies are listed 'Best First'.
Re: Printing to all clients on a socket from a child process
by BrowserUk (Patriarch) on Mar 11, 2008 at 14:29 UTC
    The infinite loops role is to send out a keep alive signal on the socket to all the clients every X seconds.

    One simple mechanism would be to have the child process (or thread) connect back to the listening socket and send a message every X seconds. Your existing code without modification would forward these to each of the clients as any other message. Though you might want to avoid sending stuff to the keep-alive client. Once you start discriminating about what messages you forward to what clients, the keep-alive just gets forward to all clients (except it's originator) as now.

    Of course, the next step is likely to be to only send keep-alive messages to those clients that you haven't sent any message to (and perhaps, received a message from) for the last X seconds. It's at this point that the thread would come into it's own, as you can then use a shared hash to record the last time a message was sent to each client.

    The keep-alive thread then wakes up every X/n (where n depends upon the resolution you require), scans the shared hash, and sends keep-alive messages, with a client identifier parameter, for each client who's time falls due within the next X/n period. Your main select loop will receive and forward these messages in the normal way.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      I have tried this solution as a backup. There is only one problem with it which is that some of my functions can take up to a minute to complete. That means I wont get a keep alive until it finishes. Is there an easy way to get around that so that I still process the keep alives whilst one of my functions is running?
[reply]

        Simplistically, put the functions in a thread also. That also allows your select loop to remain responsive to other comings and goings.

        Of course, then you need to track what threads you've started on behalf of what clients. and that starts to complicate things a bit. You could have the function threads connect back to the listener to return results, but depending upon how many clients you have it could get expensive spawning threads for short processes.

        A better architecture, especially with ithreads, would be to have your longer running functions run in long-running threads with loops reading from function specific queues and writing back to a shared results queue for dispatch. The select loop uses a timeout and monitors the results queue using dequeue_nb().

        That's harder to describe than write, but if the tachnique interests you I could probably adapt your example to demonstrate it?

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
Re: Printing to all clients on a socket from a child process
by pc88mxer (Vicar) on Mar 11, 2008 at 15:48 UTC
    After you fork, parent and child do not share memory in the sense that if the parent changes a variable the child will not see that change and vice-versa. So, even though $read_set will be the same right after the fork, when the parent accepts a new connection and changes $read_set accordingly, the child's value of that variable will not change. Copies of all data structures (including open file and socket connections) are made at the time of the fork, but then they become independent.

    Given that the child won't be able to 'see' new client connections to the parent, I think the best option is to place the keep-alive function in the parent and dispense with the child process. Even if you could share sockets between the parent and child which is possible, but tricky), it complicates your protocol since you don't want writes from the parent and child to interfere with each other.

[reply]
[d/l]
[select]
      Have you got any suggestions on where I place my keep alive in the parent? I explored this route but always got stuck as the Keep Alive would never end.
[reply]
        I would just do it in your I/O processing loop. At the end of the loop, just check if it is time to send the keep-alive message. You can keep track of things on a per-client basis, or just use the same timing for all clients.

        In your can_read call, you'll want to use a timeout value that's equal to your keep-alive period so that you won't miss sending out a keep-alive message on time.

[reply]
[d/l]
Re: Printing to all clients on a socket from a child process
by zentara (Cardinal) on Mar 12, 2008 at 13:38 UTC
    See Simple threaded chat server. Threads can share socket filehandles thru the fileno. Look at the multi-echo chat example. You can share the clients in a shared array.

    So all you would need to do is create another thread for your keepalive signal, and put in it 

     foreach my $fn (@clients) { 
      open my $fh, ">&=$fn" or warn $! and die;
       print $fh  "keepalive\n"  
  }

    [download]
    I'm not really a human, but I play one on earth. Cogito ergo sum a bum
[reply]
[d/l]
Re: Printing to all clients on a socket from a child process
by Anonymous Monk on Mar 11, 2008 at 14:19 UTC
[reply]
      Thank you for your quick reply. However I need to send a specific string as it will also contain data needed by the client on a regular basis. Thanks!
[reply]

Back to Seekers of Perl Wisdom