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

[FR] Listen Callback: Ignore Connection Request #3080

Open
maxsharabayko opened this issue Nov 25, 2024 · 1 comment
Open

[FR] Listen Callback: Ignore Connection Request #3080

maxsharabayko opened this issue Nov 25, 2024 · 1 comment
Labels
[API] Area: Changes in SRT library API Type: Enhancement Indicates new feature requests
Milestone

Comments

@maxsharabayko
Copy link
Collaborator

Need a way for an application to tell SRT to ignore a connection request via the listen callback.
Ignoring means neither accepting, nor rejecting. Just ignore and don't respond.
This would be useful in case a server needs some time to request user's passphrase from its database. The server will extract the required information from the Stream ID, ignore this exact connection request and initiate a database query. A repeated connection request will happen in about 150 ms (AFAIR), this would give some decent time to prepare for it and either accept or reject a connection.

Note other related FRs:

@maxsharabayko maxsharabayko added Type: Enhancement Indicates new feature requests [API] Area: Changes in SRT library API labels Nov 25, 2024
@maxsharabayko maxsharabayko added this to the v1.5.5 milestone Nov 25, 2024
@ethouris
Copy link
Collaborator

This isn't possible in the current implementation. First thing needed to implement this is to ship the connection processing into a separate thread; currently it's happening in the receiver worker thread that cannot be paused for a longer time because the same thread is processing the reading for all other SRT sockets sitting on the same multiplexer.

Another thing is that "ignoring" is not exactly predicted to happen in this protocol. If you don't respond for a request from the caller, the caller will repeateadly send the requests until the timeout is reached. The only sensible approach within the current rules of the protocol is to establish the security interchange connection first, exchange the required data and get the - encrypted of course - token that will be valid for a short time and will be used to authorize the transmission connection.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[API] Area: Changes in SRT library API Type: Enhancement Indicates new feature requests
Projects
None yet
Development

No branches or pull requests

2 participants