trevj

FYI, here is the commit that seemed to fix Chrome: https://chromium.googlesource.com/external/webrtc.git/+/e8386d21992b6683b6fadd315ea631875b4256fb

I dug into build-webrtc itself, too. Since the patch for Chrome essentially added a call to `SignalReadyToSend`, this seems relevant: - https://chromium.googlesource.com/external/webrtc.git/+/master/webrtc/api/datachannel.cc#242 We might be able to hack a solution...

This also seems relevant: https://chromium.googlesource.com/external/webrtc.git/+/master/webrtc/media/sctp/sctpdataengine.cc#368 `Fired on our I/O thread.` - What if there **is** no I/O thread on Node.js? Some `printf`s might help us answer that :-)

And where that callback is registered in `usrsctplib`: https://github.com/sctplab/usrsctp/blob/master/usrsctplib/user_socket.c#L1410 Again, we might even hack the callback at that level, avoid the whole I/O thread thing.

Nice find! I ran this command: ``` bash UV_THREADPOOL_SIZE=25 time node examples/stress.js ``` I didn't see an improvement but as discussed let's come up with a test where we can...

Loading and connected animations: https://github.com/uProxy/uproxy/pull/2850

TODO: * server description (location) * server "strength" * delete server

I'll take a look at this before next week's release cycle starts up.

So, on my system, If I disable these two tests then all is well: - connect to many different servers in parallel - attempt to connect to a nonexistent DNS...

@samascience This sounds related to https://github.com/Jigsaw-Code/outline-server/issues/244 which has a number of suggestions on how to run without Docker.