Downloads continue after PeerConnection closes

[bemasc]

I have been testing the copypaste sample app with CHURN enabled, over the public internet, to an endpoint that is also running a webserver. The client then requests a large file on this webserver.

The PeerConnection often fails due to ICE disconnection (presumably related to CHURN), and both sides indicate that the connection is "stopped" in the UI. However, the server continues to download the file until it completes and the webserver terminates the transfer.

Setting breakpoints showed strange behavior:

• In RtcToNet
  • `this.sendOnSocket_ is never called
  • but its returned Promise fires over and over (updating the UI's reported bytes transferred), each time with a different 4096-byte ArrayBuffer
• In PoolChannel
  • this.dc_.onceClosed has fired
  • but this.state_ is 0 (OPEN), and this.onceClosed has not fired

The former suggests a problem with setPaused and a huge backlog of promises. The latter suggests a logic error in PoolChannel. More investigation is needed.

[bemasc]

The observed issue with PoolChannel seems to have been due to testing with an old version of the code. With the latest from dev branch this no longer happens, but some version of the issue persists: downloads still appear to continue for some time after the PeerConnection closes.

Breakpoint debugging shows that data channel closing triggers the expect sequence of close calls, and RtcToNet logs "discarded session" ... but "bytes sent to remote party" in the UI continues to increase for tens of megabytes. It's now clear that this is the known issue of pathological web worker scheduling on ultra-fast downloads: in the time that it takes to hit DataChannel's 250 KB overflow threshold, and deliver the pause message upstream, 40-60 MB can be delivered to the browser.

The best short-term mitigation I know of to this is to make backpressure reaction time faster: #1474

[bemasc]

After some investigation, backpressure is already about as fast as we know how to make it without a change to freedom, such as freedomjs/freedom#255.

[trevj]

Question: did you try having SocksToRtc.stopResources_ call this.tcpConnection_.dataFromSocketQueue.claerHandler();:
https://github.com/uProxy/uproxy-lib/blob/dev/src/socks-to-rtc/socks-to-rtc.ts#L358

[bemasc]

Effectively, yes, I landed that change last week: https://github.com/uProxy/uproxy-lib/pull/167/files

Indeed, that seems to make this problem much less severe, so I'll mark it as closed.

[trevj]

Apologies, I totally forgot I reviewed just this :-)