[geocar]

> 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".

[DyslexicAtheist]

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

[geocar]

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.

[mynameisvlad]

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.

[geocar]

> 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.

[lrem]

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.