[jump to content][No Software Patents]Tools (new) : multiproxy [ Home | Scylla+Charybdis old home | Tools (old) | Tools (new) | FAQ | Downloads ]

Moving to GitHub, slowly

The software on this pages will slowly be moved to GitHub https://github.com/hilbix/. The CVS repository will be migrated to GIT as well, so the history will be preserved, a bit. See FAQ.

Scylla and Charybdis, multiproxy - Tools

The tools are developed under Linux with ESR's paradigm release early, release often in mind.
So you can consider this beta software, or alpha, or pre-alpha, or even worse ;)

Have a look in the download directory for all downloads.
As always here, all you get is the source. No binaries here.

multiproxy 0.2.1-20081021-014523

A multiple proxy implementation (look into latest version, download latest version 0.2.1-20081021-014523, sig)

This is a generic proxy implementation serving only one single request per fork(). It can be run from socklinger (or inetd) from stdin but also is able to accept the connections itself.

It is slow, because it uses fork extensively. This is by purpose. For me it's more important to be as flexible as possible instead of having ultra high performance. Performance can be gained easily by more hardware, without increasing the complexity of the code.

Using this simple approach it's easy to apply tweaks to protocols and change the behavior without interrupting any service.

The only protocol supported for now is an incomplete SOCKSv5 implementation.

It works. See README for details.

History:

version 0.2.1-20081021-014523

download (231918 bytes) sig

Bugfix release (untested)

I mixed some call in an internal library function. I believe in this case it did no harm. This release fixes that (by an update to the latest tinolib).

version 0.2.0-20070508-182130

download (179240 bytes)

Added limit to maximum number of forks. Documentation changed to meet current version.

version 0.1.0-20070418-014137

download (175152 bytes)

Now based on tinolib and added self-fork option.

It does no more need another program to do the accept-loop. This saves a lot of memory and CPU in simple situations.

You give the [ip]:port as the second argument behind the authenticator which usually shall be empty in this situation (however the authenticator only needs CPU and memory for a short time).

version 0.0.0-20060126-134503

download (19158 bytes)

A very limited first version implementing SOCKSv5 partly.

It works for me somehow, but it shows some problems:

  • Missing SO_KEEPALIVE in socklinger or other calling applications. Multiproxy shall set that and use shutdown() to shut down the socket.
  • Applications are just starving and keep a socket open. Over time this uses up all available multiproxys (socklinger is designed only to start a certain number of them). This can be based even on other bugs outside the apps, sometimes under Windows sockets just seem to "hang" even though the applications does no more know about these sockets. Multiproxy needs a configurable transfer timeout to counter this.
  • The former problem can be partly in multiproxy, unable to tear down a starved connection. Multiproxy certainly is missing some features. However I want to keep it simple.
  • Applications are braindead. When I try to keep free some uplink using Azureus, Azureus starts to send out so smaller and smaller packets. That way it even uses more uplink than before because of the packet overhead. So my uplink gets filled with 90%(!!!) supervisory data and only 10%(!!!) payload (instead of transfering 10 KB/s it drops below 1 KB/s). Multiproxy shall have some configurable way of chaining all those small packets into bigger ones to counter these crappy behavior.
  • Applications are overwhelming. Instead of opening one socket a time, often you can see 20 sockets comming in in parallel. As fork() is used to call multiproxy this makes my Linux router choke (486/133 w/ 16 MB RAM, nearly 10 years old machine, so why change?). Multiproxy shall be called serialized, that is, I need an option in socklinger to do so, say, fork 1 multiproxy per second is enough.
I will investigate all these slowly and try to solve one by one until I am satisfied. However this may take longer as expected, so I release this here early, as usual.

For now if multiproxy is started as follows

socklinger 40@127.0.0.1:1080 multiproxy ''
I 'solve' the above problems by a kill-loop a la
while sleep 3600
do
killall -1 socklinger
sleep 1
killall multiproxy
sleep 1
killall socklinger
done

License and Disclaimer

All you can see here is free software according to the GNU GPL.
Copyright (C)2000-2011 by Valentin Hilbig
Note that the software comes with absolutely no warranty of any kind.
You use the software at your own risk.
Valentin Hilbig cannot be hold responsible for any unintended damage,
lost data or malfunction of the software you can find here.

[FSFE contributor 2007]

[end of page - jump back to content][hacker culture]
Last modified: 2011-09-12 by Valentin Hilbig [ Imprint / Impressum ]