On Friday 21 December 2001 06:07 am, you wrote:
> On Fri, Dec 21, 2001 at 12:43:40AM +0100, Goran Thyni wrote:
> > This could be as complex as multiplexing,
> > and if UDP transport is to be implemented
> > multiplexing is needed anyway.
>
> Replying to myself again :-)
>
> Multiplexing connection is important infrastructure
> needed not only to "beat NAT"-strategy, f.ex. to implement
> UDP transport.
>
> Looking at the code,
> sessions seems to depend on its transporthandler (thread)
>
> A muxed link could be implemented using:
> * a MUXConnectionHandler class which extends ConnectionHandler to
>   - create new sessions/VConnectionHandler for incoming requests
>   - dispatch/receive messages to/from VConnectionHandlers
> * a VConnectionHandler class that implements virtual connections
>   - sends/receives through a per link MUXConnectionHandler.
>   - adds a SessionID field to every outgoing messages so it can
>     dispatched correctly at the receiving end.
> * an OpenVConnectionManager class which extends OpenConnectionManager
>   with some small bits.
> * a new transport TCPMUX downwards compatible or side by side
>   with normal TCP transport.
>
> I will also look into what is needed to support an UDP transport.
>
> In an earlier discussion lots and lots of transports were suggested,
> to implement this a more modular architecture for connections is
> needed.
> That thread starts here:
> http://hawk.freenetproject.org/pipermail/devl/2001-August/008348.html
>
> regards to all,


A useful type of network connection would be an "Anonymous Message 
Broadcast," (See: Applied Cryptogoraphy, Chapter 6 Section 3) where a few 
nodes can get together and anonymously request and retreive files between 
each other.  If nodes on a NAT ran this, they would have some anynomity 
protection from the gateway, even if the gateway is not participating (but 
just as long as the gateway is allowing traffic to go through).   This could 
be layered on top of the transports and connect with nodes that the current 
node has good bandwidth and latency to.

Fred should be made modular enough to support connections, transports, 
and data transformation (for hiding on the transport) all seperately, and 
allow modules to be plug-and-play.


Scott Young

_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://lists.freenetproject.org/mailman/listinfo/devl

Reply via email to