in reply to Re: Shared.pm
in thread Shared.pm

Hmm...

I am not sure why the test program didn't work for you (it works fine and dandy on this ened); you messaged me that you are running 5.005_03, but I doubt that has anything to do with it (Although it may... you never know :).

However, its not TOO surprising that some people have problems running it, since its in super-early beta, but let me explain how it works so you might be able to figure out the problem. First of all, when a new Shared::Local object is declared, a child is spawned that listens for any connection to it. If it is a valid connection with a valid header, it either recieves the information and stores it, or else sends it back if the special "retrieve" signal is sent. The Shared::Retriever is your interface to the data. Store first serializes the data, then connects to the port and address stored in the Shared::Local/Remote object, until it finally writes a header followed by the data. Retrieve works a bit differently; It starts off similarly to store, but instead of the data being sent, a collection of special characters is sent in order to signify that it should send the data back. If Shared::Local object sees these characters, the Shared::Local object then stores the port and address information, closes the connection, then connects back. In the meantime, the Retriever has since closed its side of the connection, and opened a listening port in order to recieve the information back. The information is then deserialized and returned.

About Shared::Remote: The reason you have to specify a port is for security reasons; if an attacker already knows where he has to go, that is simply less work he has do.

Thank you for bringing up the fact that zombie processes remain if for some reason the socket did not open; I will create a sub that will work similarly to destroy_all except also return a message to die. Thank god for testers :)

Also, by default, Shared lets the OS pick the port (although there is an option in the constructor to specify a specify one if you so choose.)

Finally, I'd like to thank you for taking the time out to test, I truely appreciate it.

Replies are listed 'Best First'.
Re: Re: Re: Shared.pm
by lestrrat (Deacon) on Dec 07, 2001 at 07:41 UTC

    I ran your snippet on a Solaris 5.7... So you're saying that, despite not specifying a port explicitly your snippet is supposed to magically find which port the Retriever is listening on, and Shared::Local can connect to it? hmmm, I guess there must be something I'm missing.

    in any case, sorry, but what I wrote in my orignal post is all the error message I got. :-(

    I'll try it on some other machine when I get the chance -- give me some time before I do it, though

[reply]

      Thats exactly what it does. The Shared::Local object doesn't know where to send the data until a Shared::Retriever connects to it; the Shared::Local connects to send to Shared::Retriever on the same port that the retriever sent the data on, and the retriever listens on the same port it sent the data on. (It closes the port first, of course). This allows support of multiple retrievers able to connect to one Shared::Local.

      I think I am going to add a "debug" switch (at least for now), that will spew out all sorts of data when turned on. Hopefully, this'll help sort out just where exactly you are having the problem.

[reply]

        Sorry for the delay. I tried the same thing with Perl 5.6, RedHat Linux 7.1. After I saw that something wasn't working, I changed the lines

        sub send_data
{
    my ($self, $connection) = @_;
    my $address = eval{$$connection->peerhost};
    my $port = eval{$$connection->peerport};
    $$connection->close;
    my $sock = IO::Socket::INET->new(
                                       Proto    => 'tcp',
                                       PeerAddr => $address,
                                       PeerPort => $port
                                     ) or Carp::confess $@; # <- this 
+used to be die $!
    $sock->autoflush(1);
       syswrite($sock, $self->{data}, length($self->{data}));
    $sock->close;
}

        [download]

        And get the following error :

        IO::Socket::INET: Timeout at Shared.pm line 251
    Shared::Local::send_data('HASH(0x812e004)', 'SCALAR(0x821e260)') c
+alled at Shared.pm line 233
    Shared::Local::new('Shared::Local', 'name', 'new_shared', 'accept'
+, 'ARRAY(0x812decc)') called at test.pl line 5
 at Shared.pm line 394
    Shared::Retriever::retrieve('Shared::Retriever=HASH(0x80f7acc)', '
+Shared::Local=HASH(0x812e004)') called at test.pl line 12
[me@myhost me]$

        [download]

        while $@ contains "timeout", I'm not sure if it's being able to find the Server Socket opened by the Retriever. This also left a zombie process in the background.

[reply]
[d/l]
[select]

In Section Code Catacombs