So I want to transfer sound bytes over a websocket from a phone to a server. However according to http://crossbar.io/docs/Features crossbar seems to only implement json and msgpack. Can I stil transfer binary messages over crossbar using some other way?
Also multiple crossbar clients (for eg )seems to only provide json and webpack as de/serialization formats. Am I missing something?
WAMP is primarily intended for transmission of messages, not large (binary) payloads. For small chunks you can encode the audio so that it can be part of a regular WAMP payload. For an example of this for a webcam image, see the Tessel camera example - https://github.com/crossbario/crossbarexamples/tree/master/iotcookbook/device/tessel/camera. This works fine in principle, though there is, of course, the encoding/decoding overhead.
Related
Is there a way to log or view the actual bytestream being sent to the server when using either the grpc or #grpc/grpc-js clients in NodeJS?
I'm working with an opaque GRPC server that accepts my bytes when I stream them, but doesn't do what it's supposed to do. I'd like to view the actual bytes being sent to the server, as we suspect it's a problem with how the GRPC libraries are serializing 64 bit integers.
The GRPC_VERBOSITY=debug GRPC_TRACE=tcp,http,api,http2_stream_state env variables for the native grpc module haven't been helpful in this specific case -- they show part of one byte stream, but not the full byte-stream.
Even a "here's the place in the code where the serialization happens" would be useful.
The GRPC_VERBOSITY setting there is correct. If you are using TLS, you can see all of the data that is sent and received with GRPC_TRACE=secure_endpoint. If you are using plaintext connections, you can instead see it with GRPC_TRACE=tcp. In both cases, you will need to pick the data you are looking for out of the HTTP/2 framing, and it may show compressed messages, which would be essentially impossible to interpret.
Alternatively, if your setup allows it, you may want to try Wireshark. It should be able to handle the HTTP/2 framing for you, and I believe it has plugins to handle gRPC traffic specifically.
I'm writing an audio streaming server - similar to Icecast, and I'm running into a problem with streaming audio files. Proxying audio works fine (an audio source connects and sends audio in real time, which is then transmitted to clients over HTTP), but when I try to stream an audio file it goes by to quickly - clients end up with the entire audio file within their local buffer. I want them to only have a few 10s of seconds in their local buffer.
Essentially, how can I slow down the sending of an audio file over HTTP?
The files are all MP3. I've managed to get it pretty much working by experimenting with hardcoded thread delays etc... but that's not a sustainable solution.
If you're sticking with http you could use chunked transfer encoding and delay sending the packets/chunks. This would indeed be something similar to hardcoded thread::sleep but you could use an event loop to determine when to send the next chunk instead of pausing the thread.
You might run into timing issues though, maybe your sleep logic is causing longer delays than the runtime of the song. YouTube has similar logic to what you're talking about. It looks like they break videos into multiple http requests and the frontend client requests a new chunk when the buffer is too small. Breaking the file into multiple http body requests and then reassembling them at the client might have the characteristics you're looking for.
You could simply implement the http Range header and allow the client to only request a specific Range of the mp3 file. https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests
The easiest method (by far) would be to have the client request chunks of the audio file on demand. std::net::TcpStream (which is what you said you're using) doesn't have a method to throttle the transfer rate, so you don't have many options to limit streaming backend short of using hard-coded thread delays.
As an example, you can have your client store a segment of audio, and when the user listening to the audio reaches a certain point before the end of the segment (or skips ahead), the client makes a request to the server to fetch the relevant segment.
This is similar to how real-world streaming services (like Youtube) work, because as you said, it would be a bad idea to store the entire file client-side.
I have a mini microservice project using NodeJS as backend and MQTT as the media for communicating between services. and I have a service that suppose to send an excel file to another service. Is there any way for MQTT to publish a file?
So far I only managed to send it as binary-data but had no idea what to do with that, or is there any way to recreate a file from binary-data in NodeJS?
This stackoverflow thread talks about MQTT byte limits.
The length of the actual topic string is at most 65536 bytes. This is a limit imposed by the mqtt spec, you can't change it. It is also worth noting that the topic is encoded with utf-8, so you may have less than 65536 characters available. The payload of the message is limited to 268,435,456 bytes. Again, this is defined by the spec.
If you exceed these limits, you need to break your file in chunks and use Base64 algorithm to encode them to ASCII. Make sure you send a hash of the whole file to check and guarantee that your file is consistent in the other side of the wire, after restoration.
This article does something similar using Python, in case you want to see some code. Hope it helps!
A file is just binary data and MQTT payloads are just binary data.
If you want to include meta data, e.g. a file name then you are going to have to come up with a data format to encode the filename along with the files content. That can be done any number of ways, be it in the topic you publish or by creating a data structure that includes the filename and the contents of the file.
since mqtt payload has limit, as #Fabio Manzano cited above, and it is impossible to publish binary data from even a small-sized file, i think i've managed to make this work by breaking it down into chunks (the binary data) and publish them separately. then merge them all back again when it finishes sending the last chunk.
and then do like what this thread suggests:
Writing image to local server
i've tried it and it succeed. thank you for the responses.
I am developing an application which listens live streams and fingerprints them concurrently in order to be identified by a mobile phone.
I will use gracenote's sdk for fingerprinting process. Since I need to fingerprint live streams instantaneously and get rid of them after a few minute,I need to design my own server and database (I also do not know whether you have such server in your sdk or not.).
Now I would like to ask a question about your fingerprint, I can get fingerprints successfully with gnsdk_musicid_query_get_fp_data function in base64 format.
First question: What is the length of coded strings, which are base64, in seconds.
Second question: After decode base64 codes, How should I do the comparison, in binary wise(after concatenation of bytes) or in integer wise, if integer wise how many bits to align (1,2,4 or 8 bytes?) .
Could you give some hints about comparison?
The GracenoteSDK only has the ability to create fingerprints. The only implementation that can compare fingerprints is the Gracenote Service. So you won't be able to make a service of your own that will do fingerprint recognition, but you can certainly build an application that uses Gracenote to do this.
I have just started using node.js, I'm running a node server with sockets.io and i need to send a buffer of bytes to the client.
I understand that this can be done by first translating the byte buffer to base64 and sending that, then translating it back on the client side. but i was wondering if there is a more elegant way of getting the byte stream to the client.
Socket.IO 1.0 Now supports Binary data transfer. Please have a look here . You can use Blob, ArrayBuffer and File.
https://github.com/binaryjs/binaryjs can be a solution. base 64 have ~30% of overhead size, so if you need to transfer large amount of data it will become inefficient.
There is also socket.io-stream https://github.com/nkzawa/socket.io-stream
It is little difficult to use binaryjs with socket.io.
Try deliveryjs
https://github.com/liamks/Delivery.js
which provides the means of communication between clients and server via socket.io.
However this module also uses the base64 conversion, which is a drawback.