GIP: RPC fault tolerant algorithm with distributed ACK

[prdn]

Status

[2017-06-22] Work In Progress

Problem

• A Client c sends a request r0 for a service offered by N different Servers
• Server s handles r0 but network between c and s becomes unavailable before s is able to send the result of the request back to c.
• c wants to know if r0 was completed or not by s and decide whether retry (in case r0 failed) with another Server y or get the result in case of success.

Proposal

• s writes to the DHT (using put feature) the result p (success/payload or error) of r0. The hash of the request-id rid is used as identifier
• c waits until r0 times out and searches the DHT (using get feature) for rid
• Case A: c is able to retrieve p. If r was successful then c does nothing. If r was unsuccessful c then may decide to resubmit
• Case B: c is NOT able to retrieve p. Either s crashed before being able to write p to the DHT or also DHT reachability for s is compromised. c notifies the application to manually inspect r and its result.
• s may crypto-sign p to prove the authenticity

Advantages

• Use DHT storage as an asynchronous, fault tolerant and redundant system.

Notes

• Creating grenache services for ACK storage works too but it's transport-implementation specific

[erubboli-bfx]

are there any cons? what about DHT memory usage, is it something to take into account ?

[prdn]

@erubboli-bfx I imagine this as an opt-in feature that you can enable on a per-request basis. I would not include in the main code base (at least for nodejs) but as a plugin for nodejs-base. Same for ruby.
It should be used for sensible operations not everything. Imagine to have a worker that sends a tx to the blockchain. If you have an hack and the network between client and server has an issue during tx preparation/broadcast, you can still recover the result using all builtin features of DHT.