On Wednesday 23 May 2012 18:00:40 Chetan Hosmani wrote: > Hello everyone, > > I have been a bit busy last week, and haven't committed much code. > Here are the following refactor changes I have implemented and pushed > to "refactor-1" branch- > > 1. Added a separate list for transport managers. So we basically have > a list which will contain a manager for every mode. Presently it has > two - opennet and darknet. > > 2. NodeCrypto functions in the following way- > a. Transport managers are created in the node irrespective of whether > opennet or darknet is running. > b. NodeCrypto on creation for every mode accesses its respective > transport manager to get a list of transports. > c. It runs the method handleNewTransport to initialise a PacketMangler > and handle each transport plugin. > d. If the list of transports is empty, then it will function using the > inherent UDPSocketHandler transport and run normally. > d. When a plugin is loaded (on registering with TransportManager), the > manager checks if the corresponding mode (opennet/darknet) exists and > notifies the NodeCrypto by calling the handleNewTransport method. > > 3. UDPSocketHandler now extends PacketTransportPlugin, and I have made > changes so that it looks like a plugin. I have built it and checked. > It runs fine. > It also registers in the transport manager. > > 4. Presently working on replacing the Session keys in the PeerNode > object. There are three - current, previous and unverified. I am not > yet well acquainted how these work. > But the idea is to have a separate connection object PeerConnection that - > a. Has a unique PeerNode > b. Has a transport associated > c. Has the corresponding Peer (detected Peer) object associated > (different transports are on different ports, and we can keep it open > to use different addresses itself)
This should be fairly similar to the current code. There are some complexities, e.g. <our detected IP>:<our nominal port number> is not necessarily valid externally; this is why we include both that and the address/port that our peers tell us is our address/port number. > d. A list of session keys. It need not be three. The code can become > more generic. > > So PeerNode has a list of PeerConnection objects, for every active > transport. The PeerNode will decide the transport to use using these > objects. The rest looks good. > > > The official coding period has started. So after a few more additions > I will merge them to "Transports" branch and begin working on a new > branch "PacketTransports". > Also awaiting some code review, after nextgens becomes free. > > For the coming week- > > 1. Work and finish handleNewTransport > 2. Finish the PeerConnection object > 3. List the changes needed for multiple transport support in PeerNode > (implementing PeerConnection list) > 4. Figure out PeerNode code to use different transports > > Later on I will mainly work on NewPacketFormat which needs to be > changed so that they are more generic for Packet Transports. Hope to > have toad's and zidel's help then. > > ArneBab - Flog is coming too. Sorry :) > > Regards, > Chetan Hosmani -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20120620/382f8a20/attachment.pgp>
