mdsplus
mdsplus copied to clipboard
mdsip should keep the connection to the client for async requests
Currently the implementation of async requests as done by ServerShr is as follows:
- The client binds a port in a given PORT_PANGE and listens on it for a reply connection by the server.
- It sends the port number together with the task to the server.
- The server replies with the status indicating if the task will be executed.
- The client's connection to the server closes and it waits for a reply on the reply port.
- After completing the task (much later) the server attempts to connect to the reply port sent by the client.
- Client receives the relpy and moves on.
This implementation has two major limitations that I hope to resolve:
- Communication cannot happen because the server cannot connect to the suggested port.
- firewall: port is not open / port range is exhausted
- ip routing: If the preferred outgoing IP of the server is different from the ip the client sent its request, the acceptance of the connection fails
- tunneling: through port forwarding it was possible for the client to reach the server but the server has hard time figuring out how to reach the client.
- No active connection to server:
- If the server cannot reply, there is no way of telling if it simply cannot reach the client, it died, it is still computing the request.
- no way of sending an authorized cancellation (only the client who issued the task should be able to cancel it)
- if the client closes the connection the server can cancel the task (does not apply to tasks issued with /nowait)
Possible improvements:
- Quick and dirty: Check whether the server should connect to the client right away and client should wait for this connection (if server version is newer than version of change) before returning. Client should return error (e.g. SERVER-E-NO_REPLY) if server does not connect within connection_timeout period.
- If and only if both server and client satisfy version requirement: Async requests require dedicated connection. MDSIP should serve on port and keep established connection for reply. Client should use current socket as reply channel. Both sides will close the reply channel if either a reply has been sent/received or the connection dies (here we have room for a Heartbeat). we could add a flag that controls if the server should abort or continue task even if the connection breaks prematurely. major benefit: no need for a dedicated port range to be opened in firewall.
Have any of these improvements been made? Are they still relevant?