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

Enforce max bitrate on ingest connections #42

Closed
haydenmc opened this issue Nov 27, 2020 · 1 comment · Fixed by #80
Closed

Enforce max bitrate on ingest connections #42

haydenmc opened this issue Nov 27, 2020 · 1 comment · Fixed by #80
Labels
enhancement New feature or request good first issue Good for newcomers ship blocker Need this resolved to ship

Comments

@haydenmc
Copy link
Member

No description provided.

@haydenmc haydenmc added enhancement New feature or request ship blocker Need this resolved to ship labels Nov 30, 2020
@danstiner danstiner added the good first issue Good for newcomers label Dec 1, 2020
@haydenmc
Copy link
Member Author

haydenmc commented Feb 9, 2021

Average bitrate is now calculated by #60 - just a matter of kicking off folks who go over some configured absolute maximum.

stats.RollingAverageBitrateBps = (bytesReceived * 8) / (ROLLING_SIZE_AVERAGE_MS / 1000.0f);

haydenmc added a commit that referenced this issue Feb 15, 2021
Fixes #42

This change introduces the `FTL_MAX_ALLOWED_BITS_PER_SECOND` configuration, providing a means of restricting the maximum bandwidth any given stream is allowed to consume before it is kicked off the server.

There are a few other changes in this payload as well:
- `FtlControlConnection::FtlResponseCode` enum is introduced (from [ftl-sdk](https://github.com/microsoft/ftl-sdk/blob/d0c8469f66806b5ea738d607f7d2b000af8b1129/libftl/ftl_private.h#L365-L385)), and is now referenced instead of hard-coded string values throughout `FtlControlConnection`.
- Better locking mechanisms around `NetworkSocketConnectionTransport`'s stopping procedure to prevent getting into a deadlocked state if the server is trying to stop a stream around the same time a client is.

An issue #79 was also discovered where pending writes to a `NetworkSocketConnectionTransport` aren't flushed when the connection is stopped, preventing us from communicating the response code to the client before closing the connection.

Worth noting as well is that [OBS behavior](https://github.com/obsproject/obs-studio/blob/92a7c12909556d8b64e1ea68a80a255b46d672cf/plugins/obs-outputs/ftl-stream.c#L888-L892) when a stream connection is terminated (even with a valid error response) is to reconnect every ten seconds, regardless of the error received. The net user result is OBS transparently trying to reconnect in a loop despite the server kicking them off for excessive bandwidth use.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers ship blocker Need this resolved to ship
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants