On Fri, Oct 10, 2003 at 12:09:29AM -0400, Ken Corson wrote: > Toad wrote: > > but it has not been implemented yet, and freenet needs debugging more > > than major new features at the moment (although I may do multiplexing > > before 0.6). > > Ian, Toad, Ed, Jonathan, (rest of design/development folks), > What is your definition of connection multiplexing ? I just want to > see unity in DEVELOPER's expectations of what it will represent > structurally, prior to implementation ;) Let me be clear: I AM NOT > asking what levels of performance boost people would hope to see, > how they worry it might affect the network(s)... my choice of the > word implementation above is poor, please replace with coding. This > is not a knock on anyone, but recognition of some (recently) "vocal" > people. As we have seen demonstrated, many people encompass more > than design and coding in the word 'implementation.' I hope that I > will fall into the developers category soon. Currently I'm > constructing a java simulator for FreeNet, and I want it to be > relevant. It's purpose is to evaluate algorithms for routing, > theories involving specialization, etc. (mainly a learning tool)
My definition of connection multiplexing is the ability to send more than one trailing field stream at once over the same connection. This enables other improvements such as limiting connections to 1 per node. Fewer connections opened and closed means less negotiations, lower latency, higher reliability, lower CPU usage etc. > > > My definition for connection multiplexing can be summarized quite > succinctly - > > " channeling ALL communications between a given pair of Nodes > through a SINGLE, bidirectional, reliable network connection " > > Other interpretations of multiplexing might still allow for more than > one network connection between a given pair of Nodes. > > > The benefits of strictly limiting to one channel per peer: > - some synchronization issues can be handled easier > - outbound messages for a given peer can easily be PRIORITIZED > while queued This can be done easily enough anyway. The recent changes were about a change of architecture, called PeerHandler, to introduce a single message queue for each node we talk to rather than for each connection. > - external traffic analysis becomes more difficult Yes. > - fewer total network connections per host ( maximum peers vs. > maximum # connections ) Definitely. A big advantage IMHO. > - possibly could lead to more accurate outbound bandwidth control Hmm. > - increased software metrics of "goodness" with a simpler design ? Dunno. > > The drawbacks: > Now every logical communication (insert or query request, data > content for a GUID, whatever) must be abstracted one level > as a Message (which would have a message type and length). Large > GUID-contents may need to be "chunked" at this level, to prevent > one data-streaming operation from destroying latency on the > connection. This may already be performed with the Packet class, > I'm not quite freenet.* fluent yet. Currently we have Messages and we have trailing fields. The latter take up one connection but can transfer arbitrarily slowly due to for example a slow source node. We will make it possible to send multiple trailing fields over a connection, and at the same time simplify the parsing code for Messages (using a protocol involving a length prefix byte and a type prefix byte, which will also allow for connection specific messages or data such as Identify or the long-awaited on-net IP detection to be more cleanly separated). One major issue: mainstream multiplexing protocols such as WebMUX use some sort of flow control mechanism to prevent having to use infinite buffers etc. We don't need to, because we are going to impose a maximum file size and eliminate circular buffers. Then the data goes straight into the store and we don't need to block on the other end. As long as the network isn't faster than the disk there is no problem. > > > Are there any datastore design ramifications ? Not really IIRC. Datastore would be affected more by making transfers fully nonblocking, which I will get around to eventually, perhaps in connection with multiplexing. > > > This message concerns design and coding only, not testing and > deployment, thus it was posted to the development list. > > -Ken (apologies in advance for long message) > > > IRC: if Ian is sanity, then I'm gonna be unity ;) Ian is sanity. I am toad. -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
