Maybe an option to choose an alternative controller via socket options (linux and windows offer alternatives) would make sense in some situations.
Default TCP congestion control is Reno, but Linux uses Cubic, increased initial CWND and all the other modern modifications. CDNs have their own proprietary congestion controls that are arguably better, but Google has already pushed its own congestion control (BBR) into Linux, so it is just a matter of time until it becomes new default. There is no reason to tamper with these settings unless you are operating Netflix/YouTube, some sort of CDN or unusual (satellite) link.
> Maybe an option to choose an alternative controller via socket options (linux and windows offer alternatives) would make sense in some situations.
Only the server congestion control matters. Client simply acknowledges whatever it receives as soon as possible and waits for more data.
What kind of logic should this app use to determine how many external addresses are actually available in the case of IPv4? As you say, it is more "tcp fair" to have only one TCP connection per client/server relationship in normal cases.
Just some random thoughts. Apologies if it's difficult to follow. I can reply to any questions if anything is confusing.
Opening one connection per interface is still a violation of TCP design. Look into MPTCP RFCs. It is specifically designed to use multiple connections as if you had only one. Developers of the standard made sure you don't have any advantage compared to someone using only one connection.
Two connections over two different interfaces will meet somewhere on the bottleneck near the mirror so you still have the advantage of multiple TCP connections.
Sure MPTCP is not ready yet, but multipath QUIC will be deployed by the end of this year so all your Chrome downloads from google drive will utilize multiple connections.
Normally I'd say that accelerators are abusive, but being forced to download hours of video in near-realtime is such a pisstake that I'm willing to make an exception (the alternative is to download multiple videos in parallel, which is even more abusive, yet less frowned upon).
I use a Chrome extension, though, Chrono. It's been very good.
I'm still looking for something that can do both.
Feature lists should be feature lists. On open source projects especially, I've seen "soon" take weeks or months. Move features that aren't features into a "upcoming" or "planned" block or make an issue, but don't list it as a feature when it isn't implemented.
If they want to mix the feature list with the roadmap or keep them separate, it doesn't really matter. I assume the incomplete feature list is precisely the reason for the alpha label.
I may be reading too much in between the lines, but your comment sounds like "I don't want to hear about software until it is finished. If it's not ready for prime time, keep it on your hard drive."
IMO change this description, it's rather strange...
See https://en.wikipedia.org/wiki/List_of_Unicode_characters#Blo...
