Hi! On 16:35 Sun 07 Mar , Eugen Leitl wrote: > ----- Forwarded message from Christian Grothoff <[email protected]> ----- > > From: Christian Grothoff <[email protected]> > Date: Sun, 7 Mar 2010 12:30:53 +0100 > To: [email protected], [email protected], [email protected], > [email protected], [email protected] > Subject: Help needed: Autonomous NAT traversal test [Was: enabling bridges on > NATed clients] > User-Agent: KMail/1.12.4 (Linux/2.6.31-14-generic; KDE/4.3.5; i686; ; ) > Reply-To: [email protected] > > Dear all, > > In order to more thoroughly answer sird's question (for GNUnet, possibly for > Tor and generally for anyone interested in P2P), a group of people (including > Andreas Mueller, Samy Kamkar, Nate Evans and myself) would like your help.
I had some thoughts about building a library for applications which do fancy things with the underlying network. Primarily, because I have a project which will likely be more useful, if applications take proper use of it. (see http://michaelblizek.twilightparadox.com/projects/cor/internet_exit.html ) To my mind such a library should do *way* more than NAT transversal, if it is supposed to be "generic": - Provide OS abstractions - Provide socks proxy (which BTW have a way for opening ports on the other side) abstractions - Use its own configuration file, if the application does not override things at runtime. This way, the user can configure everything even if the application does not provide ways to set certain parameters. Also, an "application name" parameter should be passed to the lib, so that the config file could contain different parameters for each application. - Maybe provide some addressing abstractions, so that applications can run within IPv4/IPv6/.onion/... networks without changes. - Provide ways to set things like IP_TOS, so that external shapers are easier to setup. - Make sure that e.g. TCP_CORK is always set when possible. - Do throttling the proper way and *not* by "usleep", but by setting TCP_CONGESTION or smaller tcp window sizes if possible. "usleep" should only be the last resort. When using usleep or smaller tcp window sizes, the lib should be able to figure the proper parameters out by itself e.g. by pinging a fixed IP and looking at the response times when the net is under load. - Provide a way for the application to tell the library which connections are important and which connections need throughput or low latency. -Michi _______________________________________________ Help-gnunet mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnunet
