Page 1 / 2   >   >>
OldPOTS 12/5/2012 | 3:39:22 AM
re: Google: Resistance Is Futile... Just join Google and get SPIM/SPAM from everywhere those hackers can hide?

mr zippy 12/5/2012 | 3:39:21 AM
re: Google: Resistance Is Futile... btw, I tried to point this out to the XMPP developers a while back, and they'd already decided that they were going to fix these problems by spitting messages into a header and a body, and then allowing the body to be encrypted end-to-end. Unfortunately that doesn't protect against the centralised server know who you're talking to, which is still quite useful to an adversary. It's still not as end-to-end security as would be useful and ideal.

They also said they were introducing server redundancy. That sounds fine until you realise that they actually weren't solving the problem of your conversation continuing across a server failure. Who wants their conversation cut off mid sentence, when some server somewhere has failed, when they've still got an IP path to their IM peer ?

Because they were so stuck in the "client-server" mindset, they couldn't see how adopting a proper peer-to-peer application architecture would make these problems just disappear, rather than them having to develop work arounds that never fully solve these problems.
mr zippy 12/5/2012 | 3:39:21 AM
re: Google: Resistance Is Futile... IM type communications is naturally peer-to-peer. You and you IM session partner are both transmitters and receivers, or both "clients" and "servers" at the same time.

If you can directly communicate with your peer (as you can on the Internet, that's the way it is designed), why should communications go through a server, which introduces both a single point of failure as well as a performance / scalability bottleneck. It also adds another party who's privy to the conversation, and therefore needs to be trusted. That might be a reasonable requirement for some corporations who wish to record their employees IM conversations (although you have to wonder how they're controlling what their employees might be showing or telling outsiders after they leave work for the day).

The XMPP model always involves a server, with all messages going through the server. If the server fails (which has happened to me), you IM session fails, even though you may, or are actually likely to have a direct IP path still available between you and your IM session peer. Last I looked into it, it only supported encryption between IM clients and the server. IOW, you might think you have a secure conversation, but reality is the security is not and could not be guaranteed to be end-to-end, and end-to-end is all that you care about - you don't want anybody else other than your IM session to be able to see what you're typing. You had no assurance that your IM session peer also was using encryption with the server. Regardless, the server needed to perform decryption to route the messages anyway.

A hybrid XMPP architecture might have been better, where a server is used to track presence and location, and then the IM sessions were established directly between "clients". That being said, the various SIP options, including pure and simple DNS, are probably ideal, as SIP follows the Internet peer-to-peer model.

It seems to me that XMPP/Jabber has been designed by people who don't understand or aren't aware of the fundamentals of how applications are designed to fit the Internet model, which if followed, gives them robustness against localalised and transient network failures, and scalability. For them, the Internet is purely "client / server", so that is how they've built a naturally peer-to-peer application.
mr zippy 12/5/2012 | 3:39:20 AM
re: Google: Resistance Is Futile... I did ask about any architectural documents that discussed design decisions, and got the "refer to the RFC drafts". They were full of client-server model descriptions, so I realised that it was probably going to be an uphill battle trying to suggest a peer-to-peer model, so I didn't persist.

Regarding the redundant server/end-to-end discussion, I'm pretty that was on slashdot. Who knows, I could have been discussing it with one of the XMPP/Jabber developers.

Anyway, I think it is a good example of where the "default" client/server model is inadequate for Internet based applications. The default should be peer-to-peer (with the benefit of robustness and scalability), with the introduction of client/server only when the problem can't be solved or solved easily with a peer-to-peer architecture.
optodoofus 12/5/2012 | 3:39:19 AM
re: Google: Resistance Is Futile... Mr. Zippy,

It sounds like a great business opportunity to me. Instead of venting on the LR chat room, why don't you get out in your garage and start making it happen?

The one problem I see with peer-to-peer is who-ya-gonna-call when it doesn't work? If there is no central point of control, then there is no one responsible for making sure the service works. It's usually not a problem for the tech savvy, but could be a major problem for the average computer user.

spelurker 12/5/2012 | 3:39:17 AM
re: Google: Resistance Is Futile... > It sounds like a great business opportunity to me.

Not really. It's not a good business opportunity to make an open-interface peer-to-peer application, because there's really no way to make money.
This is probably why the designers went with a client-server approach. They work for some company, and their company can make money either by operating the servers or by developing a robust/scalable server application. So naturally, they are thinking in that direction.
optodoofus 12/5/2012 | 3:39:17 AM
re: Google: Resistance Is Futile... > Not really.

Exactly. And that is why I said Mr. Zippy should work on it and didn't hightail it out to my own garage to do it myself. (This is the problem with sarcasm in the written medium; if you don't apply thickly enough it has no effect; too thick and you look mean.)

zwixard 12/5/2012 | 3:39:16 AM
re: Google: Resistance Is Futile... The world is not black and white but a mixture of colors. So are the software applications.
For IM and VoIP, the presence part of the solution suits the server model, which is a database application. The usage part is best for peer-to-peer.
lightreader101 12/5/2012 | 3:39:16 AM
re: Google: Resistance Is Futile... Mr. Zippy,
Conceptually you are correct: peer-to-peer model is more efficient, secure, and attractive than the client-server-server-client model.
In reality, pure peer-to-peer model has limitations and must utilize various tricks to bypass them. For example, how can two users behind NAT communicate, if their NAT servers change local port mapping depending on destination IP & port numbers? In addition, how can a Skype user logon to a new PC and find all his/her contact entries show up? All those things need the help from one or multiple middle guy(s) and servers.
It's not a news that Skype asks all users to agree on Article 4 (Utilization of your computer) of their End User License Agreement. Basically it allows any PC to be the middle guy for Skype network.
Therefore, it could be hard to argue which is more secure and efficient--the model of using random middle guys or a model to use trusted servers (note: end-to-end encryption still possible on the server model). It could be a serious security concern if your equipment is selected as the middle guy at times for unknown communication.
An enterprise may utilize its own XMPP servers for internal and/or external communication but disallow employees to open any peer-to-peer communcation applications.
rwelbourn 12/5/2012 | 3:39:15 AM
re: Google: Resistance Is Futile... SIP/SIMPLE-based IM is not necessarily any better than XMPP; it's just a different protocol, but in reality it operates in much the same way.

Although SIP can, in theory, operate in a peer-to-peer manner, in practice it almost always goes through some kind of server, for reasons of authentication, registering presence, registering location, and (not least) NAT traversal.

Both SIMPLE and XMPP use centralized servers for message passing; SIP MESSAGE packets go exactly the same route as INVITEs, REGISTERs, NOTIFYs and SUBSCRIBEs.

Rob W.
Page 1 / 2   >   >>
Sign In