Re: queueing and priorizing strategies

Arne Babenhauserheide <[email protected]>
Newsgroups gmane.network.gnutella.devel
Message-ID <[email protected]>
Am Montag, 15 de Oktober de 2007 20:28:55 schrieb Michael Rogers:
> > To include this in Gnutella: Could the leafs publish their receipts ("I
> > uploaded to that one" and "I downloaded from that one") to the Ultrapeer
> > and peruse the existing infrastructure that way? The UP could collect
> > them and push them back to the leafs, so a multi-step utility can be
> > calculated for neighbor leafs.
>
> Interesting idea. You'd have to be careful about collusion (you and I both
> claim to have downloaded 100 GB from each other in order to get faster
> downloads from everyone else), but the phrase "multi-step utility" sounds
> like you might be considering something like max flow, which can be used to
> prevent collusion:
>
> http://www.sigcomm.org/sigcomm2005/paper-CheFri.pdf

You could just decide only to trust nodes from which you already downloaded, 
and only to trust them with the amount you downloaded from them. 

To be able to lie, they then have to contribute. And they can only lie as much 
as they contribute. 

Would that (possibly) work? 

> > Does your scheme work, if people in the utility chain can drop out (and
> > do so very frequently)?
>
> It depends on a few factors. First, how long do sessions last (especially
> the sessions of people who share a lot of files, which I suspect are likely
> to be longer than average)? 

We'd need answers from some of the LW guys in here to answer that. They have 
more current statistics. 

As far as I know, it's about 2 hours for most, I don't know about uptime of 
sharers only. 

> Second, do peers have long-term identifiers 
> that persist across sessions (eg TLS certificates)? 

> Third, how long is the 
> typical delay between uploading to a peer and downloading from the same
> peer, or vice versa? (In the download mesh I guess it will typically be on
> the order of a few seconds, but if we're talking about uploading and
> downloading different files, how often does this happen, and what can we do
> to make it more common?)

In the download mesh it can be very long, because there are a few hudnred 
sources, and I download from many who don't download from me, and vice versa. 

> > Would it then be better to just push the receipt information via the
> > existing inter-UP QRP infrastructre?
>
> So if I needed receipts for peer X I'd send out a query that would be
> routed via QRP, collecting the receipts?

This question mainly goes to this list. 

I mean: We already have an infrastructure to spread information (about the 
kind of files which are shared). Could the same or a similar infrastructure 
be used to publish information about the amount downloaded from people? 

How strong is the locality of nodes in Gnutella (similar nodes grouping 
themselves together)? 

Could it be improved (for example by measuring the difference (i.e. xor) 
between QRTs and mainly connecting to nodes with low difference (means: 
Mainly connecting to people who share similar files)? 

> >How does this affect pseudo-anonymity?
>
> If the receipts only contain the number of bytes transferred, not the
> details of the files, it doesn't seem to me that it's a major threat to
> privacy - no worse than the information reported to a BitTorrent tracker,
> anyway.

It would be possible to identify major sharers that way, I think. 

It might be important to keep this in consideration. 

Best wishes, 
Arne
-- 
Unpolitisch sein
Heißt politisch sein
Ohne es zu merken. 
- Arne Babenhauserheide ( http://draketo.de )
-- Weblog: http://blog.draketo.de

-- Mein öffentlicher Schlüssel (PGP/GnuPG): 
http://draketo.de/inhalt/ich/pubkey.txt


[Non-text portions of this message have been removed]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.