Skip to content
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

Refactor SDP/gateway messages to have a top-level msgID for correlation #154

Open
DavidS-ovm opened this issue Nov 9, 2023 · 0 comments
Assignees
Milestone

Comments

@DavidS-ovm
Copy link
Contributor

DavidS-ovm commented Nov 9, 2023

With the improved strictness of message-association in the sdp-go client, uncorrelated Error messages (e.g. when query.Type == "" in https://github.com/overmindtech/gateway/blob/09197e492f4cb5c99439dd33356308bf0aa46df0/gateway/request_session.go#L510-L517) have to abort all running requests, as there is no way to tag a specific query at the moment. Note that sdp-go doesn't abort either, instead hanging until the deadline!

At the same time, when sending a bunch of queries, the only way to detect all of them finishing is to wait for a GatewayResponse_Status with no active responders. This is error and race prone and does not allow for fully parallel querying either.

To solve this, add a top-level MsgID property to GatewayRequest and GatewayResponse that all clients fill in and can use on responses to multiplex responses back to the specific request that caused it. This can be a net-new addition and individual sdp protocol users (clients and servers) can start sending at processing this message id independently as long as they can handle empty IDs. Once everything is in plac, the client can make use of the new capability for finegrained request status processing.

@DavidS-ovm DavidS-ovm self-assigned this Nov 9, 2023
@DavidS-ovm DavidS-ovm added this to the SDPv2 milestone Feb 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant