On Thursday 11 Jul 2013 19:44:58 Vladislav Sterzhanov wrote: > Planned to form this as the next update, but got stuck, so reporting now. > | Testing: > Decided to integrate it directly into Freenet web UI for a number of > reasons: > - Implementing adequate and complete simulations required for > transport-layer tests is a huge standalone task that is not actually > required, so the testing will mostly be done on real-life links. > - This will need a huge amount of data to track and represent, so > need to organize it in a more comprehensive way, then pure text-logs > - Graphs (e.g. congestion window size \ time) will help to analize > the situation deeper.
Okay so we need to decide whether to expose stuff as SNMP, expose it over FCP and provide scripts for MRTG etc (some code for both strategies already exists), or whether to provide our own logging/graphing infrastructure. > | Heterogenous networks: > Currently empowering Freenet with at least Veno TCP-modification feels > a worthwhile improvement. Had anyone had any experience in the field or > just usefull-to-know stuff? The Veno implementation is simple since it only > adds Vegas backlog-tracking features to Reno algorithm that I'm going to > implement anyway, but at the same time adds a considerable boost when > operating over wi-fi (see > paper<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.2.1469&rep=rep1&type=pdf> > ). This looks good, and good wifi support is important for some cases. > | Traffic prioritization > This turned out to be a tough one. Just can't find a trail of the > correct direction to investigate, and own ideas seem to be too > straighforward heuristics by now. If anyone can lead to the right way - > will be grateful. Okay, I think I've solved this one, though I'd appreciate some feedback ... This is largely handled in PacketSender. Currently: - Messages have priorities, within the PeerMessageQueue for talking to a specific peer. - Messages have deadlines. Normal messages have a 100ms deadline, data transfers for bulk requests (as opposed to realtime requests) have a 5000ms deadline. - If we can't send a full packet, we will still send a packet consisting only of ack's, if the ack's are overdue. - Otherwise, assuming we have enough bandwidth to send a full packet... - If we have a peer with an overdue message, we send a packet to that peer. - Else if we have a peer with a full packet worth of data queued, we send a packet to that peer. - Else if we have a peer with overdue message acknowledgements, we send a packet to that peer. So essentially the problem for things like Bloom filter sharing and opportunistically filling up our peers' datastores is that if we queue lots of data at low priority, this will cause us to send that data even though there is more important stuff to send to other nodes. So I suppose the solution is to set an infinite deadline, or no deadline, for opportunistic/idle-time traffic. Hence we will send full packets when we can, but only if there are no overdue messages to other peers. Probably we should do this on a priority level: PeerMessageQueue already has a separate timeout for PRIORITY_BULK_DATA (5000ms) versus for everything else (100ms); we could just add a PRIORITY_IDLE_DATA priority which has effectively infinite timeout. Obviously one catch with this is that we sacrifice latency by always sending full sized packets. However, for Freenet, that's probably what we want, and it's not a lot of latency anyway. Certainly for traffic analysis resistance we don't want an attacker to be able to trace a single small message across the network - which is why we coalesce. And bandwidth limits need to be at least 15KB/sec for reasonable performance, so the latency cost of sending a full packet isn't *that* huge ... > > quadrocube > > 2013/7/4 Matthew Toseland <t...@amphibian.dyndns.org> > > > On Thursday 04 Jul 2013 12:52:40 Matthew Toseland wrote: > > > On Wednesday 03 Jul 2013 15:34:06 Matthew Toseland wrote: > > > > On Wednesday 03 Jul 2013 14:34:17 Vladislav Sterzhanov wrote: > > > > > By the way, can somebody suggest a sample for some traffic-heavy > > > > > simulations in node/simulator? RealNodeBusyNetworkTest crashes upon > > trying > > > > > to retrieve data and needs a sufficient amount of simulated nodes. > > For me > > > > > two of them would be enough. > > > > > (The crash case for BusyNetworkTest was in passing null as a > > container > > > > > argument to countQueuedRequests(), fixed it with a simple return 0; > > but not > > > > > sure whether I didn't break any logical invariant) > > > > > > > > Set up two nodes and send a BulkTransfer between them? (I.e. a node to > > node transfer) > > > > > > > > Don't think there is a suitable automated unit test yet. > > > > > > > It would certainly be useful to have this. Local or LAN transfers can be > > surprisingly slow with the current code. LAN tests will need you to set up > > two nodes manually, and add them as Friends; let me know if you have any > > problems. > > > > > Doing this manually: Click on the node on the Friends page, attach a large > > file. Go to messages on the other node, and accept the transfer. The file > > will be in downloads/direct-<node name>-<filename> or similar. > > >
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
