Description:
Generic TCP stream multiplexer, automatic tunnel configurer, command line, and web-based front ends.
Synopsis:
This project is a special network tunnel that accepts an incoming connection, splits it's data across a number network tunnels (ssh/whatever), and reassembles the data from these tunnels on the other side. This allows bandwidth aggregation, reliability, redundancy, and increasing cost effectiveness of network utilization.
Features:
- Basic features are:
- Bandwidth aggregation across a number of physical links such as across multiple interfaces or modems. In researching bandwidth aggregation methods, I found that most solutions involve a low level driver for bonding Ethernet or serial lines, forget bonding a T1 and backup DSL going through different ISPs unless you want to do a lot of work. Furthermore these are not user space, on the fly configurable methods, so many of the possible advantages are ruled out. This program is much more flexible.
- Overcome bottlenecks further out on the network. For example, to saturate discrete network paths, or even increase bandwidth to a host that has arbitrary per connection bandwidth limits (strange firewall stuff).
- Failover and Redundancy This is due to automatic reconnecting of intermediate tunnels and effecient link bonding.
- Cut the cost of networking. For example if a person gets: A cheap/ unreliable/slow connection and a reliable/fast/expensive connection. The program can be made to favor the cheaper connection, but if unavailable it uses the other. Or you can bond two cheaper lines instead of getting one expensive line.
- Smoothe upgrade path. Say one has already invested in several network connections. This program allows him to add more capacity as needed instead of scrapping everything for each upgrade.
Details:
The program basicly consists of a client and server. An incoming connection is accepted by the client, the data from this socket is split among a number of intermediate sockets and recombined by the server at the other end:
tunnels
/-------------\
initiating socket -> client ---------------- server -> remote server app
\-------------/
example: port 5555 multiple ports/interfaces port 4444
This is like a regular unencrypted ssh tunnel, except the data is divided among many tunnels. It would not be much more difficult to allow reverse connections as well.
- Detailed features and future roadmap:
- Uses socket ids to track multiple sockets from one port that are going through the tunnel (like socat or ssh).
- For the ultimate in scalability, no more than ONE instance of the program should be neccesary per machine. The program runs as a daemon and take requests from the local machine to set up new clients and servers on given ports, along with more advanced commands.
- Tying in with the above, I think the best interface for the program would be with a simple command set over tcp (ala edonkey, mysql), this will be the backend for basic command line tools which communicate with this server (msaddtunnel, mssetbandwidthlimit..). Further down the road, a web front end could be added to manage the tunnels too.
- Have a variety of schedulers. These schedulers are the heart of the program that decide how much data to send across which pipe when. Different ones can be optimized for: low latency, high throughput, tunnel priority (QOS), low memory usage, low cpu usage, etc. This is where the real fun comes in, and I'm sure that with a good framework, there will be many people that suggest schedulers with other properties.
- Can communicate with multiple remote servers and especially not trash everything when someone accidentally adds a tunnel to a different server than all of the other tunnels. This necessitates the use of server ids.
- Uses a fixed number of sockets through each tunnel (default 1). Using socket ids and channel ids, multiple ports and socket connections will be combined together. This will add the benefit of decreased latency in starting a bunch of short-lived connections due to the slow ramp-up of TCP. For example, x11 and http. This what ssh does too.
- Allow for tunnel grouping for easier admin, see examples below.
- Bandwidth limiting for tunnels and whole channels. Unfortunately it seems that the most graceful way to do this is for each side to limit their upload. This must be coordinated.
- Maybe, rewrite the critical path in c. This should be a short task but may not happen for a while because when do you really run out of fun features to add?
- Maybe, rewrite it all in c!?
- All all of the other stuff that I forgot to write here.
So, overall topology on one side should look like this:
command line
admin programs: manager daemon:
----------- ------------------
|addtunnel|---->-P| <-admin port |
----------- / | |
|deltunnel|-/ | | tunnels
----------- | --------------- server socks /-------:
| | Multiplexing|P--<-------------<WBR>------: to remote machine
client socks--->-P|--| API | / \-------:
| | |P-->----/
server output--<-P|--| | client socks
| --------------|
------------------
^
|
The API implements the client and server.
Notes: The arrows indicate the direction in which the connections are
initiated, but data flows in both directions on all sockets. There is one
admin port, and zero or more ports of all other types of connections.
Possible command line examples: Here is the rough idea. I can provide more refined examples once I dig out my notes.
- # msaddtunnels --names=joe,frank,bob --tunnels=joe.com:3456,frank.ru:789,bob:6
- # mslimittunnel joe 50
- # mspriotunnel frank 1
- # mspriotunnel joe 15
- # mscreategroup -n dsl_users -t joe,frank
- # mssetdownloadlimit -g dsl_users 100
Project Schedule
The project is very close to a beta state. When the basic program is complete I would like to do more experimenting with schedulers optomized for different constraints.
2005 ANS.