Re^2: Bidirectional Client/Server - to fork or not to fork?

You certainly have a good grasp on the workflow of it!

I showed it in my other node but a visual of the process is like this(read from left to right, top to bottom for clarification):

# RQ = Incoming request sent to listening remote server

# RS = Response sent from local server to remote server
#      OR remote server to local server "flagging"
#      that the socket message was accepted by the server.
#     (Context of usage shown below)

# ST = Status of request at time of processing. More often than not,
#      this would be sent asynchronously from local server to remote
#      server.

Remote    Local
------    -----

RQ    --> 

      <-- RS

      <-- ST

RS    -->
[download]

Comment on Re^2: Bidirectional Client/Server - to fork or not to fork? Download Code

Replies are listed 'Best First'.
Re^3: Bidirectional Client/Server - to fork or not to fork? by RonW (Parson) on Dec 07, 2015 at 17:21 UTC
If you can't find a suitable module/framework, Parallel::ForkManager could be used to maintain a pool of worker processes that you main server process can delegate to. At a minimum, the worker processes would need to be able to handle receiving any of the messages from you local server. Depending on how your code will interface with the ILS software, the workers may also need to be able to handle sending messages as well. Or the ILS software might be able to have it's own workers invoke the sending scripts directly. Or your send-side ILS interface could delegate to workers of it's own. Forking is probably easier, especially if you use something like Parallel::ForkManager. Alternately, you could try to use threads. I can only assume that there is threads equivalent to Parallel::ForkManager you could use. Is possible to to do this with out forking or threads by using IO::Select].	[reply]

Replies are listed 'Best First'.

Re^3: Bidirectional Client/Server - to fork or not to fork?
by RonW (Parson) on Dec 07, 2015 at 17:21 UTC

If you can't find a suitable module/framework, Parallel::ForkManager could be used to maintain a pool of worker processes that you main server process can delegate to. At a minimum, the worker processes would need to be able to handle receiving any of the messages from you local server. Depending on how your code will interface with the ILS software, the workers may also need to be able to handle sending messages as well. Or the ILS software might be able to have it's own workers invoke the sending scripts directly. Or your send-side ILS interface could delegate to workers of it's own.

Forking is probably easier, especially if you use something like Parallel::ForkManager. Alternately, you could try to use threads. I can only assume that there is threads equivalent to Parallel::ForkManager you could use.

Is possible to to do this with out forking or threads by using IO::Select].

[reply]