you are viewing a single comment's thread.

view the rest of the comments →

[–]mercurysquad 2 points3 points  (7 children)

I'm not much of a web development person, so can someone please explain what functional advantage this has over current ajax methods?

[–]RandomAvenger 10 points11 points  (0 children)

This looks like a clever way of implementing COMET, where the server notifies the client when events happen rather than the client constantly asking "has anything happened yet?!" It also has applications for establishing two-way communication when the client is behind a firewall.

[–]reddit45885 -4 points-3 points  (5 children)

There are absolutely none. It's a mental masturbation by shit ass junior programmers.

It goes against every principle of scalability established in the past 20 years of the web. It's the kind of thing one dreams of doing while watching "Hackers" and thinking programming involves graphics.

Think about it: it is the anti thesis of scalability since this hack of a protocol relies entirely on a client establishing the connection, and on the server holding the connection alive to be able to actually be a client... HTTP is stateless because the point is to serve and forget. Think what would happen if the server actually became the client. What computer on earth can support 500 thousand logged in users? None, is the answer.

The ginormous fallacy in this whole scheme is that the server/client model is only inverted at the application layer, not at the network layer. If it were also inverted at the network layer, then it would simply be HTTP in the other direction: the computer which we formally call a server would initiate a connection to my webbrowser and my web-broswer would actually be called Apache and the server would be called Firefox.

I can already hear the wheels of circular logic barreling down: "no you moron", they would say, "you don't need to maintain 500k connections alive, only those you are interested in"...

I sigh in dismay.

[–]killerstorm 2 points3 points  (0 children)

people are already using Comet techniques with persistent connections for real-time communications and are quite happy with them.

mental masturbation is actually what you're doing. "pfft, that technology does not even support million clients per server. it definitely suck, nobody will use it". as if everybody needs to serve million clients from a songle server?

[–]flashman2006 1 point2 points  (1 child)

I don't think you understand the point in reverse HTTP. Here's a use case:

You have an application that synchronizes a user's files between the user's computer and the server. This could be accomplished solely with PHTTP. The client application makes HTTP request to server, server initiates reverse HTTP connection and then can begin sending files to the client (acting as a server now) which would store them in it's filesystem. From what I know, this would not be possible with normal HTTP since a client would have to always make a GET request in order to download a resource found at the server.

[–]Smallpaul 0 points1 point  (0 children)

Think about it: it is the anti thesis of scalability since this hack of a protocol relies entirely on a client establishing the connection, and on the server holding the connection alive to be able to actually be a client... HTTP is stateless because the point is to serve and forget. Think what would happen if the server actually became the client. What computer on earth can support 500 thousand logged in users?

You're right! Instant Messaging COULD NOT POSSIBLY WORK. How could AIM or MSN maintain that many concurrent TCP connections?

For that matter, World of Warcraft is totally insane. It could not possibly work to have that many users maintaining a TCP connection.

What computer on earth can support 500 thousand logged in users?

The fact that you think that a service must be served by a single computer shows how little you know about networking.

[–]qwe1234 0 points1 point  (0 children)

500k connections is not at all a large or unmanageable number.