Re: IPC Design problem

You wrote:

"... whether they be on separate hosts or on the same machine."

The first line of "perlipc: Named Pipes" has (my emphasis):

"A named pipe (often referred to as a FIFO) is an old Unix IPC mechanism for processes communicating on the same machine."

So, given you want the ability to communicate across hosts, named pipes would not be a suitable solution.

Sockets would be a better option. There's lots of documentation and sample code in perlipc.

— Ken

Comment on Re: IPC Design problem

Replies are listed 'Best First'.
Re^2: IPC Design problem by QuillMeantTen (Friar) on Aug 25, 2015 at 06:30 UTC
I know that I had the idea to chain messengers. Say gate ones that would use sockets and interior one using named pipes or Unix sockets ( I could implement both and choose depending on the platform). What I'm not so sure about is the design choice of letting anyone but a head of messengers demon open the necessary file handles :-$ Update I'm going to give it a try that way : only the head of messengers do the file handle management, he shall use a named pipe for his orders (thus making itself easily cross platform) and shall receive his working parameters as a hash of the following type : `my %params = ( input=>{name=>'filename', type=>'unix_socket\|network_socket\|named_pipe', bind=>address,#if network socket}, output=>{output1=>'filename\|socket_name', output2=>'idem', ... ... }, );` [download] then he shall open the file handles and create a child process with a little messenger demons that will relay data to and from them. It seemed more elegant than the first idea where I count on other modules to make the right parameter hash for the messenger demon instanciation method (furthermore it should allow me to update this method without having to change code everywhere). I will post the resulting code in the CUFP section, might give some of you quite a laugh (I'm quite new to multi process programing). Cheers!	[reply] [d/l]

Replies are listed 'Best First'.

Re^2: IPC Design problem
by QuillMeantTen (Friar) on Aug 25, 2015 at 06:30 UTC

I know that I had the idea to chain messengers.

Say gate ones that would use sockets and interior one using named pipes or Unix sockets ( I could implement both and choose depending on the platform).

What I'm not so sure about is the design choice of letting anyone but a head of messengers demon open the necessary file handles :-$

Update I'm going to give it a try that way : only the head of messengers do the file handle management, he shall use a named pipe for his orders (thus making itself easily cross platform) and shall receive his working parameters as a hash of the following type :

my %params = (
    input=>{name=>'filename',
            type=>'unix_socket|network_socket|named_pipe',
            bind=>address,#if network socket},
    output=>{output1=>'filename|socket_name',
             output2=>'idem',
             ...
             ...
             },
);
[download]

[reply]
[d/l]