Hacker News new | ask | show | jobs
by Systemic33 3086 days ago
Microsoft used centralised servers because the Skype prior to that was a curse to mobile devices running on battery power. Particularly cellphones.

Skype worked as a p2p network, where some peers where marked as super peers and would help with peers behind firewalls (UDP-holepunching), and routing through the super peer. If your phone became a super peer, you could expect to essentially work like a server, with the "benefits" of increased bandwidth usage and power usage. Not exactly what you want as a mobile user.

So Microsoft had to change the architecture (which wasn't designed with mobile devices in mind) into a more centralised approach that could work with mobile devices.

6 comments

This doesn't explain why after the change Skype started routing calls between machines on the same LAN through Microsoft servers.
It is difficult to make a p2p app on a mobile device work even between devices on the same LAN.

A simplified explanation: Mobile devices will often ignore almost all incoming network traffic to reduce battery usage. The only way to reliably communicate with the device is through a centralized push notification service (e.g. APN and GCM).

I tried to make a demo app to perform very simple HTTP p2p and found this difficult on iOS. When an app is backgrounded you have ~17 seconds to stop execution or the OS will kill any active threads UNLESS the activity is among the Apple permitted exceptions. (Note that there is no iOS SyncThing app). In Android it is possible to use IntentService as a single threaded background HTTP server. It works for the most part but can be a little flakey. I'm not 100% sure how the OpenGarden SDK accomplishes this but I'm interested. My guess is that it makes heavy use of Bluetooth, which is one of the Apple permitted exceptions to the backgrounding rule.
> there is no iOS SyncThing app

There’s fsync() but it only syncs when you launch the app - what I think you meant is “there’s no continuously syncing iOS SyncThing app”.

Yes, thanks for the clarification. Continuous/background syncing is the difficult task.
Why not perform the invoking and setup of the call via a server, but then perform the actual call on p2p once the device is awake and the app on the foreground?
I am not sure why maintaining a TCP connection to Google or Apple is somewhat more battery friendly then maintaining it to your own server, or providing a TCP-server to provide some service for someone else. (UDP is different here)

I am using CSipSimple to my own server, battery usage is the same. Yes this is anecdotal evidence, but one can always check.

I guess this changes the moment you have 100 apps, each doing 'just a quick ping to my server time to time'.

Unfortunate result is hundred of apps waking up the phone ever 20 seconds and transmitting data nonstop. Sigh.

SyncThing seems to do fine on my smartphone in my home LAN.
One thing that might explain this is that your phone could be pulling data from your computer, rather than your computer trying to connect to your phone to push data to it.
Quit the b/s, will you. It's not difficult at all.

You use a central server to do the discovery and bootstrap the connection between two devices. For each device it looks like they are connecting out. This works for UDP and this works for TCP. It works both for NAT'ed and LAN peers. For the latter it works 100% of time. This is a 10 year old tech. It worked back then and it works now.

> Quit the b/s, will you.

We ban accounts that are uncivil like this, and you've done it a lot in the past, though happily not in the recent past, so please just don't do it at all.

https://news.ycombinator.com/newsguidelines.html

I disagree with your assessment of my remark as "uncivil".

If I read you correctly, you seem to have significantly lowered the plank for what you ban people for. What the OP said was a complete factual garbage showing an utter lack of understanding of the subject he is so confidently commenting on. So this was, by any conventional definition of the term, a bullshit. How can this conceivably be a cause for a ban?

The bar hasn't changed. "Quit the b/s will you" was obviously an uncivil slap. If you don't think it is, please adjust your standard to the one that applies here, when commenting here, if you want to keep commenting here.

It's easy to point out that a statement is wrong without being disrespectful, if you want to, and so neither damage the community nor discredit the truth with personal bad behavior. That way we all can learn something.

Perceptions of what's uncivil can vary for legitimate reasons, e.g. differing cultural standards—HN is a highly international community. But for that very reason, we need people to err on the side of being respectful. The alternative leads to wars and ultimately the death of the forum.

Like the parent said, architecture change.

How Skype works, is how msn messenger worked, office messenger, then office communicator worked, then Lync, now skype.

They moved Skype to their existing infrastructure

They made a decision to ditch P2P and route all calls through their servers. Local calls would fall into the "P2P" umbrella.
They had huge stability problems with peering nodes running outdated software causing huge instability which they couldn't fix.
Yup. The whole P2P and Supernode architecture didn't just fail when it came to mobile devices. The Christmas 2010 outage was also caused by the reliance on supernodes.
I think it was a patent issue. No one is allowed to use p2p for chat.
It does look like IBM does own a p2p instant messaging patent[1]. So I think this checks out.

- https://www.google.ms/patents/US7675874

There was just a comment thread (on the slack outage article) recently discussing why there are no good p2p chat programs.

This might be one reason why. Fuck software patents.

It is more that without centralized servers, if that's what you mean, you have a lot of ux disadvantages.
and offline delivery, which is a big big thing.
Are there any European p2p instant messengers that don't accept non-EU customers? That patent obviously wouldn't apply and it would be a good move to capture a nice market.

Edit: There's https://tox.chat but I have never used it/always forget it exists. Antidote/Antox fas clients for iOS/Android.

The claims in that patent seem to be fairly easy to work around.
And then you get to risk defending that in court against Intel’s lawyers, who are on retainer.
Pedantry: There is only one independent claim, making it even easier.
It's remarkable that companies can "own" things so fundamental, and obvious in computing--even if they don't actually utilize their IP's.

"Hey guys, I've got a patent for talking from one machine to another over a connection." (Don't give SCO any ideas.)

The purpose of patents was to foster innovation, not squander it.

What if Issac Newton and Liebniz had a "foundation" that owned the rights to every mathematical construct they discovered? How would the world function if we had to pay that foundation fees every time we used Newton's method, or Calculus? It'd be complete bureaucratic hell.

And further, coming from another angle, I bet you money there are prior implementations of P2P chat long before... 2005.

I was working for a large hardware company (I'm not going to name names) that typically files for hardware/firmware patents. There was a push for everyone to file more patents, even from the software teams.

I was working on an app that had graph-like data so we decided to use a graph database...nothing super innovative. My coworker, who apparently had a couple patents, said that we could probably patent this algorithm. I looked at him and said, how can you patent traversing nodes and vertices... that's graph theory 101?!

Big companies try to patent everything because its a metric they can use to show how amazing they are, and acts as blackmail (or cold war). If you sue me, I'll sue you.

Skype itself was founded in 2003, so I doubt this patent is valid.
I doubt that.
That doesn't sound like the correct explanation. It's not as if 90% of Skype users stopped using it on desktop computers.

Other explanations that seem plausible:

* IBM patent, as other poster pointed out.

* ability to monitor/censor users more directly (to stay in government's good graces)

* problems with peers invading privacy or taking other malicious actions

Why were mobile devices candidates for superpeers?
> So Microsoft had to change the architecture (which wasn't designed with mobile devices in mind) into a more centralised approach that could work with mobile devices.

As an engineer and software developer, I find this to be extremely unlikely.

If "super-peers" can already route traffic for others, it seems very likely they could simply route all traffic for Mobile users through some "super-duper peer", instead of routing all traffic for all users through some "super-duper peer".

Operators have no interest in being reduced to "dumb pipes" (as the industry calls it). So OP is correct, P2P overlay routing has traditionally caused headaches for network operators traffic shaping. Any P2P tech that reaches this kind of scale would run into serious scalability challenges due to operator throtteling.

- http://ieeexplore.ieee.org/document/6488287/

- https://www.computer.org/csdl/proceedings/p2p/2008/3318/00/3...

- http://www1.huawei.com/enapp/198/hw-079351.htm

If all the mobile traffic is being routed through a single Microsoft-controlled "super-duper peer", then there is no P2P traffic.

Or to put it another way: If I accept the choice is between routing mobile traffic to Microsoft, or no mobile-Skype support, I don't understand how it follows that all traffic needs to move through Microsoft, or no mobile-Skype support.

Because centralized and P2P architecturally are different beasts altogether. It'd be very hard to make a protocol that essentially did both, and centralization covers all use cases, so, as a company, it makes most sense to go with that.

I'm sure there were other reasons involved in the decision, I don't pretend to know them, but from a business perspective alone, you choose one connection methodology and you stick with it. Anything more is wasteful of resources.

> It'd be very hard to make a protocol that essentially did both

They already had a protocol that essentially did both.

Once you have forwarding/routing i.e. what Skype called "super-nodes", P2P is a clear superset of "centralised".

Anyone who says different doesn't know what they're talking about.

> I'm sure there were other reasons involved in the decision, I don't pretend to know them, but from a business perspective alone, you choose one connection methodology and you stick with it. Anything more is wasteful of resources.

I'm not speculating.

I've seen engineers do stupid things that don't make sense; I'm not arguing that there are stupid reasons for it, and I'm not going to argue that there's non-technical reasons for it.

But technical reasons? I don't buy it. I need some convincing: If one protocol (the P2P one) does both use cases, then you don't need another protocol just to handle one use case. That's just not how protocols work.

Very hard is a strong overstatement, nearly as dubious as saying they did it for the backdoors. It was either a license issue, patent issue, or just unwillingness to maintain the P2P code base in face of some features (mobile, conferencing) needing the centralised one too.