-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
REPLY with flexible destination #40
Comments
For enhanced clarity, we might:
How to reply to a client:
In both cases 1) and 2) above, we have (again) the burden of how to couple the individual request sent by a given client with a given request ID, with the final reply referring to it (the client computes the response times based on that), i.e., using a per-request UUID. At the moment, requests IDs are "reassigned" by each node executing a current FORWARD/MULTI_FORWARD, but they could not even be used earlier, because each client was reusing anyway the same request ID sequences. On a related note, probably requests that are forwarded in a fire-and-forget way don't strictly need a reassignment of their ID, and they might bring forward the same ID as sent by the client (which might be what the client expects to see anyway in a final REPLY to couple it with the initial request message). |
-) Optionally change the destination of a REPLY. This is useful for DAG topologies with no-reply-back. It will be the last node of the chain to reply to the client
-) Optionally exclude a final REPLY for fire-and-forget use-case, even in the case of FORWARD messages. In the latter case, it is needed a mechanism to join a forked stream without relying on the node that called FORWARD
(however, we probably want to reply to the client nonetheless).
A first step may be converting REPLY to a "special" FORWARD case.
The text was updated successfully, but these errors were encountered: