From the first screenshot my understanding is that we will display retry to the client front-end to be "transparent" but then from the 2nd screenshot it says "such message should not be passed back ...". Do we want to hide retry operations from client front-end?
transparent means invisible. So we never display this to the client frontend.
https://www.webopedia.com/definitions/transparent/
Also what would be the difference in functions b/w KEYRANGE_SUCCESS and SERVER_NOTRESPONSIBLE? don't they both trigger a retry and update to the client metadata?
SERVER_NOT_RESPONSIBLE triggers a retry.
Retry makes the client send a KEYRANGE msg to the kvserver.
The kvserver will then respond with KEYRANGE_SUCCESS that contains the metadata payload.
Only KEYRANGE_SUCCESS updates the client metadata.
SERVER_NOT_RESPONSIBLE carries no payload, and therefore does not update the client metadata
Thanks! But why can't we skip SERVER_NOT_RESPONSIBLE and KEYRANGE? The server will send a updated metadata KEYRANGE_UPDATE instead of PUT/GET_SUCESS?
There is no "KEYRANGE_UPDATE" in M2 document.
By design, the server never actively notifies the client about the change of the distributed map of the service. The client passively finds out its cached metadata is outdated and sends KEYRANGE to sync up its "metadata map" with the server.
As our project implementation is quite flexible. I can see where your "KEYRANGE_UPDATE" comes from and believe it could work too. Of course, you may need to adjust other parts of the project to adapt to this.
One reason we have
"SERVER_NOT_RESPONSIBLE and KEYRANGE"
over
"KEYRANGE_UPDATE"
is that this could potentially save traffic and reduce communication overhead.
Imagine you have an outdated metadata table, but the keys you put just magically never touch the outdated part of the metadata hashring by coincidence. Then everything still works and you never have to sync the metadata. By this time, the server map may have already changed a few times. Imagine we have 1000 clients connected to the service and how much traffic we can save by having this design.
Thank you Luke for the detailed explaination! It makes perfect sense now!!
Shout out to Luke for consistently helping (us) out!