coderman wrote:
Hi Coderman -
Thanks for your big set of ideas!
a quick overview, since i don't have time (yet) for a more detailed reply:
there are a plethora of ad-hoc routing protocols [0] and some are well
suited towards this kind of wireless mesh. my particular favorite is
Link Quality Source Routing [1] which supports multiple radios nicely.
this is what you'll need to do your "rebroadcast" efficiently.
"Link Quality Source Routing" does sound pretty cool, but in a system
where there is zero identity in the nodes, I don't know how traditional
concepts of routing can apply. Instead of an active transmission-led
routing system, where the transmitter makes decisions to direct packets
at particular receivers, in this concept the only active decision is if
a receiver will rebroadcast. It can't target its broadcast.
some comments about the broadcasts: you'll want to consider encoding
rate and transmit power in the xmit stack, one size fits all (that is,
no differentiation between packet types and encoding) will be
inefficient, and you'll get better behavior if you can tune this
accordingly. rate control is actually pretty complicated in practice,
while it may seem seductively easy in theory. [2]
Yes it is a good point, but again the situation is unusual for that.
One might reduce the transmit power or decrease the transmission rate to
optimize a link to a particular node, but there are no particular nodes,
they are all "spartacus". I guess it can keep stats on re-requested
packets, or look at the tx signal strength used to make the request, and
figure out that there is a distant client it could service by dropping
the rate temporarily, but that has ramifications too.
along similar lines, packet size (including fragmentation, if needed)
will greatly affect the receive-ability of your broadcasts by multiple
clients, since longer payloads are more likely to experience
collision, thus forcing back-off and retransmission. in short, it
might work best to have the signalling/control/discovery traffic in
small packets, sent at the lowest bitrate and max power, while the
data traffic uses a different (more flexible) rate and fragmentation
layer. (you might be doing this already, but i did not see details on
the wiki) antenna selection may also be useful now that wireless
devices are including MIMO and multiple antennas more frequently.
Yes my current idea is this kind of granularity
- frame-sized packets 256..512 bytes that actually get transmitted
- 4K blocks of packets (individually signed)
- 1MByte "chunks" of 4K blocks (which form the "files" in the caching
system)
Each packet is marked up with the hash of the upload to which it belongs
[just to emphasize this point, the broadcast nature of wireless makes
it ideal for resource discovery requests, since it is a true
broadcast, and not an emulated one implemented via iterative unicast
or forwarding, etc. in particular i've tested small periodic payloads
(<128 bytes) at 1M rate and 1W xmit to great effect, literally many
tens of miles diameter. you shouldn't need such a high degree source,
but this does show just how wide a unidirectional path can be when the
wireless layer is tuned for distance]
Sounds like you have been there :-) This idea that you might be able to
hear a station but not talk back to it is behind the total lack of
acknowledges, that and the fact an acknowledge from one station has
little meaning when you broadcast to many. But the requests from the
guy that is unable to talk back directly can find their way back to the
transmitter via other stations.
The state at the moment is I am working on two Linux wifi drivers, for
zd1211rw and ipw3945 to add the Penumbra packet transfer stuff as a
proof of concept, and that the usermode daemon SSL and upload stuff is
done and under GPL. So it is quite early days but there is progress.
i'd highly recommend looking at the madwifi [3] driver as well, and
fortunately it makes this kind of extension very easy. there is also
a reverse engineering ath-driver HAL [4] for even more non-standard
tweaking of radio parameters if you want to _really_ avoid contention
in the usual 2.4Ghz bands by giving a finger to the FCC :P
I don't want to make any regulatory trouble. It should be fine just
using the ISM bands at normal powers using standard gear. I chose my
two POC drivers because I have the hardware :-) Assuming it can be made
to work I will document what needs to be done and hopefully someone who
works on the driver can consider to add it.
there is even an existing program that uses control frames in 802.11
for covert channel transmissions [5] that may be useful.
That is really cool, but it needs the packet injection capability in the
driver. Which admittedly is currently more available than my protocol
support in drivers. I will have a closer look at it.
last but not least, the latest madwifi drivers support virtual devices
[6], so you can have a client association, a master mode AP device,
and a raw monitor device all sharing the same physical radio hardware,
which may eliminate the need for driver tweaks when using Atheros
devices.
Yes I heard also that the Devicescape stack will support this, and I saw
in the ipw3945 driver there is hardware support but not yet software
support in the driver.
that way, although if you need to use persistent identities for secure
routing, an opportunistically shared RSA identity key (for
routing/control) could be used while keeping the single use RSA keys
(perhaps in a mode like ephemeral diffie hellman, with the transient
keys signed by the long lived identity key).
The problem here is that any kind of long-lived identity can be used to
destroy the privacy of what the node is doing. What might not violate
this privacy aspect is to have random "session keys" that are changed
every minute or so by every router, and use that for the purposes of
trying to work out what rate and tx power to use to service requests
that came with that router as the last hop.
-Andy
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
