Concerning the sneakernet issue:
The routing seems to be a problem. How does the sneakernet method exert
preference over which node it communicates with? That would have to be
dealt with, or shown to be irrelevant.
Also, there's a speed issue, for routing. Routing is based on human
networks. The flow of information through sneakernet will be based on
channels that shift so slowly (two friends or co-workers who swap CDs over
the years, or swapping CDs with the folks at the elk lodge) that they are
effectively concrete, compared to the routing-optimization that occurs over
TCP/IP. The routing as it currently stands (direct communication via
TCP/IP) garners such adjectives as "on-the-fly" or "wild". TCP/IP based
routing finds the information it wants in a quicker, more efficient way
than sneakernet routing would.
TCP/IP based routing, however, is designed to minimize the flow of
keys. It's designed so that when a node requests a key, it's likely to
find it close by. Key flow is minimized, datastore churn is minimized, and
the routing tends to stagnate some. However, the number of keys that move
through a node that communicates via sneakernet will be large. If the node
is looking for a key, it's going to have a vast choice of keys to dig
through. Also, with the slowness of sneakernet-based freenet, keys would
stick around longer. Say "KSK@text/philosophy/billofrights". Quite a
static document, and not very popularly requested, but very important to
keep around. In a slower-moving freenet it would be easier to keep it around.
Each network excels where the other leaves off, and falls short where the
other excels. More importantly, the two networks are complementary in some
ways, and can certainly co-exist peacefully. If a datastore has the high
churn of sneakernet and consequently de-specializes, then the
quick-as-a-bunny TCP/IP routing of other nodes will route around the
sneakernetted node due to never finding what it wants there. But, to the
extent that a node is used for TCP/IP communication, the flow of keys
through it will specialize the node again.
And sneakernet is not the end of the issue. We can imagine 'sneakernet' to
be simply a metaphor for the Great Unknown. Key flow could take place via
physical media, via email attachments, via file sharing networks, via radio
signals (interplanetary freenet anyone?), and even teletype, if you
wanted. Key flow could happen over any number of networks in addition to
the direct TCP/IP variety. For that matter, it could happen over TCP/IP in
various states of performance. This seems to me to be an obvious
benefit. NAT and some firewalls are already causing stoppages in freenet
communication. What will the Chinese government do when they realize that
freenet exists and what it is? What will the Department of Homeland
Security do? What could alternate channels of communication do to combat that?
Freenet should not grow incestuous with TCP/IP. The freenet node would be
most helpful, and go furthest toward the stated philosophical goals of this
project, if it worked *wherever* it was needed or wanted.
Routing should be viewed as an entity independent of the medium of
communication. The terms that frame the discussion of routing should be
implementation-agnostic. Routing, if implemented properly, could work over
a network with any degree of latency or any amount of datastore churn or
any method of communication. Routing, along with encryption, is the
central concept that constitutes freenet. Implementation of the routing
algorithm in differing mediums, with differing performance characteristics,
should be always possible in theory. Leave the 'in practice' part up to
any who wish to try it.
Can the freenet software be made to handle sneakernet? That's an issue I'd
like to see the sneakernet proponents tackle.
-Todd
_______________________________________________
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
