in reply to Non closing sockets - threads

In addition to what BrowserUk said about using our @clients as shared, instead of my @clients; can you put some debugging statements in there to see if control actually gets to the end of the thread and closes the client? 
#close filehandle before detached thread dies out
print "closing lclient $lclient\n";
    close( $lclient);
    #remove multi-echo-clients from echo list
    @clients = grep {$_ !~ $lfileno} @clients;
print "exiting thread .....clients = @clients\n";

[download]

The clients are always connected to the server, except when is some network outage or other gprs disconnections. Then, clients reconnects to the server And there is my problem: Old threads remains connected to the server and I need to get rid of them!

An interesting problem, but it seems that the disconnect should be detected. I wish I had a test setup with many GPS devices to test with.

The first thing that comes to mind, is to keep a hash of connected GPS devices, tracking their id and fileno's, and check for duplicate connections in your server->accept. Another thing is maybe try a different test in your thread for being connected. The connected method returns the address if connected, so maybe you can track addresses, and be sure there are no duplicate addresses?

Maybe try a shorter timeout value? A timeout of 500 is a long time, and may be allowing your device to reconnect before the thread detects the old connection is gone?

I'm not really a human, but I play one on earth Remember How Lucky You Are

Replies are listed 'Best First'.
Re^2: Non closing sockets - threads
by igor1212 (Novice) on Dec 15, 2008 at 18:41 UTC
    Hello Zentara,

    I've tried with debugging statements and you were right, the control never gets to the end.
    I've tried with shorter timeout, but there is no difference.

    If you or BrowserUk, need, I can route my gprs device to some other IP address and simulate disconnects

    Regards, Igor

[reply]
      If you or BrowserUk, need, I can route my gprs device to some other IP address

      No thanks....sounds like work. :-)

      You seem to be isolating the problem, what you need to do now is simplify your example for testing/debugging. Always try to start with the simplest setup, get it working, then add complexity. In your case, just try testing 2 GPS devices, and simplify your thread code (or even remove it and just go with IO::Select), until you see disconnects. Try removing all those If statements, and just have super simple code, like: 

       if($lclient->connected){
           print "1\n";   
         } else{
         print "not connected\n"
   }

      [download]
      Then start building from there. You should be able to turn off your device, and see what happens. Play with simple code until it's working under your control.

      I have a feeling that your GPS devices may not be acting like a regular computer would, and you may need to put some IO::Select code into your thread code, so you can use it's can_read, can_write, and has_exception methods to detect problems in the GPS device. You can setup IO::Select to run on just the single client in each thread, like this untested pseudocode: 

      my $sel = new IO::Select(); 
$sel->add($lclient);              
if($lclient->connected){
          print "connected\n";   
          print "can read\n"  if  ($sel->can_read);
          print "can write\n"  if  ($sel->can_write);
          print "has exception\n"  if  ($sel->has_exception);
} else{
    print "not connected\n"
}

      [download]
      I'm not really a human, but I play one on earth Remember How Lucky You Are
[reply]
[d/l]
[select]
        Hello,

        I've done a simple test with windows client and minimum code on server side, as you suggested...

        After the client(windows client, putty ...) connects to the server and then you close the client, also the thread on the server is closed.
        But, if you interrupt the connection between the windows client and the server, after few seconds the client is closed, but thread on the server remains connected.
        Timeout on the server side, was set at 5 sec.

        Regards, Igor

[reply]

In Section Seekers of Perl Wisdom