On Tuesday, January 16, 2007 Andy Green wrote:
> But the Wifi device should only transmit the packet when it hears
> no carrier from another transmission. So there is a random delay
> before a box decides to fulfill the request it heard: in the
> meanwhile it might hear another box fulfilling the request, it
> which case it cancels its scheduled, delayed transmission.
Andy, could you please elaborate on this a bit more? This cancel
part, I mean. The scenario that concerns me here is when you have four
hosts A-B-C--D-... in a row, with C reachable from A, B, and D, but D
reachable only from C. Let's say B broadcasts the request and A
retransmits it first. Then C hears that retransmission and cancels
its own one - which causes the request to never reach D, whereas
with full broadcast C is supposed to be a relay node for D (and
possibly quite a few nodes behind it).
Of course, if there is just a single unreliable link between two
parts of the networks, the broadcasts are not supposed to be reliable
in the first place. But it is one thing to have them failing from time
to time due to the channel losses, and quite another - to have them
succeed only with probability of 1/N, where N is the number of nodes
in a fully connected subnet to the left of '--' link above. Then this
1/N is the probability that relay node C will be the first to
rebroadcast the request, which will be the only case when this request
will reach the subnet D. If anyone else rebroadcasts it first, the
request will be lost, and with enough hosts in a subnet, the subnets
behind 'C' and 'D' will end up being effectively disconnected despite
the presence of a perfectly good link that connects them.
On the other hand, some kind of "response squelch" seems to be
a necessary part of response rebroadcast. Otherewise - for example
in the case of the RoofNet - all 37 nodes will end up rebroadcasting
all the responses, and when the responses represent a gigabyte file,
the resulting x37 overuse of the bandwidth can severely cripple the
delivery of this file (and anything else happening on the network).
So the scheduled responses clearly have to be somehow canceled once
at least one copy of a particular response packet reaches the
requestor.
Could you describe your scheduled transmission cancellation
plan in more detail?
Best wishes -
S.Osokine.
18 Jan 2007.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Andy Green
Sent: Tuesday, January 16, 2007 6:41 AM
To: theory and practice of decentralized computer networks
Subject: Re: [p2p-hackers] Penumbra Wifi Network
Bill Mccormick wrote:
Hi Bill -
> I don't quite understand the source of the broadcasts - is there a
> single node which will originate broadcasts and listens for requests
> from effectively anonymous users?
>
> Or can any node originate broadcasts based on a received request?
Yes every node is a complete peer, and can decide to transmit.
> It sounds like you would be flooding all requests and broadcasts over
> the network, is this correct? If so, how do you prevent flooding
> loops?
If I understood "flooding loops", the general idea at the moment is that
aside from advertisements of content, which are sent out every few
seconds, transmissions are only occurring in response to a request heard
from nearby. So perhaps several boxes have the part that is requested
and might want to transmit it.
But the Wifi device should only transmit the packet when it hears no
carrier from another transmission. So there is a random delay before a
box decides to fulfill the request it heard: in the meanwhile it might
hear another box fulfilling the request, it which case it cancels its
scheduled, delayed transmission.
There are no automatic retries and no acknowledgement... if one or more
nearby box still wants the block after it has been sent by someone,
perhaps because they are a bit too far away from that guy, then they
send another request and the process begins again, hopefully with a
larger population of nearby boxes (including one closer to the
requestor) now being able to consider to fulfill it after the first
transmission attempt gave them the packet.
For each transmission all nearby boxes that are interested in that
upload can take the transmission without generating any further traffic.
-Andy
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
