Video stream interruption

[uniqueandriy]

Recently I ran into a bit of a puzzle while working on one of my projects. I've been working on adding a typical file streaming (with ranges support, cache control, etc.), and decided to test it out with a short 5-minute video. The initial playback was just fine, but I noticed Chrome was repeatedly reconnecting to get data ranges from the server.

After some debugging, I discovered that the connection was getting aborted, and it seemed like the browser wasn't the one causing it. Chrome kept thinking the connection was fine even when the server called the .onAborted callback, leading to the net::ERR CONTENT LENGTH MISMATCH error in the console. As a result, sometimes playback was interrupted altogether.

To make sure I hadn't messed up something, I decided to compare with the video streaming example, to which I added corking and a Content-Length header. The interruptions persisted, here're the logs:

Video size is: 69856219 bytes
Listening to port 4000
Stream was opened, openStreams: 1
Stream was closed, openStreams: 0
1: 30.776ms
Stream was opened, openStreams: 1
Stream was closed, openStreams: 0
2: 34.620s
Stream was opened, openStreams: 1
Stream was closed, openStreams: 0
3: 27.879s
Stream was opened, openStreams: 1
Stream was closed, openStreams: 0
4: 36.760s
Stream was opened, openStreams: 1
Stream was closed, openStreams: 0
5: 14.551s

Got me wondering, why is this happening? Typically, when you serve such a video from something like nginx, a single connection stays active until the stream ends. Even if there are rare reconnections, the browser figures out right away the connection is closed.

P.S.: uWebSockets.js v20.31.0, Node.js v18.12.1, Windows 10 Pro (Build 19041)

[kartikk221]

@uniqueandriy It sounds like you are performing incorrect backpressure handling.
See Issue: #961 for the discussion.

With that said, If you wrote your code according to the video streaming example than this section of code may be problematic: https://github.com/uNetworking/uWebSockets.js/blob/ecd89ce24ae98fd3936e3387ccd315615d1eee37/examples/VideoStreamer.js#L41C7-L81

Essentially, this code consumes each chunk from the readStream with the 'data' event which will gradually emit all chunks until done. As you are serving each of these chunks, some may not be sent due to backpressue in which case it implements the backpressure handling with res.onWritable(). The problem is that you cannot bind res.onWritable() more than one time throughout the whole lifecycle of a request. So what's likely happening is that the first time a chunk encounters backpressure, It retries successfully. The second time a chunk encounters backpressure, It is unable to properly retry the second chunk as the second res.onWritable() handler being assigned will not work properly.

As discussed in the issue above, I implemented a fix for this in hyper-express with proper backpressure handling recently, so feel free to put together a very quick demo to stream your large video file using hyper-express to see If that may resolve your issue.

[porsager]

Interesting.

Yeah, I'm not denying the issue at all, I'm very curious since I'd obviously like to catch it in my own setup if there's something to it.

About tryRest (updated), we can just remove all the arguments now that it's in scope ;)

[uasan]

perhaps the error only appears using SSL, you tested without SSL or vice versa

[porsager]

That's a good point@uasan! I also have another issue myself with chunked transfers and SSL. Just need to find the time to describe and make a reproducible case.

[uniqueandriy]

Decided to try out the sample on a Fedora machine, which happens to have an older version of Node.js installed - v16.18.1. And, despite the variations in platform and module versions, the behavior remains the same.

Just to add: all of the tests were conducted on a server without SSL, on the same device and without any deliberate interference with the connections.

[uasan]

Yes, I reproduced this, for some reason the connection closes, in Chrome, in other browsers everything is fine