On Friday 30 November 2007 23:03, Robert Hailey wrote:
>
> On Nov 30, 2007, at 1:35 PM, Robert Hailey wrote:
> > [...] I see the major problem at hand is that the time in-handling
> > of packets must be minimized[...]
>
> To illustrate my point the following patch shows an approximate 100%
> speedup for freenet, by my crude profiling.
Speedup measured how? More comments below.
>
> Index: freenet/node/RequestHandler.java
> ===================================================================
> --- freenet/node/RequestHandler.java (revision 16160)
> +++ freenet/node/RequestHandler.java (working copy)
> @@ -121,7 +121,7 @@
> htl = source.decrementHTL(htl);
>
> Message accepted = DMT.createFNPAccepted(uid);
> - source.sendSync(accepted, null);
> + source.sendAsync(accepted, null, 0, null);
>
> Object o = node.makeRequestSender(key, htl, uid, source,
> closestLoc, resetClosestLoc, false, true, false);
> if(o instanceof KeyBlock) {
>
> A much-more aggressive patch (which makes all RequestHandler sends
> Async except the 'last') shows could be 12x; but am concerned over the
> byte-counter side effects with which I am not familiar.
Hmmm. Okay, here's how it works:
*Sender is responsible for sending a request out, talking to the nodes doing
the request.
*Handler is responsible for receiving a request, and keeping the requestor up
to date.
One Sender may serve many Handlers, or it may serve a local request. One
Handler may have no Sender if it is e.g. a request satisfied from the store,
or if it ran out of HTL.
There are two main reasons for using sendSync():
- To make sure the connection to the requestor is still open, and responsive
(won't timeout us and then reroute the request) and kill the request if it
isn't. Once a request has started, it is not possible to stop it (on
downstream nodes), so opportunities are quite limited; the fact that one
Sender can serve many Handlers or none makes it difficult to push the stop
button.
- To get the correct byte counts.
This is really important, because it underlies the major load limiting
systems. However it is only important for terminal messages: we can
reasonably assume the rest will be piggybacked if necessary.
In RequestHandler, most of the sendSync()'s are terminal, and therefore must
remain. The one that is the most interesting is the one you mentioned above:
sending the Accepted message.
One reason to keep it as-is is to deal with nodes connecting, sending a load
of requests, and then disconnecting, as a DoS attack. This is implausible as
a sensible the load limiting system won't let them start enough requests to
be a problem given the relative difficulty of getting new connections. Of
course, getting new connections is likely to be rather easy on opennet...
Another reason is if a node or a link is hopelessly overloaded, we don't want
to run a request which will not serve any purpose because the node will
timeout on us and route it to another node. This isn't really dealt with by
the current code either.
So it looks like your patch is worthwhile...
You can use the same logic on all the Handler's and Sender's. Either send me a
new patch, or send me your preferred username, password and email address so
I can give you an SVN account and you can commit it yourself.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20071202/a95cea10/attachment.pgp>
