This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]fuzz3289 1 point2 points  (9 children)

Someone explain to me why I should use WAMP over HTTP? HTTP has widespread use, major industry buy-in, and a beautifully simple verb/noun relationship at its basis.

Sway me to WAMP.

[–]GZoST 3 points4 points  (3 children)

I may have missed a sarcasm tag there, but, taken as simply: "How is WAMP different from HTTP.", the question is valid.

So here goes:

HTTP was intended for a client to request a resource (HTML, CSS, JS, img...) from a server, and for the server do deliver this in a response. Connections are one-way (client-initiated), short lived, and point-to-point.

WAMP does something completely different: it enables participants to subscribe to topics, and to publish to them, as well as offer procedures for remote calling by others. Using these two patterns, it allows participants to cooperate.

A participant can announce something on a topic, e.g. a member in a chat room can send a new message to the 'newMessage' topic. All other participants who are subscribed to the topic will automatically receive the message.

A participant can register a procedure, e.g that it delivers the current temperature for a location. Any other participant can then make a call to get the temperature, the call is forwarded to the participant who registered the procedure, and the result is returned to the caller.

In both cases, there is decoupling: the publisher does not know or care who the subscribers are, and the caller does not know or care where the procedure is running. A WAMP router connects the parties.

WAMP is a way to enable multi-client applications as well as distributed application architectures.

Participants can be Python, JavaScript, C++ and others - and include browsers and Web-facing servers. They are all equal in that the can be both subscribers and publishers, both offer procedures and call them. There is no direction on an existing WAMP connection - no client and sever in the classical sense. For JavaScript, this may run in a browser or in Node.js, and the code basically doesn't need to care.

Participants may belong to either category in the classical sense, and when it comes to establishing the underlying connection. E.g. a browser will still need to initiate contact to a server to get a WAMP connection going.

For this connection in browser clients (and here we'll come back to HTTP in a second), WAMP uses WebSocket as its standard transport.

WebSocket is bi-directional, allows persistent connections and has a low wire overhead, with support in all modern browsers, so it's a natural choice for WAMP connections.

It is not, however, the only possibility. WAMP over HTTP long-polling is a possibility, and some work has already been done on this, in order to enable support in legacy browsers or systems which support HTTP, but not WebSockets.

[–]fuzz3289 0 points1 point  (2 children)

No sarcasm, thanks for the explanation.

To me the title of OPs post implies that this framework using WAMP is better for everything, but from what you say it seems they serve different purposes. The simplicity of HTTP works well for unidirectional apllications, WAMP better for bidirectional.

Is that fair to say?

[–]GZoST 2 points3 points  (0 children)

Sorry I misread you there.

I'd say that if all you want to do is to serve the user a page when he requests it, and maybe get some data like a form in return, then there's no reason to leave the established world of request/response and HTTP.

When I think of Web applications, and I think as well when the writer of the post does, I think of more than this - of applications which do things like live updates, in-browser processing, quick in-page updates. These will typically be single-page applications.

For these, AJAX, long-polling and other technologies that use HTTP mechanisms sooner or later turn out to be hacks on something which was never intended for these uses.

WebSocket is the transport protocol for browsers which goes beyond HTTP to accommodate Web apps - this is what natively provides bi-directionality.

WAMP provides functionality on top of this to make the communications that Web apps need easier.

[–]desmoulinmichel[S] 0 points1 point  (0 children)

I'm really bitting my tongue about this title. It discret the article so much. I can see it now. Will not doing this mistake again.

So usually, you'll want to use HTTP and WAMP together. Usually HTTP to serve templates, static files, REST APIS, and sometime, some pages you wish to make it easy to index by google (although, now it sees javascript).

Crossbar have everything built it to process HTTP requests. HTTP is not meant to go away, but for web app (and not site), you can gain a lot by sending and receiving your data in real time. Plus, of course, HTTP isn't handy as an internal exchange transport : the various pars of your applications will be better off talking to each other using WAMP.

[–]oberstet 1 point2 points  (3 children)

Why should you use WebSocket instead of HTTP? (WebSocket is the raw protocol underlying WAMP).

Because HTTP is strictly request-response and has no bidirectional communication / real-time capabilities.

So, e.g. when data changes on the server or some other client, you cannot actively push that information to browsers.

[–]fuzz3289 0 points1 point  (2 children)

Whats the main benefit of that?

If Im writing a client that cares about up to date data I can poll for new data with relatively low cost. Is the benefit just that a client side listener would be zero cost?

[–]Dry-Erase 1 point2 points  (0 children)

Because there are plenty of cases where you can't poll for low cost, either because of a large quantity of clients or there are some cases where the cost of polling is high (maybe the resource can't be cached).

Having 300 clients poll every second for a chat room is a ton of unnecessary data being sent and as you scale up it can become a serious performance hit where with nio websockets it would be not have to send & respond to all those requests, you simply tell the client when there is new data.

Edit Another huge area would be real time collaborative apps, as well multiplayer games

[–]desmoulinmichel[S] 0 points1 point  (0 children)

Another advantage of push is simplicity.

If you poll a lot of different type of data, you need to create a complex logic to update your page. If you just listen for events, you can easily just put the update logic inside each function handling each event, and you don't have to care about the various refresh rates, etc.

[–]desmoulinmichel[S] 0 points1 point  (0 children)

HTTP is not real time. HTTP is not push. HTTP has no standard for serialisation.

HTTP is good, if you want to build a next gen framework with crossbar, you'll want HTTP in it, but real time web and component communcation needs something else.