> We should think about how difficult it would be to allow the various > non-streaming messages (ie. the messages that do not contain a stream of > data) to be transmitted via UDP, as opposed to TCP.
I see this as a two part question - how difficult would it be to support non-TCP socket transports, and how difficult would it be to add support for splitting up certain types of messages for delivery over different transports. I'll deal with the former first. Currently, Fred has a few "nuances" tying its operation to connections as TCP sockets. The main hurdle I've run into implementing another transport has to do with the intermingling of the transport layer with the other parts of Fred. Specifically, the use of OpenConnectionManager.ConnectionJob to implement part of the transport protocol as well as FNPLink and FNPLinkManager mangling connection data for transport security. The transport layer has great interfaces, but transport layer security isn't implemented in the transport layer as (IMHO) it should be. This ties components higher up in Fred to the assumption of streaming synchronous communication - a property of TCP sockets, not a general purpose transport layer. Once transport security is wholely contained within the transport layer, different protocols can implement whatever voodoo magic they need to so as to provide the security Fred needs - packet by packet encryption (or whatever) for UDP, streaming encryption for TCP sockets, as well as whatever other funky stuff needs to be done for any particular transport. Fixing this is pretty easy. First, a change to the transport abstraction is necessary - a Connection is a secure means to send messages back and forth between a peer [as opposed to just being viewed as a raw socket to another machine]. To reflect that change, add getMyIdentity() and getPeerIdentity() to freenet.Connection. At that point, all of the transport layer security currently implemented should be merged into the TCP socket transport (this includes FNPLink and FNPLinkManager, as they implement transport specific security negotiation). We don't need to change the concept of Connection.getIn() or .getOut(), as the Presentation.readMessage(in) and RawMessage.writeMessage(out) handles translating messages into raw bytes on the stream. The rest of the app just needs to "forget" about the Link class (Connection has a nearly identitcal API) and leave transport management to the transport layer (aka if Fred really needs to explicitly tell the transport to clean up its links [LinkManager.cleanupLinks()], we can add a Transport.expireUnusedConnections(), though I really think transport layer connection maintainence is the transport's responsability) In addition, the transport layer should be responsible for any multiplexing between lower level connection mechanisms (sockets, etc) and the Connection's InputStream. Yes Toad, I know new transports don't belong before 1.0, but maybe refactoring the transport layer so other transports can reasonably be built does. As for whether Freenet should use different transports for different types of messages, I wouldn't suggest going that route, but instead leaving the decision as to how to deliver each particular type of message to the transport itself (for example, the transport could say "oh, this is an AcceptedMessage" and block encrypt it or even keep it cleartext instead of using a stream cypher). -jrandom (p.s. yes, you could communicate via UDP through JMS) !+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+ CryptoMail provides free end-to-end message encryption. http://www.cryptomail.org/ Ensure your right to privacy. Traditional email messages are not secure. They are sent as clear-text and thus are readable by anyone with the motivation to acquire a copy. !+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+ _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
