Anatomy of the Skype network

This is a follow-up to my earlier post on “Skype Network Problems“. I’ve just remembered an analysis of the Skype P2P Protocol from the Columbia University that might give some insight on what’s wrong. The subsequent quotes are taken from: “An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol“, Salman A.Baset, Henning Schulzrinne, 2004, Columbia University

Login is perhaps the most critical function to the Skype operation. It is during this process a [skype client] authenticates its user name and password with the login server, advertises its presence to other peers and its buddies, determines the type of NAT and firewall it is behind, and discovers online Skype nodes with public IP addresses. We observed that these newly discovered nodes were used to maintain connection with the Skype network should the [super node] to which [the skype client] was connected became unavailable.

Each skype client can become a super node if it has sufficient CPU cycles, memory and bandwidth to spare. The super nodes form a fully meshed network (each super node knows the IP of each other super node that is logged on).

We observed that a SC must establish a TCP connection with a [super node] in order to connect to the Skype network. If it cannot connect to a super node, it will report a login failure.

So, if there is a problem with reaching super nodes in general, the whole network goes down. Now since a skype client can connect to the network once in a while, there is no general failure of the super nodes, but appearantly, we get disconnected from all neighboring super nodes after a short period of time.

After a [skype client] is connected to a [super node], the [skype client] must authenticate the user name and password with the Skype login server. The login server is the only central component in the Skype network.

As we can log on to the network for a couple of minutes, the problem is unlikely to be with the login server alone, although they constitute the single point of failure in the network. (otherwise, we couldn’t log in at all like when entering an unknown username/password combination). Finally, the entire super node mesh network us bootstrapped by seven hard-coded super node IPs.

After logging in for the first time after installation, [the host cache] was initialized with seven IP address and port pairs. We observed that upon first login, [the host cache] was always initialized with these seven IP address and port pairs except for a rare random occurrence. In the case where [the host cache] was initialized with more than seven IP addresses
and port pairs, it always contained those seven IP address and port pairs. It was with one of these IP address and port entries a [skype client] established a TCP connection when a user used that [skype client] to log onto the Skype network for the first time after installation. We call these IP address and port pairs bootstrap super nodes.

Consequently, there seems to be a problem that certainly involves the bootstrap super nodes as a client always tries to reach these to connect to the network. I believe that the network suffers a combination of unstable state of the overlay network and high loads on the (bootstrap) super nodes.


7 thoughts on “Anatomy of the Skype network

  1. A colleague in the US now has skype service, but the number of reported users is down to 180,000 !!!!!!! Meltdown or what???

  2. umm… I can’t say yes or no. Both work different. MSN has just the single central login server (there might be a couple of them as backup, but just one entity to send a “login” message to). If this one is not reachable because it’s down or the DNS records don’t point to the correct IP or you simply can’t reach that IP address, then MSN is “down” for you. But since I don’t know how much fallback capabilities Microsoft and Skype each have available to backup their single points of failure, I can’t tell whether MSN could fail similarly.

  3. Skype is down in S. Korea as well, despite rumors that this is primarily affecting Europe and no users in US “appear” affected. However, my spouse in CO, USA says it was up and down showing users connected then not as of 0800CDT.

  4. I succesfully “skyped out’ed” Edinburgh from Poznan- Poland : it was a good quality call, despite the applet in the panel WinXP going off and on. It was 30 minutes long on August 16, approx. between 20:15 and 21:00 this evening. Warsaw time zone.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s