On 12/22/2010 9:54 PM, Julian Cain wrote:

On Dec 23, 2010, at 12:33 AM, Salman Abdul Baset<sa2086@columbia.edu> wrote:

...

On Thu, 23 Dec 2010, Julian Cain wrote:

...

Here I display some of todays work: http://www.youtube.com/watch?v=YHpFIMlItrM

Cool stuff.

My first guess at why Skype super node numbers are decreasing at this time of the year are that most Skype super nodes run in universities and it is the end of the academic semester. So students are shutting down their machines and Skype super nodes. Infact, it is safe to say that if the universities cracked down on Skype, there will not likely be enough super nodes to sustain the Skype network.

There are ~100,000 standby supernodes at any one moment also the hardcoded supernodes are for the most part installed into universities as you state. I believe this to be an automated event.

If you compare which supernodes went down to those that didn't the version numbers are similar. I've captured these packets and decrypted them and currently looking into my findings.

Most of the supernodes were non-responsive at ~12:00 EST. There were only ~2k routing traffic at the peak of this event and the network requires ~71,000 to support peak load hours.

It will be interesting to hear what they claim happened. I'm not an official spokesperson for Skype, so I can't really say more

It is fairly common knowledge that many people running the current version of the Windows client experienced a crash last night at around the same time. This matches Skype's public message at http://blogs.skype.com/en/2010/12/skype_downtime_today.html "many of them were taken offline by a problem affecting some versions of Skype". Not surprisingly, a whole lot of the nodes run Windows and thus the fraction of supernodes which are running Windows is also high. More clients trying to reach supernodes than there is supernode capacity looks exactly like a DDOS against the supernode addresses, of course. This is a common restart failure mode for all types of network systems... one must always balance the reconnect backoff times between the risk of flooding the servers (in this case, distributed out to supernodes in a p2p system) and the user experience of taking forever to reconnect after a local network outage (which may be indistinguishable from a global server-side problem). than what's in the official blog... though it does say almost exactly what's above. Matthew Kaufman _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE