Pending writes are not flushed when a connection is closed #79
Labels
bug
Something isn't working
Comments
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.
|
I thought surely there must be a flush call to make sure the bytes at least get out onto the wire... No such luck! This article covers the relevant bits pretty well: https://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If you call
NetworkSocketConnectionTransport::Write(...)and then immediatelyNetworkSocketConnectionTransport::Stop(), there's a good chance that the bytes you've just queued up to be written will not make it across the wire.This is particularly unfortunate when you're trying to tell the client why you're about to disconnect them!
We ought to add a way to either synchronously write to a
ConnectionTransport, or flush writes when callingConnectionTransport::Stop().The text was updated successfully, but these errors were encountered: