On 23/02/16 17:53, Martin Byrenheid wrote: > Hello again, > > in the current Freenet-code, the realRun-method of the AnnounceSender class > contains a check whether opennet is disabled [1]. However, (if I understood > the code correctly and) if opennet is disabled, no Instance of the > AnnounceSender class will ever be created at this node (incoming announce > requests are already rejected in the handleAnnounceRequest-method of the > NodeDispatcher-class [2]), which renders the check mentioned above obsolete. > Therefore it may be removed for the sake of code simplicity. I know, it's > just 4 lines but I think it's worth mentioning.
Hmmm. I thought we relayed opennet announcements through darknet nodes? We probably do want to send them through hybrid nodes, so we can't just say "never forward an announcement to a darknet peer"? Or can we? As discussed previously I don't think the security issue is relevant one way or the other, e.g. swapping and FOAF data give away a lot. So currently we will send it to a darknet peer, but if it's a pure darknet node it will reject it, whereas if it's a hybrid it may accept the announcement? Path folding, on the other hand, *is* relayed through darknet IIRC. Anyway, the apparently redundant check is probably there to deal with race conditions - whether opennet is enabled changes occasionally. IMHO that is legitimate. > While trying to run Freenet in a local testbed without connection to the > "real" Opennet, I encountered a problem which keeps nodes in opennet-mode > from > connecting to each other. More precisely, my testbed currently consists of 3 > nodes: a seed node S and two opennet nodes O1,O2. When O1 sends an > announce request (with HTL 18) to S while O2 is not connected to S, S accepts > and also wants O1 as a peer, thus S sends an AnnouncementReply together with > its noderef to O1. After S has sent its ref, it sends a FNPRouteNotFound to > O1 > as no more peers are available. However, the packets received by O1 are > handled in a different order than they were sent by S, so that the > FNPRouteNotFound-message gets processed earlier than the last message of the > noderef-transfer, thereby closing the connection to S and causing the noderef- > transfer to fail. I encountered an analogous case when O2 was also connected > to S, where a noderef-transmission from O2 to O1 via S was aborted because > the > FNPRouteNotFound-message from O2 was processed earlier than the last bulk > transfer packet. > Do you know what might lead to this reordering? Both S, O1 and O2 are running > on the same machine but with different ports, so I wouldn't expect the OS to > reorder packets. If you need more information (logfiles etc.), I would be > glad > to help. Bandwidth limiting, message priorities, something of that nature. The point is it shouldn't actually complete the AnnounceSender and close the connection until existing transfers have completed. Which is why complete() waits for all transfers to finish. Unfortunately we don't call complete() in the case of an RNF! AFAICS the solution is to copy the wait loop from complete() into rnf(). Patches welcome. :) Thanks for looking into this stuff! > Martin > > > [1] > https://github.com/freenet/fred/blob/71a788164a896d6e5b6af0dfe0f35da5a6927633/src/freenet/node/AnnounceSender.java#L139 > > [2] > https://github.com/freenet/fred/blob/71a788164a896d6e5b6af0dfe0f35da5a6927633/src/freenet/node/NodeDispatcher.java#L648 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
