Peer-to-Peer Traces

Edonkey traces

These traces have been collected from a fake client, connecting to other clients, and asking for their lists of files. This was possible in 2004, but not anymore. They have been anonymised and converted to a common format.

The traces:

14-16 october 2003 : 3 days
09 december 2003 - 02 february 2004 : 56 days

Downloads

trace.txt.bz2 (42 MB) : 3 day trace containing all the snapshots. A snapshot is composed of TIME in yday:hour:minute (day 342 is 09 december 2003), ID is the client identity, NFILES is the number of files in the snapshot, and then all the files starting with their local identifier FID.
trace2.txt.bz2 (955 MB) : 56 day trace in the same format
num_client_info.txt.bz2 (24 MB) : the identities of the clients in the trace:
Each line contains: client_id key_id addr_id trace_id donkey_id
- client_id: ID used in the "ID" field of trace.txt and trace2.txt
- key_id: indicates whether is an IP ("IP") or an identifier ("ID"). It is an IP if we could connect to it, it is an identifier if it connected to us. Identifiers are less reliable, and should probably be discarded during an analysis of the trace.
- addr_id: a different number for two different IP addresses
- trace_id: trace in which the client appeared
- donkey_id: Edonkey uniq identifier, as generated by the client. When different from 0, it can be used to detect the same client using different IP addresses.
chunks.txt.bz2 (461 MB) : for every file MD4, the chunks composing the file. Not very useful...
num_file_md4.txt.bz2 (224 MB):

When analysing this trace, we strongly suggest to:

remove all clients which donkey_id appears with different addr_id
remove all clients with key_id = ID
keep only one of the clients sharing the same addr_id

An finally, a small bonus: settings.txt shows upload and download settings of MLdonkey clients, in kB/s (0 meaning unlimited). Free-riders would be those who set their upload to 1, the minimum value, they only represent 3% of the total...and those who set their upload to unlimited are also 3% !!

Bibtex (from DBLP)

The 56 day trace was analysed in a paper published in EuroSys'2006. If you are using it, you should cite the paper:

@inproceedings{DBLP:conf/eurosys/HandurukandeKFMP06,
  author    = {Sidath B. Handurukande and
               Anne-Marie Kermarrec and
               Fabrice {Le Fessant} and
               Laurent Massouli{\'e} and
               Simon Patarin},
  title     = {Peer sharing behaviour in the eDonkey network, and implications
               for the design of server-less file sharing systems},
  booktitle = {EuroSys},
  year      = {2006},
  pages     = {359-371},
  ee        = {http://doi.acm.org/10.1145/1217935.1217970},
  crossref  = {DBLP:conf/eurosys/2006},
  bibsource = {DBLP, http://dblp.uni-trier.de}
}

@proceedings{DBLP:conf/eurosys/2006,
  editor    = {Yolande Berbers and
               Willy Zwaenepoel},
  title     = {Proceedings of the 2006 EuroSys Conference, Leuven, Belgium,
               April 18-21, 2006},
  booktitle = {EuroSys},
  publisher = {ACM},
  year      = {2006},
  isbn      = {1-59593-322-0},
  bibsource = {DBLP, http://dblp.uni-trier.de}
}

The 3 day trace was analysed in a paper published in IPTPS'2004. If you are using it, you should cite the paper:

@inproceedings{DBLP:conf/iptps/FessantHKM04,
  author    = {Fabrice {Le Fessant} and
               Sidath B. Handurukande and
               Anne-Marie Kermarrec and
               Laurent Massouli{\'e}},
  title     = {Clustering in Peer-to-Peer File Sharing Workloads},
  booktitle = {IPTPS},
  year      = {2004},
  pages     = {217-226},
  ee        = {http://springerlink.metapress.com/openurl.asp?genre=article{\&}issn=0302-9743{\&}volume=3279{\&}spage=217},
  crossref  = {DBLP:conf/iptps/2004},
  bibsource = {DBLP, http://dblp.uni-trier.de}
}

@proceedings{DBLP:conf/iptps/2004,
  editor    = {Geoffrey M. Voelker and
               Scott Shenker},
  title     = {Peer-to-Peer Systems III, Third International Workshop,
               IPTPS 2004, La Jolla, CA, USA, February 26-27, 2004, Revised
               Selected Papers},
  booktitle = {IPTPS},
  publisher = {Springer},
  series    = {Lecture Notes in Computer Science},
  volume    = {3279},
  year      = {2005},
  isbn      = {3-540-24252-X},
  bibsource = {DBLP, http://dblp.uni-trier.de}
}

Internet Round-Trip Traces

I measured some latencies on the Internet in 2005. The software was installed on many home computers, that were working with other home computers. Latencies were measured as the best response time (in milliseconds) among a given number of either TCP or UDP requests. Unfortunately, there are very few triangles (three computers pinging each others), but it might still be of some use to some researchers.

The format is: source_IP destination_IP nbr_pings best_rtt

tcp.log.bz2 (111 MB): 17.542.023 TCP rtt
udp.log.bz2 (72 MB): 12.406.112 UDP rtt