After a decade of using ZeroMQ I noticed a foot note in the zmq_socket API docs that states:
ZMQ_PAIR sockets are designed for inter-thread communication across the zmq_inproc(7) transport and do not implement functionality such as auto-reconnection. ZMQ_PAIR sockets are considered experimental and may have other missing or broken aspects.
http://api.zeromq.org/2-1:zmq-socket
However, the zmq_inproc API docs doesn't mention any form of "experimental" status in regards to zmq_inproc itself. Should I interpret this to only being relevant to network socket based ZMQ_PAIR abstractions?
Related
I am completely new to RSocket.
I read the FAQ and the motiviations page (and skimmed the Protocol page) and understand that RSocket can be used on top of TCP, WebSocket and Aeron. But what I don't understand is what the differences are between using RSocket with these transports because all interaction-models can be used with each transport.
I am personally interested in using RSocket channel to enable bi-directional communication but don't know which transport I should use.
For example what are the differences between RSocket (channel) + TCP and RSocket (channel) + WebSocket?
I couldn't find an answer anywhere, so I was hoping someone here could help me out.
Ty in advance.
RSocket let's you program across platforms (JS, iOS, Android, C++ Server) with a single reactive network programming model. Cleanly supporting common reactive operations from frameworks like RxJava (Observable, Flowable, Single, Maybe, Completable).
The underlying transport is an implementation detail. But it's a critical implementation detail as between a mobile and a server hosted in GCP, WebSocket may be the only viable option. While in a datacenter you may opt for Aeron or TCP depending on your requirements.
Whatever you choose, you can write against the same higher level model of reactive network operations. If you know you just need say Aeron for a single server to server operation, you may not need RSocket, you could program directly against Aeron. RSocket is giving you this abstraction above it.
RSocket provides a common programming interface to multiple transports. You can choose the transport based on the qualities of service the transport provides. For example, if you require ease of firewall traversal then choose WebSocket, if you require low-latency and high-throughput transfer choose Aeron. All things are relative. Aeron can traverse firewalls but configuration is more specialised and WebSocket can give reasonable performance but it is not in the same category as Aeron.
Many other factors come into play so you need to understand the underlying transports with the qualities they provide and match these up against your requirements.
I am doing research on websocket in the world of IoT, but the scope of information I have is quite small. I like the suggestion, if you can share information about the website, if you can, thank you.
I read several papers about IoT, including the application of websocket in the queuing system, there is also a comparative analysis of the performance of Xbee and Websocket.
WebSocket is a communications protocol which facilitates a full-duplex communication channel over a single TCP connection. WebSocket WebSocket communication presents a suitable protocol for the IoT environments. Since it offers a lightweight communication between server and client also bundles of data can be transmitted continually between multiple devices. For this we need to have a server that needs WebSocket library installed and also a WebSocket Client and web browser installed on the client or the device that supports WebSocket.
There are both the advantages and caveats of using WebSockets and IoT.
Please refer the below links for more information:
1) https://www.hcltech.com/blogs/unleashing-power-html5-websocket-internet-things-iot
2) https://medium.com/#krishna.thokala2010/websocket-fever-for-iot-f662498ff1d2
3) https://webofthings.org/tag/websockets/
4) https://readwrite.com/2017/10/31/websockets-iot-two-dont-go-together/
Hope this information helps. Please comment if you need more assistance on specific details.
I'd like to compare somehow capabilities of grpc vs. zeromq & its patterns: and I'd like to create some comparsion (feature set) - somehow - 0mq is "better" sockets - but anyways - if I apply 0mq patterns - I get comparable 'frameworks' I think - and here 0mq seems to be much more flexible ...
The main requirements are:
async req / res communication (inproc or remote) between nodes
flexible messages routing
loadbalancing support
well documented
any ideas?
thanks!
async req / res communication (inproc or remote) between nodes
Both libraries allow for synchronous or asynchronous communication depending on how to implement the communication. See this page for gRPC: http://www.grpc.io/docs/guides/concepts.html. Basically gRPC allow for typical HTTP synchronous request/response or a 'websocket-like' bidirectional streaming. For 0mq you can setup a simple REQ-REP connection which is basically a synchronous communication path, or you can create async ROUTER-DEALER type topologies.
flexible messages routing
'Routing' essentially means that a message gets from A to B via some broker. This is trivially done in 0mq and there are a number of topologies that support stuff like this (http://zguide.zeromq.org/page:all#Basic-Reliable-Queuing-Simple-Pirate-Pattern). In gRPC the same sort of topology could be created with a 'pub-sub' like connection over a stream. gRPC supports putting metadata in the message (https://github.com/grpc/grpc-go/blob/master/Documentation/grpc-metadata.md) which will allow you to 'route' a message into a queue that a 'pub-sub' connection could pull from.
loadbalancing support
gRPC has a health check support (https://github.com/grpc/grpc/blob/master/doc/health-checking.md) but because it's HTTP/2 you'd have to have a HTTP/2 load balancer to support the health check. This isn't a huge big deal, however, because you can tie the health check to a HTTP/1.1 service which the load balancer calls. 0mq is a tcp connection which means that a load balancer would likely check a 'socket connect' in tcpmode to verify the connection. This works but it's not as nice. Again you could get slick and front-end the 0mq service with a HTTP/1.1 webserver that the load balancer reads from.
well documented
both are well documented. 0mq's documentation must be read to throughly understand the technology and is more of a higher lift.
Here's the big differences:
0mq is a tcp protocol whereas gRPC is HTTP with a binary payload.
0mq requries you design a framing protocol (frame 1 = verison, frame 2 = payload, etc.), whereas much of this work is done for you in gRPC
gRPC is transparently coverted to REST (https://github.com/grpc-ecosystem/grpc-gateway) whereas 0mq requires a middleware application if you want to talk REST to it.
gRPC uses standard tls x509 certificates (think websites) whereas 0mq uses a custom encryption/authentication protocol (http://curvezmq.org/). Prior to 4.x there was no encryption support in 0mq and if you really wanted it you had to dive into this crap: https://wiki.openssl.org/index.php/BIO. (trust me don't do it)
0mq can create some pretty sick topologies (https://github.com/zeromq/majordomo) (https://rfc.zeromq.org/spec:7/MDP/) whereas gRPC is basically client/server
0mq requires much more time to build and get running whereas gRPC is basically compiling a protobuf messages and importing the service into your code.
Not quite the same. gRPC is primarily for heterogeneous service interoperability, ZeroMQ (ZMQ/0MQ/ØMQ) is a lower level messaging framework. ØMQ doesn't specify payload serialization beyond passing binary blobs whereas gRPC chooses Protocol Buffers by default. ØMQ is pretty much stuck on the same machine or machines between datacenters/clouds, whereas gRPC could potentially work on a real client too (ie mobile or web, it already supports iOS). gRPC using ØMQ could be significantly faster and more efficient for in-cloud/-datacenter services than the overhead, latency and complexity of http2 request/response chain. I'm not sure how (or even if) gRPC TLS security is adequate for public cloud and mobile/web usage, but one could always inject end-to-end security requirements (ie libsodium) at the router/controller level of the app/app framework and run in plaintext mode (which would also remove OpenSSL fork BoringSSL from causing maintenance headaches because of upstream flaws).
For very high latency / low bandwidth services (ie mission to mars), one would think about RPC using a transport like SMTP (ie Active Directory alternate replication) or MQTT (ie Facebook Messenger, ZigBee, SCADA)
Bonus (off-topic): It would be nice if gRPC had alternate pluggable transports like ØMQ (which also itself supports UNIX sockets, TCP, PGM and inproc), because HTTP/2 isn't stable in all languages yet and it's slower than ØMQ. And, it's worth looking at nanomsg (especially in the HFT world) because it could be extended with RDMA/SDP/MPI and made crazy low-latency/zero-copy/Infiniband-ready.
I am working on a project which involves real time chat (messaging, including group chats).
I have worked with websockets before, So I started working on this using spring-websockets and I did some reading about what is the best way to implement it. Then I came across STOMP (as a sub-protocol for websockets)and as there is direct support for STOMP in spring it was bit easy to achieve what I was supposed to do.
But my doubt is as far as my understanding STOMP and XMPP are similar protocols(messaging protocols) but I could not find any questions/blogs where the differences are explained and why somebody would prefer one over another?
It will be really helpful if somebody explains how these two protocols differ?
Thank you.
As the successor of Jabber, XMPP is more focused on instant messaging instead of STOMP. XMPP is an extensible protocol and could be used for other purposes, but there are plenty of built-in mechanism and implementations regarding IM. STOMP offers a more general mechanism and "message" here refers a broad meaning.
Let's say you choose STOMP for your project. Then you will probably need to define basic messages for certain scenarios (peer-to-peer, group chat) which are already offered by XMPP.
To compare two protocols;
STOMP message is carried as plain text (as its name indicates) whereas XMPP is structured as XML.
STOMP connections can be established via TCP or WebSockets. XMPP supports TCP or HTTP (WebSocket standard is also propopsed).
In Java world, Spring has the ability to talk STOMP and it's very easy to implement. However, XMPP support can be added by adding 3rd Party APIs (i.e. Smack)
Couldn't find a clear answer to either:
WebSockets: There is support for WebSockets (http://www.pubnub.com/websockets/) and socket.io, however do the other SDKs use web sockets?
XMPP: Does PubNub use it as a communication protocol?
PubNub WebSockets and/or XMPP
Update 2019 🌟 PubNub is planning to add additional protocols. MQTT is supported today mqtt.pubnub.com, additionally we will be adding WebSockets and SEE and connectionless push with UDP.
At PubNub we use many protocols in our Client SDKs starting with an always-on forever lived TCP Socket. Our TTL policy on TCP Sockets is unlimited. We provide the best protocol and we roll in updates under the covers so developers don't have to sweat the details of how messages are delivered.
The PubNub Data Stream Network believes in a protocol independent open mobile web; meaning that we will use the best protocol to get connectivity through any environment. Protocols, like WebSockets, can get tripped up by cell tower switching, double NAT environments, and even some anti-virus software or proxy boarder authorities.
PubNub provides client libraries specifically so we can auto-switch the protocol and remove socket-level complexities making it easy for developers to build apps that can communicate in realtime.
PubNub has deployed a variety of protocols over time, like WebSockets, MQTT, COMET, BOSH, long polling and others. We are exploring currently prototyping future designs using SPDY, HTTP 2.0, and others. The bottom line is that PubNub will work in every network environment, and has very low network bandwidth overhead, as well as low battery drain on mobile devices compared to connection based push implementations.