QuillMeantTen has asked for the wisdom of the Perl Monks concerning the following question:

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:


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?

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

Replies are listed 'Best First'.
Re: IO::Socket::Unix,message type and Connection Reset
by Anonymous Monk on Aug 26, 2015 at 07:42 UTC

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

      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