in reply to Bidirectional Client/Server - to fork or not to fork?

In my experience, you need to open 2 sockets: one to to listen for and accept incoming connections, and the other to connect to the other server.

If I'm understanding your 2 posts correctly, I would imagine a processing flow like:

  1. Remote Server listens on a port for incoming connections.
  2. When an incoming connection is detected, delegate a worker process/thread.
  3. Worker accepts the connection while the Remote Server resumes waiting for incoming connections.
  4. Worker receives the message and validates it.
  5. If validation fails, worker sends a negative response, closes the connection then becomes idle (or terminates itself).
  6. Otherwise, worker sends a positive response, closes the connection then processes the message.
  7. If no results message needs to be sent, worker becomes idle (or terminates itself).
  8. Otherwise, worker opens a socket, connects to your Local Server and sends the results message.
  9. Worker waits for positive/negative response. Once received, closes the connection.
  10. Worker performs any needed follow up based on the positive/negative response.
  11. Worker becomes idle (or terminates itself).

In the case where the Remote Server is initiating the transaction, a worker would proceed as above as though it were sending a results message. Any results sent back from the Local Server would be handled be handled the same as accepting requests as above.

I am sure there are modules/frameworks in CPAN that can handle the network part, especially if the communication between the Remote and Local servers is HTTP based.

  • Comment on Re: Bidirectional Client/Server - to fork or not to fork?

Replies are listed 'Best First'.
Re^2: Bidirectional Client/Server - to fork or not to fork?
by ljamison (Sexton) on Dec 05, 2015 at 04:13 UTC

    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]

[reply]
[d/l]

      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]

In Section Seekers of Perl Wisdom