More details on how client requests should be initiated

[rfairley]

To elaborate a bit more on what I think we need to add to client, noted as one of the items in: https://github.com/zzlyn/ConsensusVisualization/pull/69#issue-366723281

adding a client node, and implementing the proper logic for trying the primary first, then multicasting if a timeout is reached, and the 2f+1 replies to the client (details of this are in the paper in section 4.1) (Robert to open issue, Daniel to look into)

To issue a clientRequest right now, a user clicks on one of the PBFT servers, clicks the "Request" button, which calls pbft.clientRequest. This will then enqueue a client request on all the servers in queuedClientRequests, and the primary will begin execution of the first message in the queue. Once the message has been committed, nodes remove the message from the queue, indicating the request has been processed, and the server no longer needs to have a view change alarm.

This is what I think the client initiation should look like:

The user clicks on the client node (the one drawn at the top left), and clicks a "Request" button. This will call a pbft.clientRequest which will call a function called sendClientRequest (which has yet to be implemented), which sends a message of type MESSAGE_TYPE.CLIENT_REQUEST to what the client believes is the primary. I think the client "guesses" what the primary is based on the CLIENT_REPLY messages it has received in the past. If it has not received any CLIENT_REPLY messages before that would allow it to guess the view, the client can assume the primary is node 0.

If the message was not executed and the client times out after not receiving a CLIENT_REPLY for the request (e.g. if the node it sent the CLIENT_REQUEST message to was not the primary), it will then send a MESSAGE_TYPE.CLIENT_REQUEST to all of the nodes. This is described in the second-last paragraph of section 4.1 in the paper. This requires implementing a request timeout on the client. If we wanted to keep it simple as a first step, we can have the client always send the CLIENT_REQUEST messages to all nodes, and not do a point-to-point message to the primary.

Upon receiving MESSAGE_TYPE.CLIENT_REQUEST, the function handleClientRequestRequest should enqueue the request from the client in the same way as is currently done in the code.

So pbft.clientRequest would be altered to call sendClientRequest, which sends a MESSAGE_TYPE.REQUEST to the primary or multicasts to all of the nodes. sendClientRequest would need to be added and implemented. handleClientRequest would need to be implemented, as described above.

[rfairley]

Closing, as we added a client in #81