in reply to How to Multiplex a Client using IO::Select

I'm not sure what you are asking, and you show no code, but I think you should google for "perl select client" and look at the examples. I would think from your description, is that you want a client to connect to multiple servers, and read write to them? The problem it seems to me, is when a message comes in, how would you know which of multiple servers to write to? You will have to keep a hash of the sockets and see who is sending, then reply to that socket. Usually a client is forked to make it bi-directional, see UDP bidirectional client

Things get complicated fast, if you want a bidirectional client that connects to multiple servers simultaneously. See Simple bi-directional forking commandline client for a single connect client. You could do probably it with select, but it will involve a complex while loop check like this: 

# very crude pseudocode
my $select = IO::Select->new($server1);
$select->add($server2);
$select->add(/*STDIN);  #for sending
# etc etc

my @ready;

while(@ready = $select->can_read) {
   my $socket;
   for $socket (@ready) {
       # see if you can read a socket
        .....
        .....
    }

#see if $select handle is STDIN, if so, send it to all in @ready
}

# do socket close error checking here

[download]
The complexity will get so great, that you are better off using an eventloop system to watch your sockets, like POE or Tk or Gtk2. POE may have something already in it's cookbook, google for it. Look at the Tk client in Simple threaded chat server , it uses fileevent (similar to select) and it would be easy to extend to multiple server connections.
I'm not really a human, but I play one on earth Remember How Lucky You Are

Replies are listed 'Best First'.
Re^2: How to Multiplex a Client using IO::Select
by muthuma (Novice) on Oct 12, 2008 at 11:20 UTC
    First of all thanks for your reply. I will look through links your provided. POE is good idea but the modules is very huge enough to sit in memory constrains applications devices.So i planned to write of my own server and client that suits for my application. Pblm with select is that its behavior is different for platform like Windows and Linux. One example is, STDIN won't work in Windows with select. This has been explained in Network Programming with Perl by Lincoln D. Stein many years back. Over these years any solution has been found for that or i don't know(If there pls provide link for the same). I want to design a platform independent server and client. Provide me if any other way of multitasking.without forks or thread(both has drawback as memory usage. Any other go for memory constrain applications.(or only option is select??).
[reply]
      One example is, STDIN won't work in Windows with select

      So don't insist that everything is selectable. Use select on the sockets which is portable, and use a thread for STDIN. There is only 1 STDIN, so the cost is minimal.

      Your main dispatch loop then becomes something like: 

      my $Qstdin = new Thread::Queue;
async {
    $Qstdin->enqueue( $_ ) while defined( $_ = <STDIN> );
}->detach;

...

while( 1 ) {
    if( my @readers = $selector->can_read( 0.1 ) ) {
        ## See what they have to say
    }
    elsif( my @writers = $selector->can_write( 0.1 ) {
        ## Tell'em what they need to know
    }
    elsif( my @exceptors = $selector->has_exception( 0.1 ) {
        ## Deal with their tantrums
    }
    else {
        while( $Qstdin->pending ) {
            my $kbinput = $Qstdin->dequeue;
            ## do whatever
        } 
    }
}

      [download]

      That should be portable to any OS supporting threads:

      • It uses one thread, so memory use is minimal.
      • It requires no user locking or syncing. Simple code.
      • Doesn't require you to do nasty things like using RAW mode.

        That means that all the facilties provided by the local shell, like:

        • Line buffering.
        • Line editing.
        • History.
        • Macro expansion.
        • Redirection.
        • etc.

        are available without any extra effort, code or complications on your behalf.

      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]

        The second and third timeout should be zero. Better yet, you can combine the three system calls into one: 

        while( 1 ) {
    if (
        my ($readers, $writers, $exceptors) =
            IO::Select::select($selector, $selector, $selector, 0.1)
    ) {
        for( @$readers ) {
            ## See what they have to say
        }
        for( @$writers ) {
            ## Tell'em what they need to know
        }
        for( @$exceptors ) {
            ## Deal with their tantrums
        }
    }
    if( $Qstdin->pending ) {
        my $kbinput = $Qstdin->dequeue;
        ## do whatever
    }
}

        [download]

        Another possible improvement would be to ditch Thread::Queue in favour of a Win32::Socketpair "pipe".

[reply]
[d/l]
        my $Qstdin = new Thread::Queue; async { $Qstdin->enqueue( $_ ) while defined( $_ = <STDIN> ); }->detach; In this code while waits for input. when does the thread context switch to while(1) loop??. It is looping in while defined ($_ = <STDIN>)
[reply]
        Ya it is very good idea. I will try with it. Above code snippet is in while 1 loop how does the can_read or selection would know the service has disconnected.. Whether has_exception will take care of it??(will try it). Command on that.
[reply]

In Section Seekers of Perl Wisdom