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

Add srt_shutdown() to the SRT API #478

Open
gegles opened this issue Oct 15, 2018 · 3 comments
Open

Add srt_shutdown() to the SRT API #478

gegles opened this issue Oct 15, 2018 · 3 comments
Labels
[core] Area: Changes in SRT library core Priority: Medium Type: Enhancement Indicates new feature requests
Milestone

Comments

@gegles
Copy link
Contributor

gegles commented Oct 15, 2018

The standard POSIX socket API has a int shutdown(int socket, int how) method that allows "all or part of a full-duplex connection on the socket associated with the file descriptor socket to be shut down".

There is no srt_shutdown() equivalent. Would it be possible to add? Any thoughts as to how I could emulate this for now? Would sending an empty msg do the trick? (haven't tried yet).

This is especially needed/useful when building some kind of proxy to/from SRT to another protocol... I wonder how stransmit deals with that? Shutting down half connections in the right order is critical for proper behavior...

@ethouris
Copy link
Collaborator

Not sure how we would implement this because currently the only way that comes to my mind is to make a shutdown direction flag which will be set by this function so that the transmission in particular direction will be denied (error reported from particular sending or receiving function). That would be the only visible part of it and of course it will not affect the underlying UDP sockets at all, especially that they can be used by multiple SRT sockets at a time, of which not all wanted to be shut down.

Please tell me if making just this thing - set a flag that will enforce error on calls to srt_send* or srt_recv* respectively - and effectively making the socket unusable without closing it, will serve this solution best. It would be also enlightening if you describe more how you're going to use it and what it should help you with better than just closing the socket.

@gegles
Copy link
Contributor Author

gegles commented Oct 23, 2018

I think that would be a great start, but may not be enough. I don't know SRT's inner working well enough to say.

My understanding of how this works (in TCP), is that when one side sends its SHUTDOWN msg, it triggers an EOF on the receiving side. The receiving side can't read anymore after that, but can still send as much data as it wants and only when it decides it is done send its SHUTDOWN message. The initial sender should still be receiving until it gets that final SHUTDOWN... Once both sending/receiving have been shutdown, each side can then call close to properly dispose of the socket...

Is this possible to do with SRT?

@ethouris
Copy link
Collaborator

Everything is possible within the ranges of what userspace software can do, the question is only how much effort.

In this case the trouble is that the information must be sent from the closed sender to the received, without breaking the connection. As this is UDP, this must use some cyclic-sending with confirm-response. I have some ideas how to implement that, but I must consult with the management first. Note of course that this mechanism will only work when both sides are of minimum version that supports it.

@ethouris ethouris added the [core] Area: Changes in SRT library core label Aug 13, 2019
@ethouris ethouris added this to the v1.4.1 milestone Aug 13, 2019
@maxsharabayko maxsharabayko modified the milestones: v1.4.1, v1.4.2 Nov 3, 2019
@maxsharabayko maxsharabayko modified the milestones: v1.5.0, v1.6.0 Dec 27, 2019
@mbakholdina mbakholdina modified the milestones: v1.6.0, Backlog May 26, 2021
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 Priority: Medium Type: Enhancement Indicates new feature requests
Projects
None yet
Development

No branches or pull requests

4 participants