When I send a binary message from a Python server to a JavaScript client, an exception is thrown from JSON.parse at this codeline. I'm sending the message like this:
server.sendMessageHybi(myBinaryChunk, binary=True)
On the receiving end, the data field is holding a Blob object rather than a string. Wondering if this is a supported workflow, or if I'm doing something wrong.
You can send binary WebSocket messages from AutobahnPython and receive those on browser-side with pure WebSocket (you don't need AutobahnJS for that).
AutobahnJS is a WAMP implementation: RPC and PubSub over WebSocket. WAMPv1 uses text (JSON) messages for serialization and does not support (unencoded) binary payloads.
There are considerations for supporting binary payloads in WAMPv2 (https://github.com/tavendo/wamp/issues/4)
Related
For an example, one can send binary data as either a Blob or an ArrayBuffer using WebSockets.
var file = document.querySelector('input[type="file"]').files[0];
connection.send(file);
Currently server sent events (SSE) don't have the binary messaging capability.
Can I know HTTP/2 protocol supports for sending binary messages? (References would be better)
I want to send messages from kafka to clients through a websocket,
I have kafka topic of with json records like: {...fields...., type:1}.
A client initiates the connection to websocket with a json message that includes an array field of the types he intrested in like: {...fields..., types:[1,3,4]}
I tried to do it with Nifi but I dont have a way to consume from kafka and at the same time filter the messages that I get by the type.
I would be happy to get recommandations on a way of doing this in Nifi or any other way (Streamsets, implementing costumized websocket that consumes from kafka etc...)
(My code is written in java)
Thanks :)
with Nifi but I dont have a way to consume from kafka and at the same time filter the messages that I get by the type
ConsumeKafka + RecordPath filter should work fine...
Alternatively, you have not mentioned what type of system your webserver is running...
You would write it in Spring Boot... or Django, ... or Flask+Faust, or NodeJS then forward Kafka messages from a built-in consumer to a web-socket.
tl;dr Search "your language + websocket + kafka" ... I'm sure there will be results
Or you could use the Kafka REST Proxy, then just use AJAX instead of a WebSocket.
You could also use Kafka Connect HTTP Sink to just send events to an open webhook (such as Nifi's ListenHTTP), for example.
What are the major differences between WebSocket and STOMP protocols?
This question is similar to asking the difference between TCP and HTTP. I shall still try to address your question, its natural to get confused between these two terms if you are beginning.
Short Answer
STOMP is derived on top of WebSockets. STOMP just mentions a few specific ways on how the message frames are exchanged between the client and the server using WebSockets.
Long Answer
WebSockets
It is a specification to allow asynchronous bidirectional communication between a client and a server. While similar to TCP sockets, it is a protocol that operates as an upgraded HTTP connection, exchanging variable-length frames between the two parties, instead of a stream.
STOMP
It defines a protocol for clients and servers to communicate with messaging semantics. It does not define any implementation details, but rather addresses an easy-to-implement wire protocol for messaging integrations. It provides higher semantics on top of the WebSockets protocol and defines a handful of frame types that are mapped onto WebSockets frames. Some of these types are...
connect
subscribe
unsubscribe
send (messages sent to the server)
message (for messages send from the server) BEGIN, COMMIT, ROLLBACK
(transaction management)
WebSocket does imply a messaging architecture but does not mandate the use of any specific messaging protocol. It is a very thin layer over TCP that transforms a stream of bytes into a stream of messages (either text or binary) and not much more. It is up to applications to interpret the meaning of a message.
Unlike HTTP, which is an application-level protocol, in the WebSocket protocol there is simply not enough information in an incoming message for a framework or container to know how to route it or process it. Therefore WebSocket is arguably too low level for anything but a very trivial application. It can be done, but it will likely lead to creating a framework on top. This is comparable to how most web applications today are written using a web framework rather than the Servlet API alone.
For this reason the WebSocket RFC defines the use of sub-protocols. During the handshake, the client and server can use the header Sec-WebSocket-Protocol to agree on a sub-protocol, i.e. a higher, application-level protocol to use. The use of a sub-protocol is not required, but even if not used, applications will still need to choose a message format that both the client and server can understand. That format can be custom, framework-specific, or a standard messaging protocol.
STOMP — a simple, messaging protocol originally created for use in scripting languages with frames inspired by HTTP. STOMP is widely supported and well suited for use over WebSocket and over the web.
The WebSocket API enables web applications to handle bidirectional communications whereas STOMP is a simple text-orientated messaging protocol. A Bidirectional WebSocket allows a web server to initiate a new message to a client, rather than wait for the client to request updates. The message could be in any protocol that the client and server agree to.
The STOMP protocol is commonly used inside a web socket.
A good tutorial is STOMP Over WebSocket by Jeff Mesnill (2012)
STOMP can also be used without a websocket, e.g. over a Telnet connection or a message broking service.
And Raw WebSockets can be used without STOMP - Eg. Spring Boot + WebSocket example without STOMP and SockJs.
Note: Others have well explained what are both WebSocket and STOMP, so I'll try to add the missing bits.
The WebSocket protocol defines two types of messages (text and binary), but their content is undefined.
STOMP protocol defines a mechanism for client and server to negotiate a sub-protocol (that is, a higher-level messaging protocol) to use on top of WebSocket to define following things:
what kind of messages each can send,
what the format is,
the content of each message, and so on.
The use of a sub-protocol is optional but, either way, the client and the server need to agree on some protocol that defines message content.
Reference
TLDR; STOMP is a framework built on top of websockets, i.e. stomp utilizes websockets in the background. If you are thinking of building a notification/messaging system then use stomp.
https://stomp.github.io/stomp-specification-1.2.html
is it possible to create server based unsolicited "events", "messages"
(e.g. message that is NOT a reply to a client's request, but generated
on behalf of the server) in gRPC?
[Tried googling for it, but couldn't find any relevant answer, mind me]
Thanks,
If you want the server to initiate the connection from the server and send a message with no prior interaction from the client, then no, you can't do that with gRPC.
However, this fits perfectly into the "subscriber" pattern that gRPC is intended to support: the client opens a server-streaming request (possibly indicating which messages or events they would like to receive), then the server responds with each message or event as it appears.
I would like to use thrift with a Java server sending data to a browser using websockets. Is this possible?
According to this issue: https://issues.apache.org/jira/browse/THRIFT-2355 Thrift recieved support for web sockets in the javascript compiler for version 0.9.2.
In thrift there are 2 important things: protocol, and transport. Protocol defines how is data serialized into the data stream. And transport defines how are those streams of data exchanged between communicating entites.
There is json protocol in thrift which is supported by javascript, but as far as transports go I think Thrift supports only 2 transports raw tcp, and http. Later can be used to invoke operation on a HTTP server, and fetch the result from it, but not the other way around as you need it.
I guess you might be able to use json protocol, but you would need to roll your sleeves up and implement your own websockets transport. This could be a a non trivial task.
As of v.0.9.0 of Thrift, the answer is no.
On the client side, the javascript generated uses AJAX for it's transport as seen in Thirft.js library, so if a client was to use a WebSocket, then transport in Thrift needs modified.
On the server side, the Java code shows a socket server, but I believe it doesn't have the handshaking needed for the WebSocket server side code. Again, probably be added somewhat easily. It probably makes more sense for you to use jWebSocket as your server and the Java object classes created by thrift than the Thrift version of the server. You can inspect the code to know it better in Thrift. see /lib/java/src/org/apache/thrift/ section of the trunk in Thrift.