IO::Socket::Unix,message type and Connection Reset

[QuillMeantTen]

Greetings

After some time banging my head to a wall (and much more time reading through previous posts such as this one I have come to some discoveries that bring yet more questions regarding the message passing daemon that I am writing :

1. a continuous write such has my sub{my $c = 0; while(1){$sock->print("$c\n");$c++}} quickly ends up with the remote end hanging up
2. same write with a sleep in each loop works fine
3. this does not seem to happen with simple named pipe, but if I fill a named pipe without a reader on the other end I quickly fill my ram with crap(or more accurately whatever I did put in the named pipe
4. SOCK_STREAM seems fine for text line but what about serialized data?

I have tested my code using the following combination:

• named pipe input, named pipe output : no issue with a loop without sleep
• unix_socket input, named pipe output : the issue I talk about

Now, after some debugging I discovered that my testing program crashed when the connection was reset by the peer, is there anyway to reconnect to an unix socket after the connection has been reset and do so without crashing?

or should I just take care of not sending to much data at the same time?
And last but not least, since I am going to use that message passing daemon to carry serialized objects around is SOCK_STREAM a bad idea?

[Anonymous Monk]

Now, after some debugging I discovered that my testing program crashed when the connection was reset by the peer, is there anyway to reconnect to an unix socket after the connection has been reset and do so without crashing?

What does "crash" mean, do you mean die? You can catch those with eval

or should I just take care of not sending to much data at the same time?

:) sure why not

And last but not least, since I am going to use that message passing daemon to carry serialized objects around is SOCK_STREAM a bad idea?

:) I don't know, but I'm curious why not start a little higher up, say Net::Server...

[QuillMeantTen]

sorry, yes I meant die, thank you for the tip about eval, I have no idea why I did not think about that.

Problem is I have no idea what would be too much data and I find the reputation of unreliability of SOCK_DGRAM quite scary...

About starting higher up, thing is I need some granularity : each module must be able to run either on a windows or unix box and they need to be able to request the best messaging daemon performance wise (meaning they should use unix sockets when on unix box to communicate with other processes on the same box, named pipe to do so on windows and INET sockets on to communicate over the network).

Up to now I only have implemented named pipe communication and unix sockets but I think I shall use the fine module in the link you just sent me for the network communication! thanks a bunch :D