WAMP is interesting to scale WebSocket (WS) application, going from 1 websocket procesus to several. You can do the same with Redis or else.
Otherwise said it allows to create clustered websocket (WS) applications.
E.g. two clients are connected to the same web chat room but via different WS servers, WAMP will allow to forward messages happening in one websocket server/processus to the other, otherwise their would be the equivalent of an IRC net split. You can do that with Redis too, but with WAMP “it just works”(tm).
- WS doesn't support natively RPC as «function call + return value»
- PUB/SUB is also nice to have, especially since it's cluster-aware.
> - Direct browser to browser communication.
There is a router and that is all, you don't have to setup your own (cluster aware) dispatch logic.
> Except it’s not, because everything goes through a router, so how’s that different from using an HTTP server in terms of moving parts?
It gives you the API to work as is and the speed of it for RPC is close enough. If you had to do it with HTTP, you'd have to code the linking mechanisme, make use you use keep alive and manually drop the headers.
> - Can work outside of browsers.
> So can HTTP.
Yes, but is has no routing system. You'd have to code it yourself, again. And since it's not websocket, make sure all clients use keep-alive (most default settings for lib such as urllib2 do not), create a standard for all the clients to talk to each others, drop the headers, agree on serialisation, include exceptions handling, wrap that in an async API. And even with keep alive, websocket is x10 faster than Ajax in my tests.
> - Allows independent microservices.
> Again, so does HTTP.
And again, you'll have to hack around HTTP to get this. HTTP is not made for this, it's made to be stateless. It's made to be text. It's made to be simple. You can do anything with HTTP, you could even use it to say, send the packet to sync a starcraft game LAN. But you don't, because it's not efficient. You can cut your meat with a spoon, provided you sharpen it and hold it in a weird way, and force. But you don't. You use knives.
> - Has push and pub/sub.
> Ok, but so does anything based on websockets, I don’t see how that’s an argument for this protocol.
You don't have primitive to do pub/sub with raw websocket. Websocket allo you to push data, but the registering logic, the serilialization, the exception hanlding and the routing are not included. WAMP is a standard for that.
It's not trying to be magical. It's not pretentious. It's not revolutionary. It's just that : a standard to do efficient RPC and PUB/SUB, with clean, simple API that works in the browser, and outside of it.
WAMP came up on Meteor's mailing list some time ago. One would compare it with Meteor's own pub/sub and rpc protocol called DDP (https://www.meteor.com/ddp).
I have used WAMP 1.0 for a few projects and converted some Play framework code to pure Java EE7 code. However I haven't used it in any of my recent projects because of support, I like losing the HTTP header, saves a fair bit of traffic.
he de facto open source WAMP router, crossbar.io, is written with Twisted, Python. For now it's Python 2.7 only, but Autobahn Python, the Python client, works with Twisted or asyncio (Python 3)
[+] [-] WhitneyLand|11 years ago|reply
To extend that reasoning, there are many things sockets may be better for but I'd like to hear the arguments specifically in support of WAMP.
[+] [-] amirouche|11 years ago|reply
Otherwise said it allows to create clustered websocket (WS) applications.
E.g. two clients are connected to the same web chat room but via different WS servers, WAMP will allow to forward messages happening in one websocket server/processus to the other, otherwise their would be the equivalent of an IRC net split. You can do that with Redis too, but with WAMP “it just works”(tm).
- WS doesn't support natively RPC as «function call + return value»
- PUB/SUB is also nice to have, especially since it's cluster-aware.
> - Direct browser to browser communication.
There is a router and that is all, you don't have to setup your own (cluster aware) dispatch logic.
edit: this might be helpful http://wamp.ws/why/
[+] [-] sametmax|11 years ago|reply
It gives you the API to work as is and the speed of it for RPC is close enough. If you had to do it with HTTP, you'd have to code the linking mechanisme, make use you use keep alive and manually drop the headers.
> - Can work outside of browsers.
> So can HTTP.
Yes, but is has no routing system. You'd have to code it yourself, again. And since it's not websocket, make sure all clients use keep-alive (most default settings for lib such as urllib2 do not), create a standard for all the clients to talk to each others, drop the headers, agree on serialisation, include exceptions handling, wrap that in an async API. And even with keep alive, websocket is x10 faster than Ajax in my tests.
> - Allows independent microservices. > Again, so does HTTP.
And again, you'll have to hack around HTTP to get this. HTTP is not made for this, it's made to be stateless. It's made to be text. It's made to be simple. You can do anything with HTTP, you could even use it to say, send the packet to sync a starcraft game LAN. But you don't, because it's not efficient. You can cut your meat with a spoon, provided you sharpen it and hold it in a weird way, and force. But you don't. You use knives.
> - Has push and pub/sub. > Ok, but so does anything based on websockets, I don’t see how that’s an argument for this protocol.
You don't have primitive to do pub/sub with raw websocket. Websocket allo you to push data, but the registering logic, the serilialization, the exception hanlding and the routing are not included. WAMP is a standard for that.
It's not trying to be magical. It's not pretentious. It's not revolutionary. It's just that : a standard to do efficient RPC and PUB/SUB, with clean, simple API that works in the browser, and outside of it.
And it's good at it.
[+] [-] imslavko|11 years ago|reply
DDP has clients in Objective-C, Java, Python and some other major languages, too: http://www.meteorpedia.com/read/DDP_Clients
https://groups.google.com/forum/#!searchin/meteor-talk/wamp/...
[+] [-] bbody|11 years ago|reply
[+] [-] sametmax|11 years ago|reply
The cool thing is that it's an open standard registered at IANA (https://www.iana.org/assignments/websocket/websocket.xml), and you can talk WAMP with clients in C++/Java/C#/PHP/JS.
It's pretty nice for the IoT and real time apps.
[+] [-] reedcat|11 years ago|reply