I apologize for the lack of clarification in my original question. Let me explain a bit further and clarify to get rid of any confusion:
This workflow will be used in a library environment. Our library is migrating to Koha, which is built on Perl and MySQL. MY task is to interface Koha (which will be hosted by a third party off-site. For the remainder of this reply I'll identify Koha as the ILS - integrated library system - and our local server called EMS) with a local server on-site (EMS) which runs a machine we use to store and pick books from (read as replacement for bookshelves).
As an example, a person would log in to the Koha library catalog and "Place Hold" on something. When they click "Place Hold" that would trigger a request file (request.pl) and collect contextual information regarding the request through MySQL extraction then relay that information via socket to EMS for the request to be completed.
EMS has been designed by a third-party to accept Socket (SOCK_STREAM) connections over TCP protocol. EMS is set up to process data in the form of single line "messages". A robust ACK/NAK mechanism is in place to guarantee success or failure of a message which is handled by EMS.
Parts of the actual interface connection are confidential, however I will try to answer the posed questions as best I can in hopes it will assist with a solid solution.
To answer NetWallah's questions:
- The EMS server handles incoming requests in a FIFO manner. Both sides (ILS and EMS) are to have a SEND and RECEIVE function. The EMS side already has both configured but it is up to me to create them for the ILS side.
- "The SEND task begins by attempting to connect to a socket. Once a connection is established then messages can be sent. After a message is sent, SEND should wait for an acknowledgement before sending the next message. If any errors occur, the socket should be closed and attempt to establish a new connection (on the same IP:Port). If the connection fails, SEND should periodically attempt to establish a connection."
-
"The RECEIVE task begins by creating a socket, binding to the socket and listening for a connection. After receiving a valid connection request RECEIVE will accept the connection and can begin receiving/responding to messages. RECEIVE will be responsible for preserving the message before sending the acknowledgement. If the connection is lost, RECEIVE should return to listening for a socket connection."
- Currently, I have been trying to work with 8 separate Perl files (messages), however all 8 could potentially be combined into one if I am able to access the necessary sub as needed.
- Though it would not necessarily happen constantly, it is more likely than not that more than one message may be triggered simultaneously.
- All 8 messages would send their data to one end point (via IP Address) on only one port.
- The receiving end (EMS) also has a SEND and RECEIVE task.
- For the EMS SEND task, if we make an on-site local change, EMS will use the SEND task to notify ILS of the update. (The change is made locally, SEND task opens a socket, sends a message to ILS to notify of an update and waits for a response if the message was accepted/rejected then closes the socket.
- For the EMS RECEIVE task, ILS opens a socket, sends a request message for an item to EMS, EMS sends a response message back to ILS that the request message was accepted/rejected, then EMS sends a status message to ILS telling ILS if the item is available or not, ILS sends a response that the status message was accepted/rejected, then closes the socket.
- And I'm impressed that you guessed right about it being message based!
- Lastly (to give a clearer picture), when the ILS RECEIVE task is active, it will make a SQL query to UPDATE the database.
I hope that I provided enough clarification to clear up the confusion!