On Friday 21 May 2010 14:05:06 Martin Nyhus wrote: > I've tried to think about how to implement the new packet format, while > keeping the old code around. My plan so far is to move all the FNP > related code from PeerNode to a new class, and have PeerNode use the > old code through this class. > > The new code can then be added without touching FNP, and PeerNode will > choose which format to use for each peer. At the moment I'm not sure > how to select which format to use. It obviously depends on the peer, so > is there anything in the node ref that can be used to decide that the > peer supports 'FNP v2'? If not, can something be added without breaking > old nodes, or is there a better way of doing this? > Yes. See "auth.negTypes" in node references, and its corresponding code in PeerNode and FNPPacketMangler. We auto-negotiate based on the available negotiation types, and we declare them in the noderef. At the moment this is only used for link setup, but in principle it could be used for post-setup connection formatting.
A lot of the FNP code is already moved out of PeerNode into two classes: PacketTracker SessionKey The actual connection setup code, and a few minor bits and pieces (e.g. crypto keys) are still in PeerNode. IMHO you won't need drastic changes to the connection setup code. Did you have any specific structural changes you were thinking of as a first step? It probably makes sense to not change over to the new block transfer code until the new packet format is well established, to avoid having to write code for converting between the two mid-route. However, it will be necessary to keep support for old style bulk transfers for quite some time because it is needed for Update Over Mandatory to continue to work. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20100522/323586f1/attachment.pgp>
