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

Fixed: reject RID for id=0 if not rendezvous #2562

Merged
merged 1 commit into from Dec 6, 2022

Conversation

ethouris
Copy link
Collaborator

@ethouris ethouris commented Dec 1, 2022

Fixes #2557

The problem: The "rendezvous queue" has been serving in UDT for actually two purposes: beside rendezvous, it was also used to handle caller sockets in non-blocking mode (blocking mode for caller sockets' handling was executed completely in a loop in CUDT::startConnect). This was a procedure used for the following situations in response to an incoming handshake packet:

  1. When a packet is coming with a given target Socket ID. In this case it should find and return such a socket, which is:
    • a registered earlier caller socket that started the connection request
    • a rendezvous socket which's id is known because at least one WAVEAHAND handshake has been received already
  2. When a packet is coming with ID=0, which means it's a connection request, then:
    • if to the address, to which the handshake packet has come, there is a listener bound, this has been handled already before even looking into the rendezvous queue, which means, it wouldn't be a case here at all
    • if there is a need to search for a socket bound to that address that is expecting a contact, and it wasn't the listener case, then it can only be a rendezvous connection request looking for the first contact

This means: in order to handle all these 3 cases, the lookup in the rendezvous queue in case when the incoming ID is 0 should succeed only in case when the found socket is rendezvous.

BTW. Further research: it shouldn't be allowed to bind two sockets to the same address if any of these sockets is rendezvous. The rendezvous sockets should have a nonshareable binding regardless of the value of the SRTO_REUSEADDR option (might be that this option should be set automatically to false when setting rendezvous, and setting rendezvous should not be allowed on a socket that already has a shared binding).

@ethouris ethouris added Type: Bug Indicates an unexpected problem or unintended behavior [core] Area: Changes in SRT library core labels Dec 1, 2022
@maxsharabayko maxsharabayko added this to the v1.6.0 milestone Dec 1, 2022
@maxsharabayko maxsharabayko merged commit 4090b25 into Haivision:master Dec 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[core] Area: Changes in SRT library core Type: Bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUG] Caller should not connect to another Caller
2 participants