Web Application Messaging Protocol: Difference between revisions

Content deleted Content added
Added categories.
 
(72 intermediate revisions by 53 users not shown)
Line 1:
{{Short description|WebSocket subprotocol registered at IANA}}
WAMP is a [[WebSocket]] subprotocol registered at [[Internet Assigned Numbers Authority|IANA]],<ref>[https://www.iana.org/assignments/websocket/websocket.xml IANA protocols listing page]</ref> specified<ref>[https://github.com/tavendo/WAMP/blob/master/spec/basic.md WAMP basic profile specifications]</ref> to offer routed [[Remote procedure call|RPC]] and [[Publish–subscribe pattern|PUB/SUB]]. Its design goal<ref>{{cite web|url=http://wamp.ws/why/|title=Using WAMP you can build distributed systems out of application components which are loosely coupled and communicate in (soft) real-time.}}</ref> is to provide an open standard for soft real time message exchange between application components and ease the creation of [[loosely coupled]] architectures based on [[microservices]]. Because of this, it is a suitable [[Enterprise service bus|ESB]],<ref>[http://www.slideshare.net/KSDaemon/wamp-en-exported A few words about WAMP]</ref> fit for developing responsive Web applications or to coordinate multiple connected objects in the [[Internet of Things|IoT]].<ref>{{cite web|url=https://books.google.co.th/books?id=JPKGBAAAQBAJ&pg=PA172&lpg=PA172&dq=wamp+iot&source=bl&ots=8_zF1iZI_k&sig=2CgkqF4tlry5byIUXLiZjZVG2N8&hl=en&sa=X&ei=m0yyVN2JMI6QuASV3oLYBA&redir_esc=y#v=onepage&q=wamp%20iot&f=false|title=In this chapter [...] you will learn about the Web Application Messaging Protocol [...] which provide tools and services for developping IoT solutions}}</ref>
{{Advert|date=October 2016}}
 
'''WAMP''' is a [[WebSocket]] subprotocol registered at [[Internet Assigned Numbers Authority|IANA]],<ref>[https://www.iana.org/assignments/websocket/websocket.xml IANA protocols listing page]</ref> specified<ref>[https://github.com/tavendo/WAMP/blob/master/spec/basic.md WAMP basic profile specifications]</ref> to offer routed [[Remote procedure call|RPC]] and [[Publish–subscribe pattern|PubSub]]. Its design goal<ref>{{cite web|url=https://wamp-proto.org/intro.html|title=Using WAMP you can build distributed systems out of application components which are loosely coupled and communicate in (soft) real-time.}}</ref> is to provide an open [[Web standards|standard]] for soft, real-time message exchange between application components and ease the creation of [[loosely coupled]] architectures based on [[microservices]]. Because of this, it is a suitable [[enterprise service bus]] (ESB),<ref>[http://www.slideshare.net/KSDaemon/wamp-en-exported A few words about WAMP]</ref> fit for developing responsive web applications or coordinating multiple connected IoT devices.<ref>{{cite book|url=https://books.google.com/books?id=JPKGBAAAQBAJ&pg=PA172 |title=In this chapter [...] you will learn about the Web Application Messaging Protocol [...] which provide tools and services for developing IoT solutions|isbn=9780996025515|last1=Bahga|first1=Arshdeep|last2=Madisetti|first2=Vijay|date=9 August 2014}}</ref>
 
==Characteristics==
 
 
 
===Structure===
 
WAMP requires<ref>[{{Cite web |url=http://crossbar.io/docs/Router-Transports/ |title=Crossbar.io router transport ]|access-date=2015-01-12 |archive-date=2015-01-12 |archive-url=https://web.archive.org/web/20150112101645/http://crossbar.io/docs/Router-Transports/ |url-status=dead }}</ref> a reliable, ordered, [[full-duplex]] message channel as a [[transport layer]], and by default uses Websocket. However, implementations can use other transports matching these characteristics and communicate with WAMP over e.g. raw sockets,<ref>{{cite web|url=https://github.com/tavendo/WAMP/issues/63|title=WAMP can run over Raw transports instead of WebSocket. Each message is prefixed with a uint32 (big endian) that provides the (serialized) length of the following WAMP message.|website=[[GitHub]] }}</ref> [[Unix ___domain socket|Unix sockets]], or [[Push technology#Long polling|HTTP long poll]] or [[ZeroMQ]].<ref>{{cite web|title=We could use raw sockets, like the ones Ratchet is built on, but ZeroMQ is a library that just makes sockets easier. |url=http://socketo.me/docs/push}}</ref>
 
Message [[serialization]] assumes integers, strings and ordered sequences types are available, and hence default to [[JSON]]. Implementations often provide [[MessagePack]] as a faster alternative to JSON, but at the cost of an additional dependency.<ref>{{cite web|url=http://ksdaemon.github.io/wampy.js/#description|title=Wampy default serializer is JSON, but it also supports msgpack as serializer, but you need to include msgpack.js as dependency}}</ref>
 
Message [[serialization]] assumes<ref>[https://github.com/tavendo/WAMP/blob/master/spec/basic.md#serializations WAMP serialization]</ref> integers, strings and ordered sequence types are available, and defaults to [[JSON]] as the most common format offering these. Implementations often provide [[MessagePack]] as a faster alternative to JSON at the cost of an additional dependency.<ref>{{cite web|url=https://ksdaemon.github.io/wampy.js/#description|title=Wampy default serializer is JSON, but it also supports msgpack as a serializer, but you need to include msgpack.js as dependency}}</ref>
To identify remote procedures and PUB/SUB topics without conflicts, WAMP also needs an ID space allowing global assignment and resolution. Because the protocol is Web native - Websocket being the preferred transport - HTTP [[URI]]s are used.
 
===Workflow===
 
WAMP is architectured around client-clientclient–client communications, with a central software, the router, dispatching messages between them. The typical data exchange workflow is:<ref>[https://github.com/tavendo/WAMP/raw/master/spec/figure/sessions2.png WAMP internals bird view diagram]</ref>
 
* Clients connect to the router using a transport, establishing a session.
* The router identifies the clients and gives them permissions for the current session.
* Clients send messages to the router which dispatches them to the proper targets using the attached URIs.
* A client registers a procedure or subscribes to a topic, using serialised messages carrying unique IDs.
* A client calls a remote procedure or publishes on a topic with this ID.
* The router dispatches the message from one client to another.
 
The clients send these messages using the two high-level primitives that are RPC and PUB/SUB, doing four core interactions:
This can have subtle variations depending of the underling transport.<ref>{{cite web|title=The Long-Poll Transport is able to transmit a WAMP session over plain old HTTP 1.0/1.1. This is realized by the Client issuing HTTP/POSTs requests, one for sending, and one for receiving|url=https://github.com/tavendo/WAMP/blob/master/spec/advanced.md#long-poll-transport}}</ref> However, implementation details are hidden to the end user who only programs with the two high-level primitives that are RPC and PUB/SUB.
 
* '''register''': a client exposes a procedure to be called remotely.
* '''call''': a client asks the router to get the result of an exposed procedure from another client.
* '''subscribe''': a client notifies its interest in a topic.
* '''publish''': a client publishes information about this topic.
 
This can have subtle variations depending on the underlying transport.<ref>{{cite web|title=The Long-Poll Transport is able to transmit a WAMP session over plain old HTTP 1.0/1.1. This is realized by the Client issuing HTTP/POSTs requests, one for sending, and one for receiving|website=[[GitHub]] |url=https://github.com/tavendo/WAMP/blob/master/spec/advanced.md#long-poll-transport}}</ref> However, implementation details are hidden to the end-user who only programs with the two high-level primitives that are RPC and PubSub.
 
===Security===
 
As WAMP uses Websocket, connections can be wrapped in [[Transport Layer Security|SSLTLS]] for encryption. Even when full [[confidentiality]] itis not established, several mechanisms are implemented to isolate components and avoid [[Manman-in-the-middle attack|MITM]] attackss. Default implementations ensure that trying to register an already registered procedure will fail.
 
Routers can define [[Realm (disambiguation)|realms]] as administrative domains, and clients must specify which realm they want to join upon connection. Once joined, the realm will act as a [[namespace]], preventing clients connected to onea torealm be able to do RPC and PUB/SUBfrom using IDs defined in another for RPC and PubSub. Realms also have permissions attached, and can limit the clients to one subset of the REGISTER/CALL/PUB/SUBPubSub actions available.
 
Some realms can be only be joined by authenticated clients, using various authentication methods such as using [[X.509|TLS Certificatecertificate]], [[HTTP cookie|cookies]] or a simple ticket.
 
==Implementations=Routed RPCs===
 
Unlike with traditional RPCs, which are addressed directly from a caller to the entity offering the procedure (typically a server backend) and are strictly unidirectional (client-to-server), RPCs in WAMP are routed by a middleware and work bidirectionally.
 
Registration of RPCs is with the WAMP router, and calls to procedures are similarly issued to the WAMP router. This means first of all that a client can issue all RPCs via the single connection to the WAMP router, and does not need to have any knowledge what client is currently offering the procedure, where that client resides or how to address it. This can indeed change between calls, opening up the possibility for advanced features such as [[Load balancing (computing)|load-balancing]] or fail-over for procedure calls.
===Clients===
 
It additionally means that all WAMP clients are equal in that they can offer procedures for calling. This avoids the traditional distinction between clients and server backends, and allows architectures where browser clients call procedures on other browser clients, with an API that feels like peer to peer communication.
As WAMP main targets are Web applications and the Internet of Things, the first client implementations are in languages well established in these industries:
 
However, even with multi-tiers architectures, the router is still a single point of failure. For this reason, some router implementation roadmaps include clustering features.<ref>{{Cite web |url=http://crossbar.io/docs/Architecture |title=Crossbar node architecture |access-date=2015-04-20 |archive-date=2015-01-12 |archive-url=https://web.archive.org/web/20150112133407/http://crossbar.io/docs/Architecture/ |url-status=dead }}</ref>
{| class="tableizer-table"
 
|- class="tableizer-firstrow"
==Implementations==
! Library
 
===Clients===
 
As WAMP main targets are Web applications and the Internet of Things, the first client implementations are in languages well established in these industries (only WAMP v2 clients listed):
<!-- In each table, link one (often 1st) instance of terms, remove other WP:OVERLINK(s). -->
{| class="wikitable"
|-
! Client library
! Language
|-
| AngularWAMP
| [http://autobahn.ws/android/ AutobahnAndroid]
| [[JavaScript]] for the [[AngularJS]] framework
| [[Java (programming language)|Java]] for [[Dalvik (software)|Dalvik]]
|-
| [https://github.com/tavendo/AutobahnCpp AutobahnCpp]
| [[C++]] 11
|-
| wamplv
| [http://autobahn.ws/js/ AutobahnJS]
| [[LabVIEW]] (G)
| [[Javascript]] ([[Web browser|browser]] and [[NodeJS]])
|-
| AutobahnJS
| [http://autobahn.ws/python/ AutobahnPython]
| JavaScript ([[Web browser|browser]] and [[Node.js]])
|-
| AutobahnPython
| [[Python (programming language)|Python]]
|-
| wampy
| [https://github.com/bwegh/erwa Erwa]
| [[Python (programming language)|Python]]
|-
| Net::WAMP
| [[Perl]]
|-
| backbone.WAMP
| JavaScript for the [[Backbone.js]] library
|-
| CppWAMP
| C++ 11
|-
| Erwa
| [[Erlang (programming language)|Erlang]]
|-
| Jawampa
| [https://github.com/Matthias247/jawampa Jawampa]
| [[Java (programming language)|Java]]
|-
| [| Loowy
| [https://github.com/mogui/MDWamp MDWamp]
| [[Lua (programming language)|Lua]]
| [[Objective C]]
|-
| MDWamp
| [[Objective-C]]
|-
| Minion
| [https://github.com/Vinelab/minion Minion]
| [[PHP]]
|-
| rx.wamp
| [https://github.com/voryx/Thruway Thruway]
| JavaScript for the [[React (JavaScript library)|React]] library
|-
| Thruway
| PHP
|-
| WAMP POCO
| [https://github.com/Code-Sharp/WampSharp WampSharp]
| C++
|-
| wampcc
| C++
|-
| WampSharp
| [[C Sharp (programming language)|C#]]
|-
| [https://github.com/KSDaemon/wampy.js Wampy.js]
| [[Javascript]]JavaScript (browser only)
|-
| nexus
| [https://github.com/nicokaiser/wamp.io Wamp.io]
| [[Go (programming language)|Go]]
| Javascript (browser and NodeJS)
|}
 
The minimum requirements to build a WAMP client are the abilityabilities to use sockets and be able to serialise to JSON. This implies a lotThus, ofmany modern languages already havefulfill inthese requirements with their standard library what is needed to build a one. Additional features which would add dependencies, such as SSLTLS encryptions or Message PackMessagePack serialization, are indeed optional.
 
However, the persistent nature of WebsocketWebSocket connections requires the use of non -blocking libraries and [[Asynchronous I/O|asynchronous]] [[Application programming interface|API]]s. In languages with one official mechanism such as JavascriptJavaScript, Erlang or Go, it'sthis is anot simplean issue. But infor the oneslanguages with several competing solutions for asynchronous programming, such as Python or PHP, it forces the client author to standcommit forto a specific part of the ecosystem.
 
For the same reason, integrating legacy projects can also require work. As an example, most popular Web Python frameworks are using [[Web Server Gateway Interface|WSGI]], a synchronous API, and running a WAMP clientsclient inside a WSGI worker needs manual adapters such as [https://pypi.python.org/pypi/crochet crochet].
 
===Routers===
 
RoutersWhile routers can technically be embedded directly into the application code, and for this reason some client libraries also provide a router., Butthis sincearchitecture it'sis adiscouraged movingby part,the itspecification.<ref>{{cite isweb|title= bestBrokers usedand asDealers aare swappableresponsible blackfor boxgeneric justcall likeand oneevent wouldrouting considerand [[Apachedo HTTPnot Server|Apache]]run orapplication code.|website=[[NginxGitHub]] for [[Hypertext Transfer Protocol|HTTP]]url=https://github.com/tavendo/WAMP/blob/master/spec/basic.md#application-code}}</ref>
 
Since the router is a moving part, it is best used{{According to whom|date=November 2015}} as a swappable black box just like one would consider [[Apache HTTP Server|Apache]] or [[Nginx]] for [[Hypertext Transfer Protocol|HTTP]]:
{| class="tableizer-table"
 
|- class="tableizer-firstrow"
{| class="wikitable"
! Router name
|-
! Router
! Language
|-
| Bondy
| [http://crossbar.io Crossbar.io]
| [[Erlang (programming language)|Erlang]]
| Python
|-
| Crossbar.io
| [https://github.com/bwegh/erwa Erwa]
| Python (CPython and [[PyPy]])
|-
| Erwa
| Erlang
|-
| wampcc
| [https://github.com/Matthias247/jawampa Jawampa]
| C++
|-
| Jawampa
| Java
|-
| [https://github.com/voryx/Thruway Thruway]
| PHP
|-
| wamp.rt
| [https://www.npmjs.com/package/wamp.rt wamp.rt]
| JavascriptJavaScript (NodeJSNode.js only)
|-
| [https://github.com/Code-Sharp/WampSharp WampSharp]
| C#
|-
| Wiola
| [http://ksdaemon.github.io/wiola/ Wiola]
| [[Lua (programming language)|Lua]]
|-
| [https://github.com/christian-raedel/nightlife-rabbit Nightlife-Rabbit]
| JavascriptJavaScript (NodeJSNode.js only)
|-
| nexus
| [[Go (programming language)|Go]]
|}
 
[[Tavendo]], the company from which originated the protocol, is also the author of [[Crossbar.io]], which promotes itself as the de facto router implementation.<ref>{{cite web|title=Crossbar.io is the name of the most full -featured router|date=26 December 2014 |url=http://www.slideshare.net/sametmax/intro-wamp}}</ref> As they are promoting microservice -based architectures, Crossbar.io embeds a service manager for hosting and monitoring WAMP app components, a static file Web server, and a WSGI container. Being written with the [[Twisted (software)|Twisted]] library, it is one of the implementations that can be setupset up in production without a proxy, aiming to replace stacks such as Nginx associated with [[Process supervision|Supervisor]] and [[Gunicorn]].
 
==Use cases==
However, because Crossbar.io has Twisted as a dependancy, it can only run on Python 2.7, which means one must install and manage two Python versions in parallel to use the router and a Python 3 client on the same system.
 
Being a WebSocket sub-protocol, WAMP fits naturally anywhere one would use raw web sockets, as a way to synchronize clients such as Web browsers, push notifications to them and allow soft real-time collaboration between users.<ref>[https://github.com/voryx/angular-wamp WAMP and AngularJS]</ref> It has also the same limitations, requiring client support, which is missing for [[Internet Explorer]] versions older than 10.<ref>{{cite web|url=http://caniuse.com/#feat=websockets|title=Can is use websockets ?}}</ref> This is mitigated by the existence of [[Polyfill (programming)|polyfill]]s<ref>[https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills Web socket polyfills]</ref> using more portable technologies such as [[Adobe Flash|Flash]] or the use of HTTP Longpoll as a fallback. In that sense, WAMP is a competitor to [[Meteor (web framework)|Meteor]]'s [[Distributed Data Protocol|DDP]].
==Evolution==
 
WAMP also targets the IoT, where it is used in the same way as [[MQTT]]<ref>{{cite web|url=https://into.aalto.fi/download/attachments/12324178/Huang_Fuguo_thesis_2.pdf|title=Moreover, we compared WAMP with other registered WebSocket subprotocols (MBWS, SOAP and STOMP) in terms of the related features; and with other potential protocols (CoAP and MQTT), in terms of the related practical deployments.|access-date=2015-01-12|archive-date=2016-05-13|archive-url=https://web.archive.org/web/20160513073741/https://into.aalto.fi/download/attachments/12324178/Huang_Fuguo_thesis_2.pdf|url-status=dead}}</ref> as a light and efficient medium to orchestrate clusters of connected objects. The implementations in various languages make it suitable to control and monitor small devices such as the [[Raspberry Pi]] (in Python) or the Tessel<ref>[https://www.youtube.com/watch?v=WY7KzrRm8XY Tessel alarm app with Crossbar.io]</ref> (in JavaScript).
WAMP is currently in a transitional state, with the version 1<ref>[http://wamp.ws/spec/wamp1/#overview WAMP 1 specification overview]</ref> of the specification being deprecated in favour of the version 2.<ref>[http://wamp.ws/spec/ WAMP 2 specification menu]</ref> Because the two versions are incompatible, clients and routers implementing only one or the other cannot be used with each others, leading to fragmentation.<ref>{{cite web|url=https://groups.google.com/forum/#!searchin/autobahnws/android/autobahnws/h141CzuHmYA/viC6QbAnhSEJ/hy3j650tZB4J|title=We are waiting the second version for Android Client for a long time}}</ref>
 
And last but not least, WAMP can act as an enterprise service bus, serving as the link between microservices like one would do with [[Common Object Request Broker Architecture|CORBA]], [[ZeroMQ]], [[Apache Thrift]], [[SOAP]] or [[AMQP]].
Since, Crossbar.io, the reference implementation, supports only the version 2, old clients can seldom be used unless ported. Given that allowing an heterogeneous stack of components to communicate with each other is one of the WAMP selling points, having part of the supported languages only enabled to use WAMP 1 can be perceived as a barrier to adoption.
 
==Evolution==
This doesn't prevent the specification to keep being updated. Currently, it is divided into two profiles : basic and advanced. The former is considered stable and libraries implementing WAMP 2 are based on it, while the latter is still a work in progress, and not fully implemented in Crossbar.io.
 
WAMP is currently in version 2<ref>[https://wamp-proto.org/spec.html WAMP 2 specification menu]</ref> which introduced routed RPC. As of now, all routers are compatible with version 2. Some clients remain unported: Wamp.io, AutobahnAndroid, and cljWAMP.
==Use cases==
 
The version 2 of the specification is divided into two parts: the basic profile, including the router RPC and Pub/Sub, and the advanced profile, featuring trust levels, URI pattern matching, and client listing. The basic profile is considered stable and is what current libraries are implementing while the advanced profile is still in evolution.
Being a Websocket sub-protocol, WAMP fits naturally anywhere one would use raw web sockets, as a way to synchronize clients such as Web browsers, push notifications to them and allow soft real time collaboration between users.<ref>[https://github.com/voryx/angular-wamp WAMP and AngularJS]</ref> It has also the same limitations, requiring client support, which is missing for [[Internet Explorer]] versions older than 10.<ref>{{cite web|url=http://caniuse.com/#feat=websockets|title=Can is use websockets ?}}</ref> This is mitigated by the existence of [[polyfill]]s<ref>[https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills Web socket polyfills]</ref> using more portable technologies such as [[Adobe Flash|Flash]]. In that sense, it's a competitor to [[Meteor (web framework)|Meteor]]'s [[Distributed Data Protocol|DDP]].
 
==Comparison==
WAMP also targets the IoT, where it is used in the same way as [[MQTT]]<ref>{{cite web|url=https://into.aalto.fi/download/attachments/12324178/Huang_Fuguo_thesis_2.pdf|title=Moreover, we compared WAMP with other registered WebSocket subprotocols (MBWS, SOAP and STOMP) in terms of the related features; and with other potential protocols (CoAP and MQTT), in terms of the related practical deployments.}}</ref> as a light and efficient medium to orchestrate clusters of connected objects. The implementations in various languages make it suitable to control and monitor small devices such as the [[Raspberry Pi]] (in Python) or the Tessel<ref>[https://www.youtube.com/watch?v=WY7KzrRm8XY Tessel alarm app with Crossbar.io]</ref> (in Javascript).
The WAMP website claims<ref>[https://wamp-proto.org/comparison.html WAMP compared]</ref> the following selling points for the technology:
* '''Native PubSub''': supports Publish & Subscribe out of the box (no extension required).
* '''RPC''': supports Remote Procedure Calls out of the box (no extension required).
* '''Routed RPC''': supports routed (not only point-to-point) Remote Procedure Calls.
* '''Web native''': runs natively on the Web (without tunneling or bridging).
* '''Cross Language''': works on and between different programming languages and run-times.
* '''Open Standard''': Is an open, official specification implemented by different vendors.
 
On the other hand, WAMP does not try to achieve some goals of other protocols:
At last, WAMP can act as an enterprise service bus, serving as the link between micro-services like one would do with [[Corba]], ZeroMQ, [[Apache Thrift]], [[SOAP]] or [[AMQP]].
* Full object passing like [[Common Object Request Broker Architecture|CORBA]].
* Data synchronization like DDP.
* Peer-to-peer communication like [[ZeroMQ]].
* Multi-media streaming like [[WebRTC]].
* Large file transfer like HTTP.
 
Nevertheless, numerous protocols share some characteristics with WAMP:
{| class="wikitable sortable"
! Technology
! PubSub
! RPC
! Routed RPC
! Web native
! Cross Language
! Open Standard
|-
| WAMP
| {{ya}}
| {{ya}}
| {{ya}}
| {{ya}}
| {{ya}}
| {{ya}}
|-
| [[Ajax (programming)|AJAX]]
|
| {{ya}}
|
| {{ya}}
| {{ya}}
|
|-
| [[AMQP]]
| {{ya}}
| {{ya}}
|
|
| {{ya}}
| {{ya}}
|-
| Apache Thrift
|
| {{ya}}
|
|
| {{ya}}
|
|-
| Capn'n'Proto
|
| {{ya}}
|
|
| {{ya}}
|
|-
| [[Comet (programming)|Comet]]
|
|
|
| {{ya}}
| {{ya}}
|
|-
| [[Data Distribution Service|OMG DDS]]
| {{ya}}
|
|
|
| {{ya}}
| {{ya}}
|-
| [[D-Bus]]
|
|
|
|
| {{ya}}
|
|-
| CORBA
| {{ya}}
| {{ya}}
|
|
| {{ya}}
| {{ya}}
|-
| [[Distributed Component Object Model|DCOM]]
| {{ya}}
| {{ya}}
|
|
| {{ya}}
|
|-
| [[Java Message Service|Java JMS]]
| {{ya}}
|
|
|
|
| {{ya}}
|-
| [[Java remote method invocation|Java RMI]]
|
| {{ya}}
|
|
|
| {{ya}}
|-
| [[JSON-RPC]]
|
| {{ya}}
|
| {{ya}}
| {{ya}}
| {{ya}}
|-
| [[MQTT]]
| {{ya}}
|
|
| {{ya}}
| {{ya}}
| {{ya}}
|-
| [[Representational state transfer|REST]]
|
| {{ya}}
|
| {{ya}}
| {{ya}}
|
|-
| SOAP
|
| {{ya}}
|
| {{ya}}
| {{ya}}
| {{ya}}
|-
| [[Socket.io]]
| {{ya}}
|
|
| {{ya}}
|
|
|-
| SockJS
|
|
|
| {{ya}}
| {{ya}}
|
|-
| [[Streaming Text Oriented Messaging Protocol|STOMP]]
| {{ya}}
|
|
| {{ya}}
| {{ya}}
| {{ya}}
|-
| [[XML-RPC]]
|
| {{ya}}
|
| {{ya}}
| {{ya}}
| {{ya}}
|-
| [[XMPP]]
| {{ya}}
| {{ya}}
|
| {{ya}}
| {{ya}}
| {{ya}}
|-
| [[ZeroMQ]]
| {{ya}}
|
|
|
| {{ya}}
|
|-
| [[Distributed Data Protocol|DDP]]<ref>[https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP.md DDP specs]</ref>
| {{ya}}
| {{ya}}
|
| {{ya}}
| {{ya}}
|
|}
 
Although, it is important to note that while DDP does Pub/Sub under the hood to synchronize data sets, it does not expose PubSub primitives. It also is an open specification with several implementations, but not registered as a standard.
 
==References==
 
{{Reflist}}
 
Line 149 ⟶ 410:
[[Category:Remote procedure call]]
[[Category:Data serialization formats]]
[[Category:Inter-process communication]]
[[Category:Message-oriented middleware]]
[[Category:Middleware]]
[[Category:Internet protocols]]
[[Category:Network protocols]]
[[Category:Open standards]]