Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Re^2: POE TCP client problem

by baldeep8 (Initiate)
on Jan 08, 2010 at 07:21 UTC ( [id://816230] : note . print w/replies, xml ) Need Help??

in reply to Re: POE TCP client problem
in thread POE TCP client problem

Hi rcaputo,

Thanks a lot for the reply. I have already tried using POE like the way you have suggested. I have used Client Input on the server side and Server Input along with Connected components on the client side. My problem on the Client side is that i am not able to synchronize between sending and receiving files. We do a put ie a send operation in the Connected part and do a receive ie a heap input operation on the Server Input part. But how do we then synchronize if i want to first write a file then read then again write and then read again. This requires some kind of synchronization between Server Input and Connected components reads and writes. I am not sure how to do this. Please help.

#!/usr/bin/perl -w use strict; use POE; use POE::Component::Client::TCP; use POE::Filter::Reference; my $host = "localhost"; # The host to test. my $port = 11212; my @values = (6, 2); POE::Component::Client::TCP->new( RemoteAddress => $host, RemotePort => $port, Filter => "POE::Filter::Reference", Connected => sub { my $j = "teste"; print "connected to $host:$port ...\n"; $_[HEAP]->{server}->put(\@values); }, ConnectError => sub { print "could not connect to $host:$port ...\n"; }, ServerInput => sub { #when the server answer the question my ($kernel, $heap, $input) = @_[KERNEL, HEAP, ARG0]; print "got result from $host:$port ... YAY!\n"; #print to screen the result print $$input. "\n"; }, ); $poe_kernel->run(); exit 0;

Replies are listed 'Best First'.
Re^3: POE TCP client problem
by rcaputo (Chaplain) on Jan 11, 2010 at 06:43 UTC

    I suspect I misunderstand your protocol. Based on my reading of your sample code, the timing seems to be:

    • Client sends a file to the server in response to establishing a successful connection.
    • Server receives the client's file and sends a file to the client in response.
    • Client receives the server's file and sends a file to the server in response.
    • The last two steps repeat until some ending condition is reached.

    That sort of protocol tends to be self-synchronizing. Neither the server nor the client will send a file out of turn, so logic for handling out-of-turn files isn't necessary. If it weren't for the client taking initiative, nothing would happen at all.

    If you want to identify when one or the other side is desynchronized, then you can store a "sender" or "receiver" state in a variable, or in $_[HEAP]. The client begins in the "sender" state, and the server starts in "receiver" mode. If input arrives when a client or server is in "sender" mode, that's an error. Each side switches from sender to receiver upon successful transmission of a file. Each side switches from receiver to sender upon successful receipt of a file.