Slashdot Mirror
An Analysis of the Skype Protocol
zib writes "Ever felt a need to peek under the hood of your Skype client? This paper (PDF) explains all the details. Among other issues, it focuses on the NAT capabilities of Skype and audio compression."
← Back to Stories (view on slashdot.org)
other voip providers use a something called Session Initation Protocol which is an open standard, compatable with loads of clients even open source ones like kphone.
Even the routing can be done with open projects such as Asterisk. Skype is worthless proprietary tripe compared to these solutions.
I don't think that your phone call data goes through the supernode. From what I understand, the supernode is used to facilitate the connection between two clients which are behind NAT or a firewall. After the supernode hooks you up, it is a direct connection between the two clients, without the supernode involved.
What is the deal with supernodes, isn't there a peer to peer protocol that doesn't revolve around supernodes?
Because this type of tiered network is what works and scales well to thousands and millions of clients. The original Gnutella protocol was designed not to use "supernodes" or a tiered network structure and it was a miserable failure. The bandwidth and large latency required for all of the clients to communicate with each other (especially ones using 56K modems) easily overcame the usefulness of the network. The current Gnutella protocol now uses a tiered (layered) network where clients can become supernodes and this version actually works with tens to hundreds of thousands of people connected.
When creating a large, scalable network this type of protocol is what has been proven to work.
--
Join the Pyramid - Free Mini Mac
infested with jello like fishes no melotron wishes
That makes no sense.
Lets say I'm firewalled and you're firewalled. Neither of us can open any ports. I want to call you. As a result, we both connect to a supernode, and send and receive data through the supernode. The supernode sees it all.
I checked out Skype's EULA as found on their website.
The only thing relating to third party software that I found was this:
2.4 Third Parties. You acknowledge and agree that the Skype Software may be incorporated into, and may incorporate itself, software and other technology owned and controlled by third parties. Skype emphasizes that it will only incorporate such third party software or technology for the purpose of (a) adding new or additional functionality or (b) improving the technical performance of the Skype Software. Any such third party software or technology that is incorporated in the Skype Software falls under the scope of this Agreement. Any and all other third party software or technology that may be distributed together with the Skype Software will be subject to you explicitly accepting a license agreement with that third party. You acknowledge and agree that you will not enter into a contractual relationship with Skype or its Affiliates regarding such third party software or technology and you will look solely to the applicable third party and not to Skype or its Affiliates to enforce any of your rights.
Basically, you have to explicitly accept a license agreement with the third party. They say nothing in here about installing and using 3rd party software on your computer without your consent.
There are other solutions which'll do essentially what you want. One option is to have connections rotate round-robin style, rather than by bandwidth. That way, if you can go by 5 paths, each path gets 1/5th of the traffic, making it much harder for evesdroppers.
A second option is to use kernel or userland IPSec, so that all connections are secure. IPSec is pretty solid and it is doubtful anyone would be able to break into such traffic.
Supernodes are just a load-balancing mechanism. Not a very good one, because it's a two-state system, but it works. Networks have developed routing and QoS protocols to handle exactly the kind of information P2P is approximating with the supernode scheme. It would seem to make much more sense to use mechanisms people have worked on for much longer to get right.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
FYI, if you want to look at the "registry" info for Skype on Linux, it's in $HOME/.Skype/shared.xml.
Generally speaking, end users are at the very bottom of a long hierarchy of ISPs and pipes. For example: UUNET -> AT&T -> Your local ISP -> You. As such, generally speaking, you are a leaf on a very large tree that may span several classes of IP networks. If a peer were to be used as a super node, it would mean that the data send from A to C would travel like this: A -> ISP -> AT&T -> UUNET -> Verizon -> Bell -> ISP -> B -> ISP -> Bell -> Verizon -> SomeOtherCarrier -> SomeOtherLocal -> ISP -> C.
It makes no sense since in all likelyhood, UUNET, Verizon and SomeOtherCarrier are all on the same backbone, one or two hops away from each other.
It only makes sense in a LAN situation, like in Campus setups where there are nodes that are 'above' other nodes hierarchically: like if someone has inbound Internet over one box and distributes the connection to his dorm house connected to 8 other computers.
And aside from that, Skype coms are encrypted. No third party software can intercept a properly encrypted message. That's the whole point of PKI, to avoid man in the middles.
Not necessarily. There exist ways to get through a double NAT environment. We developed one such system for an engineering thesis; for documentation on another see the "STUN" RFC
Um, actually RTFA.
In most cases the voice packets go direct leaf node to leaf node.
However if both are behind NAT firewalls then they can't directly talk to each other, and the Skype protocol seems to pick another Skype users machine (picked by some scheme that probably isn't publically described anywhere) and route the packets through them.
There's no security problem with doing this (the packets are end-end encrypted), it just takes longer and is more likely to congest, and it takes up bandwidth at the extra users network.
Really, IMNHO, NAT is a real menace. I'm really looking forward to IPv6 which doesn't have all this garbage; should be here by 2100 I reckon.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"i've seen someone experimenting with this before. it's actually not too difficult to do once you have two computers that are both trying to set up the connection. how to alert the second computer that the first wants to initiate a connection is the challenge. in this case the supernode seems to be responsible for that aspect.
basically each computer attempts to initiate a connection to the other computer on a port that has been agreed to in advance. the first computer to attempt will fail, due to the firewall on the other end. however, his firewall will now be expecting return traffic originating from the port that his computer attempted to connect to. therefore, the second connection attempt, from the other computer, will succeed. now, both firewalls are allowing return traffic through in response to a connection initiated from inside the firewall. all the supernode has to do is allow for negotiation of timing and source and destination port numbers, and the rest is quite simple.
If I don't put anything here, will anyone recognize me anymore?
If you run Skype on Linux or Mac OS X, it is reduced to using high ports anyway, so it's easy to block. An example iptables command line would be
(Caveat: Check your local servers, use passive FTP, modify this if you actually want to use P2P, etc.)Every gateway may have different timeouts for NAT UDP port binding, right?
The PDF doesn't explain how it's done, but it's rather simple, and is explained in the STUN RFC:
1. Open a socket, and tell the server, hi, i'm here, reply to the same address you received this message from, and tell me what that address is (let's call this address REF_ADDRESS_A).
2. Sleep for some time...
3. Open a second socket, and say, hi, i'm here, reply to the same address you received this message from AND to the old address(REF_ADDRESS_A)
If the first opened socket receives the message as well, this means the binding is still valid.
Increase the timeout and try again.
Otherwise, decrease the timeout and try again.
Eventually, it finds the right timeout for the binding.
Having said that, a proper app should really run this routine periodically, because network elements may change.
I love burekas in the morning
I've seen one Skype supernode in action and was pretty impressed by the bandwidth it was using. It was getting more than 15000 connections an hour, coming close to saturating its 100 mbps pipe. Which is kind of okay if you're paying a flat rate for access, but if you're paying by volume, I suggest that you take measures to avoid becoming a supernode. It's easy enough to do so. (On Linux, just block the high ports you're not using yourself. On OS X, activate that firewall.)