I have been doing some playing around in the code, in addition to the
"real work", looking at doing things like different data stores and
different lookup mechanisms (can you say "multicast"? I can!). Both
these changes require making changes to the way messages are handled --
*all* types of messages. Going around and whacking the internals of
each variant of pReceived to add these new behaviors is neither a good
idea nor a good time. There needs to be some sort of "pluggability" in
the way incoming messages are handled.
So, for example, consider how Request.pReceived actually works.
Currently, the code can be summarized as doing the following: detect a
loop, retrieve the data in the datastore, retrieve the data from the
address we have for the data, retrieve the data from hosts with "close"
keys, and return a failure message.
My modest proposal is that these activities be encapsulated in actual
"strategy" objects that perform each function. Then, once a message has
arrived and been parsed out of its raw format, it is simply passed to
the list of strategies. Other strategies can be included as needed, so
an expanded list might look like (asterisks mark strategies that do not
yet exist):
CheckUniqueIdStrategy, MyDatastoreStrategy*, DiskCacheStrategy,
KnownAddressStrategy, MulticastLookupStrategy*,
CloseAddressStrategy, RequestFailedStrategy.
These strategies should be configurable at run-time (in the .freenetrc,
presumably). For example, a node that does not want to store data can
leave out the DiskCacheStrategy; a node on a small network behind a
firewall might replace CloseAddressStrategy with DefaultAddressStrategy
(configured to send all requests to the "gateway" node); developers
might insert a StallTenSecondsStrategy to chase timing problems..
This approach works across all message types: the series of actions to
be performed on data insertion matches more or less in lockstep those
for data lookup. An insertion is less likely (completely unlikely?) to
interrupt the strategy chain, so it may be that only requests get to
throw exceptions.
What do people think? I don't think I'm being completely hair-brained
here, but maybe there is a better way to do this. How much coding
anguish would this cause, and who here is competent to do this sort of
major restructuring?
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
