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?
Is HTTP/3 compatible with WebSocket?
Is there any solution for this?
While there exist RFC 8441 that specifies how to bootstrap WebSocket over HTTP/2, there is not yet such RFC (in final form) for HTTP/3.
However, given that HTTP/2 and HTTP/3 are quite similar (at the HTTP/x framing layer), this is in the work at this draft RFC: https://www.ietf.org/archive/id/draft-hamilton-httpbis-h3-websockets-00.html.
I expect browsers and libraries to implement this draft RFC in the following months, like it happened for RFC 8441.
Currently, a browser will either open a separate WebSocket connection, or use an existing HTTP/2 connection as specified by RFC 8441.
I'm trying to send a message via SNMP version 1 or 2.
I need TLS support for safe transmission.
Does both version support TLS? (I'm using SNMP4j Library in Java)
No, SNMP v1 and v2 send everything in plaintext over the network.
You have to use SNMP v3 together with the security level authPriv.
Note: SNMP v3 also support the security levels noAuthNoPriv and authNoPriv which will send the data unencrypted, too.
I have recently come across a term 'Reactive sockets'. Up until this point, I used to think websockets are the way to go for full fledged asynchronous style.
So what are reactive sockets.
This link (http://rsocket.io/) even talks about comparison over websockets.
What is RSocket?
RSocket implements the Reactive Streams specification over the network boundary. It is an application-level communication protocol with framing, session resumption, and backpressure built-in that works over the network.
RSocket is transport agnostic. RSocket can be run over Websockets, TCP, HTTP/2, and Aeron.
How does RSocket differ from Websockets?
Websockets do not provide application-level backpressure, only TCP-based byte-level backpressure. Websockets also only provide framing they do not provide application semantics. It is up to the developer to build out an application protocol for interacting with the websocket.
RSocket provides framing, application semantics, application-level backpressure, and it is not tied to a specific transport.
For more information on the motivations behind the creation of RSocket checkout the motivations doc on the RSocket site.
Both WebSocket and RSocket are protocols which feature bi-directional, multiplex, duplex communication. But both work at different levels.
WebSocket is a low level communication protocol layered over TCP. It defines how a stream of bytes is transformed into frames. But WebSocket message itself does not have instructions about how to route or process it. Therefore, we need messaging protocols that operate on top of websocket, at application level, to achieve two-way communication.
RSocket is a fully reactive application level protocol which runs over byte stream transports such as TCP, WebSocket, UDP or other. It provides application flow control over the network to prevent outages and increase resiliency. RSocket employs the idea of asynchronous stream processing with non-blocking back-pressure, in which a failing component will, rather than simply dropping traffic, communicate its stress to upstream components, getting them to reduce the load.
Websocket
TLDR: L4 protocol, TCP for web.
Websocket is single bytestream, frames based protocol with very compact header.
It relies on web/http in each important protocol aspect: http based handshake (full roundtrip, not ideal for latency), text frames in addition to binary ones, compression support (for low-throughput/high latency connections),
mandatory frame content masking for compatibility with legacy non-tls http proxies.
Frames may be fragmented for better memory utilization by client and server;
Flow control is byte level only from TCP, and is not propagated to userspace.
Because websocket is just single bytestream transport, It needs full application protocol on top to be useful, and application level flow control scheme to be scalable.
Adoption wise, stable websocket implementation is available for most OSes / architectures, protocol is supported by all browsers and is go-to solution if any traffic needs to survive internet hop.
RSocket. Theory
TLDR: L5 protocol, primarily cloud/datacenter communications with excellent
throughput/latency characteristic: huge throughput while maintaining latency < few millis.
RSocket is session layer protocol, offers multiplexed flow controlled streams of binary messages over any transport capable of transferring bytes in order (tcp, unix sockets, also websocket).
Low latency is cornerstone, protocol has several capabilities for this:
2 levels of flow control: Reactive-Streams on individual stream level,
request leasing on connection level. Leasing is feature to control number of active streams by responder side using service & connection latency stats.
Instant handshake: client may send requests immediately after initial setup message.
Message fragmentation helps with reducing server memory pressure and improves latency for large messages (if done properly, see RSocket. Practice below).
Session resumption: reduced latency on client reconnection.
Because binary streaming interactions / multiplexing are available out-of-the-box, It is trivial to implement application RPC on top - only data serialization/deserialization is needed (mstreams-rpc using protobuf data encoding).
The protocol is semantically compatible with http2, which means It is also compatible with GRPC (given protobuf is used for message encoding).
RSocket. Practice
Only useful on JVM because that's where reactive streams are popular and practically useful with several
stable implementations: rxjava, project-reactor, smallrye-mutiny.
RSocket/RSocket-java is based on project-reactor from springboot.
Natural expectation would be best-in-class throughput, unfortunately RSocket/RSocket-java did not get this
right so performs worse
than 10+ year older GRPC (its predecessor Stubby was in use from ~2001) on top of http2: chatty web protocol.
Fragmentation: no server memory use or latency improvement because RSocket/RSocket-java
implemented It in pointless way - frames are always reassembled before passing
downstream.
GRPC compatibility: absent.
Advice for 2022: better stick with GRPC.
I tried to look this over in the Netty documentation but was unable to find it : which all websocket protocols does Netty websocket implementation support ?
I am trying to check for browser compatibility and hence also wanted to see the protocols as mentioned above. Going through the websocket server example in Netty 3.5.3 , I see in the WebSocketServerIndexPage class that window.MozWebSocket is also used , hence am I right that hybi-07 and hybi-10 is also supported without any specific code to be written? (Pardon me I am not much aware of the differences in the various protocols but it seems to be mentioned everywhere).
Netty supports protocol versions HyBi 00 (which is the same as Hixie 76), HyBi 8-10 and HyBi 13-17 (17 is the same as IETF 6455).
Each browser supports a single version of the protocol. HyBi 00-76 covers current released versions of iOS. IETF 6455 covers recent versions of Chrome and Firefox (and Opera if once they enable it by default), and IE 10. For browsers without native WebSocket support but with Flash you can use web-socket-js as a fallback and that supports IETF 6455 (albeit without binary data types).
In other words, Netty supports basically all browsers that have WebSocket support.
According to the netty api docs, it supports 3 versions of the Hybi drafts - 00, 07 and 10 as well as RFC 6455.
This will give you support for most browsers as summarised by http://en.wikipedia.org/wiki/WebSocket.