* Run the command `npm install -g dispatch-proxy` as a power user and press Enter. It will install the `dispatch` command-line utility.
2) STARTING AN HTTP PROXY
* To quickly start an HTTP proxy, run `dispatch start --http`.
* The program will print the proxy address and port (by default localhost:8080) as well as the list of local addresses the program will be dispatching requests to.
* Configure your system to use the combination address:port as an HTTP proxy.
3) LISTING ALL AVAILABLE NETWORK INTERFACES
* To list all available network interfaces, run `dispatch list`
* Each available network interface will be printed with a list of addresses.
* Right now, the dispatch utility only supports IPv4 addresses.
* If an address is marked to be "internal", then you won't be able to use it to connect to the internet.
Great job. I am not too technical so pardon my question. Can multiple 3G connections be combined or have a 'random selector'/failover.
So where I live (you can make a guess), mobile connectivity is not the most reliable in the world. So for instance, POSs are not reliable since one network will always fail. With this, could we use multiple SIMs thereby making them more reliable?
BTW, have you seen BRCK http://www.brck.com/specifications/? Seems to have the sort of the same concept although I think yours is combining speed vs. having a fail-over system for internet access.
This is a neat idea. Does anyone know if it's possible to achieve a similar effect natively on Linux ? i.e. make the linux network stack load-balance all outgoing connections to all available interfaces ?
The Linux bonding driver provides a method for aggregating multiple network interfaces into a single logical "bonded" interface. The behavior of the bonded interfaces depends on the mode. Generally speaking, modes provide either hot standby or load balancing services. Additionally, link integrity monitoring may be performed.
Bonded Interfaces operate at a lower level. There are many different "bonding modes" in the Linux Kernel. None of them would allow you to present a single "bonded" interface across multiple independent network interfaces where each interface belongs to a separate network. Case in point: You cannot "bond" two interfaces where one is connected to a cable modem and the other a DSL modem. Typically (in most configurations) a bonded interface receives one IP.
You can, but you need to make two tunnels (GRE, IPIP or whatever you fancy) over those two uplinks, then create a bond over those - if that's technically possible (I believe interfaces must at least have equal MTUs, can't remember what other requirements are). Obviously, this requires configuration on both sides of the bond.
And, ahem, correct load balancing over bonded interfaces is not trivial as it may seem (although, usually it's more likely you'll be able to distribute approximately evenly than not)
I'm pretty sure you can do this sort of load balancing on Linux without having to install any extra software, at the IP level, with the "ip rule" and "iptables" commands.
It is possible to do per-packet load sharing in Linux as the link above suggests. Both links need to be able to source traffic using the same IP address, i.e. you can't mix comcast and dsl. The way to get around this is to have an upstream router that will source your traffic from the same IP address:
client - routerD --upstream1---routerU -- the internets
|-------upstream2-----|
The iptables statistic module with random mode seems to work better than nth packet.
Keep in mind PPS load sharing is not the most effective way to utilize links as retransmissions will slow things down. Now if you have two links to the same provider it's probably OK. You can even buy a bonded connection from most providers where they do all of this for you.
ECMP is only useful if you have a large number of clients. So you can do PPS load sharing, knowing full well that it's going to be slower than a single link some percentage of the time or just buy a faster connection.
If everybody follows this advice, then the isp has to/will be increasing the price of the faster connection. And this is especially true in US, since there is virtually no real competition for isp.
I have used dual wan routers that do this: While speed can go up, and bandwidth certainly does, the latency variance makes many games unplayable, and really throws some video and audio streaming apps for a loop.
I'd love to see a write up how well this does stuff that is sensitive to latency and changing network conditions, beyond simple web surfing.
Nice. Interesting that you're doing it at the userland level and balancing across IP address and not interfaces. I may find a use for this. (On a network rate limited by IP address, not per physical connection or per MAC address, and allows me to use multiple IPs. Go figure.)
I haven't set this up myself, but I think the iptables method for doing this is `nexthop via`. Never found any great documentation, but this seems to describe it: http://lartc.org/howto/lartc.rpdb.multiple-links.html
I think the iptables method balances across interfaces, not IPs. But I want to balance across IP aliases (multiple IPs, same interface). And I'm usually on a Mac. So I may see if dispatch-proxy is a better choice.
If anyone is interested in my particularly strange use case, this seems to work:
$ sudo ifconfig en0 alias 192.168.2.210 255.255.255.0
$ sudo ifconfig en0 alias 192.168.2.211 255.255.255.0
$ sudo ifconfig en0 alias 192.168.2.212 255.255.255.0
$ dispatch start
SOCKS5 server started on localhost:1080
Dispatching to addresses 192.168.2.28@1, 192.168.2.210@1, 192.168.2.211@1, 192.168.2.213@1
Also the link I mentioned is different from what other people have mentioned in this thread. It's not interface bonding or TCP multipath. It is actually similar to dispatch-proxy, it balances TCP connections across interfaces as far as I can tell.
As far as I know this is a DIY solution for what companies sell as a "bonded" internet connection..?
I spent weeks trying to get a reliable setup for streaming concerts in HD from all varieties of spotty WiFi and 4G hotspots. The streaming server wouldn't accept packets that seemed to come from totally different IP addresses so there had to be an intermediate proxy server in the cloud that would re-assemble the data from my various connections.
I was able to get it working and it would have been great for normal Internet usage, but I never found a reliable system for streaming. That was about a year and a half ago. I would love to see this technology mature to the point where it worked well for streaming.
From a quick glance over the code, it just seem to proxy TCP streams over one channel or another, probabilistically. Most trivial form of load balancing possible.
This approach certainly won't work for typical media streaming, as it usually uses a single connection. Particularly, because streaming over multiple connections is tricky because as they don't guarantee delivery order, so you'll probably get your packets "scrambled" and will have to reorder them by yourself (implementing your own flow control).
So if I am in a residence where I can connect to 3 independant WiFi networks, and have 3 wireless network adapters, I can combine their bandwidth?! because that would be freaking awesome.
Since uncapped 3G is pretty common where I live, I've always thought to build something similar but without never finding the time to do it. This will also be great for load balancing my network the next time I gather to play some online-games with my friends.
Any idea will the proxy still be available if one of the connections drops? Like if my broadband cuts out (like it does on a daily basis) will the cellular data automatically take over?
For now, the proxy will still try to dispatch sockets to every network interfaces specified at launch. But such a feature could perfectly be implemented.
Can anyone explain how this works? From previous experience I always thought that this was not possible without some cooperation on the other end because the problem is you want to split the data being sent to you to different ips. If the other end sends all the data to the same ip, you cannot redirect/load balance to other ips before the data actually gets to you. What am I missing?
Probably each TCP connection only goes over one IP address, so the remote end doesn't get confused. All the data coming back on that connection will have to come in on the same path the connection started on.
If that were the case, the download would be no faster than using a single connection. I guess it would help if you download multiple things, but that is a different claim than what is claimed in the title.
Well, if you just balance TCP connections across physical connections, you could then combine this with a multi-connection HTTP download client and get the effect without any one piece having knowledge of it all (aside from the human). But yes, it's not going to be useful in general for everything.
In theory, it's possible to load balance transparently across multiple IP addresses, provided that you have a well-connected VPS in a nearby datacenter to serve as an intermediary.
From the world's point of view, you'll be connecting from the VPS's IP address, but between you and the VPS, you can do pretty much anything with the packets.
God I've been wanting to do something like this for a long time, but just didn't have the networking chops to get started. Glad someone beat me to it!
I imagine this would work well, not just on networks you own, but with cooperative neighbors as well. What if an entire floor of an apartment building used the same proxy? Would that work?
I think Justin.TV used a setup like this in the early days to stream 24/7 live video -- several mobile hotspots from different carriers all working on sending data to the remote server, ensuring that the data got there somehow. The difference was that they controlled the server side.
Ideally, in the future, yeah. But for now, two reasons I can think of: first, Multipath TCP doesn't cover the same use cases as dispatch. For example, having one proxy only route to low-latency connections (e.g. for gaming) and another to all connections (e.g. for downloads). Second, Multipath TCP isn't widely implemented and would require application developers to use it, whereas this can give many of the same benefits without waiting for your applications to support it.
Does this do bonding at the packet level, or at the TCP level?
Outcome being, if I download one particular file over HTTP will it run N times as fast, or are you just increasing the total speed available for many connections?
now i can use dispatch proxy on application bases like firefox or aria2c, simply by adding the proxy "localhost:8080" to the proxy section on these applications
but how to use it system wide ? so apps that don't support the use of proxies will be able to benefit from all this ?
Siri does this in a more systematical way. It uses Multipath TCP, which is in transport layer. This is an application layer hack. This one is actually less convenient and less efficient (tunnelling in proxy adds extra headers and reduces available data space in each packet).
The possibilities are endless:
* download a file through threaded downloading, effectively combining multiple connections' speed in one single file download,
* create two proxies, assign to each its own interface, and run two apps simultaneously that use a different interface,
* create a hotspot proxy at home that connects through Ethernet and your 4G card for all your mobile devices,
* etc.
Here are some instructions to quickly get started with using the proxy:
1) INSTALLATION
* Install Node.JS (http://nodejs.org/).
* Launch a terminal.
* Run the command `npm install -g dispatch-proxy` as a power user and press Enter. It will install the `dispatch` command-line utility.
2) STARTING AN HTTP PROXY
* To quickly start an HTTP proxy, run `dispatch start --http`.
* The program will print the proxy address and port (by default localhost:8080) as well as the list of local addresses the program will be dispatching requests to.
* Configure your system to use the combination address:port as an HTTP proxy.
3) LISTING ALL AVAILABLE NETWORK INTERFACES
* To list all available network interfaces, run `dispatch list`
* Each available network interface will be printed with a list of addresses.
* Right now, the dispatch utility only supports IPv4 addresses.
* If an address is marked to be "internal", then you won't be able to use it to connect to the internet.
I encourage you to read the docs https://github.com/Morhaus/dispatch-proxy.