You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although I can workaround it by generating a random UUID and both server and client agree to use that as a universal identifier, are there any better way to do this in tarpc without having to manually resolve the data context (not tracing context) all the time?
Right now, I use this to solve the client retry issue because the client can disconnect intermittently. Once the "key agreement" is established, I can replay the client messages logically so that we can resume on working. However, this also means the RPC methods must not have any side effect (i.e. idempotent)
The text was updated successfully, but these errors were encountered:
Hi! Sorry, I missed this earlier. Thanks for filing.
Generally, I would envision the client being identified by a load balancing layer, part of the transport (which tarpc doesn't bake in). That would kind of go hand-in-hand with client reconnect behavior.
Hi! Sorry, I missed this earlier. Thanks for filing.
Generally, I would envision the client being identified by a load balancing layer, part of the transport (which tarpc doesn't bake in). That would kind of go hand-in-hand with client reconnect behavior.
Yeah, I just realized what I expressed about the "universal identifier" is just some kind of stateless construct, such as a cookie or a bearer token. To think further, we will need to do session management in tarpc.
Although I can workaround it by generating a random UUID and both server and client agree to use that as a universal identifier, are there any better way to do this in tarpc without having to manually resolve the data context (not tracing context) all the time?
Right now, I use this to solve the client retry issue because the client can disconnect intermittently. Once the "key agreement" is established, I can replay the client messages logically so that we can resume on working. However, this also means the RPC methods must not have any side effect (i.e. idempotent)
The text was updated successfully, but these errors were encountered: