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.