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.

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

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.