Desired client response upon no reply from server to confirming message

[NotionCommotion]

I am building a client which will continuously attempt to connect to a server of a given IP.  After connected, messages will be sent and received via JSON RPC over TCP/IP socket streams.

 

If the client sends a confirming JSON RPC message to the server, and the client does not receive a response within the specified time period, what should the client do?

 

Should the client break the connection, and then go back to attempting to connect?  Should it do it after the first incident, or should it be more tolerant and reattempt the request using the same message id several times?  If so, are there rules of thumb how many times?

 

http://json-rpc.org/wiki/specification 1.0 section 2.1 JSON-RPC over stream connections states the following.  What does this mean?  JSONRPC Specification 2.0 is silent on this issue.
 

Closing the connection between peers must raise an exception for all unanswered requests on each peer. Non-valid requests or responses must result in closing the connection.

 

Thanks

[requinix]

Keep-Alive is potentially a relevant concept here: messages are periodically, on the order of seconds or even minutes, exchanged between the hosts simply to confirm that both ends are still connected and talking to each other. If you're normally exchanging messages constantly then you don't need this.

 

TCP already has a mechanism to re-send messages so you don't need to duplicate that particular aspect. What you need to worry about is whether the recipient is in the process of responding; with your cross-client messages you also need to think about whether your connection to the server is fine but its connection to the other client has been broken.

 

I would use Keep-Alive (eg, ping/pong messages) between each client and server. If a request is lost then either (a) the next Keep-Alive will fail and the connection should be severed, or (b) the Keep-Alive continues and you... well, you just keep waiting (unless you want to add a sort of timeout/TTL concept to your messages). A Keep-Alive can also provide a way for the server to track which clients are still connected, so if a cross-client message needs to be sent and the recipient is down then the server can immediately reply, or maybe spool the message waiting for the problematic client to reconnect.

 

Of course TCP has Keep-Alive too, so you don't necessarily need your own version, but if it's not much overhead to implement then I like the idea of knowing not just that the connection is working but that the applications on either end are still working too (and not, say, stuck in an infinite loop somewhere). If the peers are potentially doing long-running operations then this is probably not a good idea, because regardless of what React hides under the hood PHP is still single-threaded.

 

 

Regarding the excerpt, keep in mind that JSON-RPC is designed as an underlying transport mechanism for the exchange of messages. A read-through of the OSI model will help. Technically OSI deals with the actual underlying networking principles, and everything you're doing is part of the application layer, however since you're working with a communication protocol you can draw analogies between OSI and what you're working with.

 

JSON-RPC is mostly the transport layer-side of things. It deals with the message format and how they're exchanged between peers. That part of the spec is talking about what the layer should do when the connection is severed, and is necessary not just because closed connections can happen but because JSON-RPC isn't actually the transport layer (TCP is) and is thus susceptible to what the real layer does.

 

To communicate the connection problem with the higher layers (ie, your application) JSON-RPC 1.0 mentions exceptions. These aren't "errors" that it otherwise mentions least of all because errors are exchanged between peers and thus are useless if the connection is closed. Thus I assume they mean that an exception is raised towards the application; it had used JSON-RPC to send a request and thus it needs to receive something as a response. Ideally each request sent would have logic for a response and logic for an exception, for example

try {
	$response = $this->transport->sendRequest($request);
	// handle response
} catch (\TransportException $te) {
	// handle exception
}

AJAX works similarly, with the technical advantage that is uses an optional error callback instead of forcing a stack-unravelling exception. You could (and with React, probably would) do the same.

 

The second half of that excerpt deals with an unusual situation where the client and/or server can't understand each other, so closing and re-establishing the connection brings them back to a hypothetical handshake stage (which JSON-RPC doesn't actually have...) - or in other words is the "turn it off and on again and see" approach.