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

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...

Comment on Re: IO::Socket::Unix,message type and Connection Reset

Replies are listed 'Best First'.
Re^2: IO::Socket::Unix,message type and Connection Reset by QuillMeantTen (Friar) on Aug 26, 2015 at 07:49 UTC
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	[reply]

Replies are listed 'Best First'.

Re^2: IO::Socket::Unix,message type and Connection Reset
by QuillMeantTen (Friar) on Aug 26, 2015 at 07:49 UTC

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

[reply]