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

fix: Properly wait for client to accept connection #1058

Draft
wants to merge 3 commits into
base: development
Choose a base branch
from

Conversation

WispyMouse
Copy link
Collaborator

Before: When a host requests a client to start a connection, clients were using AcceptConnection as if it were synchronous. In the event that a host opens a connection sufficiently faster than a client, the client may be messaged with the "READY" before it has actually accepted the remote connection. The result is that the client fails to receive the packet, does not respond to the host's connection attempt, and thus the connection cannot be made.

Now: Subscribing to the AddNotifyPeerConnectionEstablished message and handling the results in there allows the client to properly time when they're ready for communication.

Internal_OpenConnection has been split into synchronous part (Internal_StartOpenIncomingConnection) and asynchronous part (Internal_ContinueOpenOutgoingConnection).

Warning

This has barely been tested at the point where this is put up to PR. This pr is in draft to start with until it has been tested. Please give feedback on the approach and naming conventions. Please provide scenarios you want to see covered in tests, if you can think of anything in particular.
The testing process for this will include:

#EOS-2255

Before: When a host requests a client to start a connection, clients were using `AcceptConnection` as if it were synchronous. In the event that a host opens a connection sufficiently faster than a client, the client may be messaged with the "READY" before it has actually accepted the remote connection. The result is that the client fails to receive the packet, does not respond to the host's connection attempt, and thus the connection cannot be made.

Now: Subscribing to the `AddNotifyPeerConnectionEstablished` message and handling the results in there allows the client to properly time when they're ready for communication.

`Internal_OpenConnection` has been split into synchronous part (`Internal_StartOpenIncomingConnection`) and asynchronous part (`Internal_ContinueOpenOutgoingConnection`).
@WispyMouse WispyMouse added fix PR contains a fix. tracked This issue has a corresponding task in our internal bug tracking system labels Dec 14, 2024
@WispyMouse WispyMouse self-assigned this Dec 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fix PR contains a fix. tracked This issue has a corresponding task in our internal bug tracking system
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants