search

alexkirsz / dispatch

Combine internet connections, increase your download speed
Apache License 2.0
354 stars 28 forks source link

Any planned new features? #3

Open Unknown78 opened 1 year ago

Unknown78 commented 1 year ago

Congrats for the release with Rust as known broadly by it's safe memory handling. As a long time user, I just realized that there's a new release.

There's a few topic from the past repo:

  1. One and only self-hosted Speedify alternative as channel bonding and not the typical ubiquitous load balancing? #82 #89
  2. Automatically restart the dispatch start after fatal crash? #93 #95 #100
  3. Automatically bypass the proxy server for local (intranet) addresses #92
  4. Why drop the support for HTTP? And even further of encrypted proxy? Such as HTTPS Proxy or the new HTTP/3 which is QUIC-based? #94

Were part of those at least already implemented? Any milestone plan?

alexkirsz commented 1 year ago

Thanks for keeping up with the project!

One and only self-hosted Speedify alternative as channel bonding and not the typical ubiquitous load balancing? 82 https://github.com/alexkirsz/dispatch-proxy/issues/89

I have no plans to implement a form of channel bonding for dispatch-proxy. While it's a very interesting feature, it is out of the scope of this tool and would require a more advanced setup: for one, you'd need a remote server with a high bandwidth. A VPN is a much better fit than a proxy for such a feature, but it's also a much more complicated piece of software.

Automatically restart the dispatch start after fatal crash? https://github.com/alexkirsz/dispatch-proxy/issues/93 https://github.com/alexkirsz/dispatch-proxy/issues/95 https://github.com/alexkirsz/dispatch-proxy/issues/100

The new implementation should be much more robust than the old one in that regard. I have added a prompt to open a GitHub issue when a fatal crash occurs, but proxy/connection errors are soft errors and should not affect the lifetime of the program.

Automatically bypass the proxy server for local (intranet) addresses https://github.com/alexkirsz/dispatch-proxy/issues/92

This is definitely implementable in dispatch today. It might work even better as a filter for addresses not to use the proxy on. To add these features on top of dispatch-proxy, I used to recommend a third-party tool such as Proxifier, which lets you describe your proxy rules in much more details. I haven't kept up with the tool but I expect it still works well for this use case.

Why drop the support for HTTP? And even further of encrypted proxy? Such as HTTPS Proxy or the new HTTP/3 which is QUIC-based? https://github.com/alexkirsz/dispatch-proxy/issues/94

HTTP is rarely used nowadays, with most connections going through HTTPS. HTTPS is a black box for dispatch. It is possible to create an HTTPS proxy that can properly dispatch traffic, but it requires dispatch creating a certificate/certificate authority, installing it on the machine, and then acting as a middle-man, decrypting and re-encrypting as data comes through. Charles Proxy does this so their implementation could be used as a model to implement this for dispatch.

HTTP3/QUIC is another beast. It can use UDP, which dispatch-proxy does not support at the moment. However, IIRC the UDP datagrams from QUIC can be sent from any connection by design, which might make it an even better fit for dispatch than HTTP/TCP.

The goal with this rewrite is to provide an alternate, much more performant option to the Node.js dispatch implementation, in a language more amenable to external contributions (the original was written in CoffeeScript). I do not have any clear milestones for this project, except to fill the same niche that the original software occupies, but I will gladly accept external contributions if they are well thought-out and executed.