I'm in the process of implementing a streaming protocol in JavaScript. The protocol is defined in terms of byte streams, not messages. I'd like to be able to talk to browsers using this protocol.
I've used Socket.io in the past for easy cross-browser full-duplex networking. However, in this case, I need BSD-style sockets. Ideally, I could code to the Node.js streams API and have the same (or very similar) code work in the browser.
Is there something like Socket.io for byte streams? ie Well tested, cross-browser, multi-transport, heart beating, etc.
So far, http://binaryjs.com/ is the closest to what I need. Unfortunately, the documentation suggests it is somewhat immature. I'd be very happy to find a more stable library with wider browser support.
Socket.IO uses lots of tech behind the scenes in order to make it very accessible and reliable. Lots of users will have Long Polling fallback, which is just pure HTTP protocol.
While WebSockets do support binary type of messages, it will be not the same as Long Polling or any other fallback tech, so Socket.IO will not support it as far as it is not something on all transports.
As well WebSockets and Socket.IO is purely Message Based communication protocol. In case with WebSockets it has framing around each message which will drive overhead for streaming.
What you need is Stream based communication, but not Message based. As I am aware this is long topic, and still not clear in web world.
Although you could look into WebRTC as future possibility for streaming data and it might meet your needs.
Some other options is to use plugins or extensions for browsers, like flash, unity, bespoke stuff and so on, in order to enable real streaming features.
Related
What I am trying to do is to create a simple virtual classroom project like Adobe connect, but obviously simpler, using Flutter and NodeJS, and I need the following options:
Real-time video or only voice streaming
Live chat box
Screen sharing ability
File sharing ability(Like PDF or PowerPoint or other text/doc files)
Whiteboard
As I searched so far I found that it seems WebRTC works for video/voice streaming and also screen sharing as well.
Also most of the livechat projects using Socket.IO.
My main question here is to know can I use only WebRTC for both real-time video/voice streaming and also live chat as well? Is it a good idea or it's better to combine Socket.IO and WebRTC together?
Furthermore I want to know can I use each of those libraries for File-Sharing purposes?
WebRTC gives you lower latency and a lot of functionality for conferencing out of the box. So for video/audio calls and screen sharing this is definitely a better choice.
Also, there's an option to use p2p communication which reduces latency even more and saves you resources on the server-side. Though if you intend to support many participants it looks less beneficial - you will need to maintain n-1 connections for each user if you have n users in total.
For live chat, whiteboard and file sharing there would be no big difference in terms of performance.
Things to consider:
WebRTC is more complex technology than websockets to setup and support
There might be opensource solutions for this features, i would make a decision based on what you can reuse in your project
You can use WebRTC for some of the features and websockets for others
can I use only WebRTC for both real-time video/voice streaming and
also live chat as well
Yes you can, there's a RTCDataChannel interface for exchanging arbitrary data. It can be used for live chat / whiteboard / file transfer.
As a good example, there's an opensource project peercalls, that implements chat and file transfer via WebRTC through the same connection that is used for conferencing.
Websockets can be used for file transfer as well, check out this library.
Using WebRTC requires signaling server and signaling is often implemented using websocket, check this mdn article Signaling and video calling
And with websocket you can implement livechat too, so it is not an either or situation but both quite often.
Socket.io there have been some eternal confusions.
It is supposed to fall back to mechanisms that the browser supports. Does that mean on latest browers it will use websockets over anything else? or does it need to be specifically told to use websockets.
websockets by themselves do they use polling or any other method where other forms of messaging like MQTT excel?
With both these points in mind has anyone taken a note of how socket.io and its working impact the battery life of a device. Considering phongeap/cordova apps having socket.io running inside a embedded browser.
I am developing a web application that has a desktop client written in Java. I am using WebSockets to communicate between the NodeJS server and the web client.
I am trying to decide whether to use a WebSocket or a normal TCP socket to communicate between the NodeJS server and the desktop client.
As I understand it, it would be easier to use a WebSocket but also a little bit heavier weight.
How does one make this decision?
It depends on your exact use case:
WebSockets are established by first doing a HTTP connection and then upgrading this to the WebSocket protocol. Thus the overhead needed to exchange the first message considerably higher than with simple sockets. But if you just keep the connection open and exchange all messages through a single established socket then this does not matter much.
There is a small performance overhead because of the masking. But these are mainly simple computations (XOR) so they should not matter much.
It takes a little bit more bandwidth because of the framing. But this should not really matter much.
On the positive side it works much better (but not always perfect) together with existing firewalls and proxies so it integrates easier into existing infrastructures. You can also use it more easily with TLS because this is just WebSocket upgrade inside HTTPS instead of inside HTTP.
Thus if you must integrate into existing infrastructure with firewalls and proxies then WebSockets might be the better choice. If your application is performance heavy and needs every tiny bit of bandwidth, processor time and the lowest (initial) latency then plain sockets are better.
Apart from that if latency is really a problem (like with real time audio) then you might better not use any TCP based protocol, like TCP sockets or WebSockets. In this case it might be better to use UDP and deal with the potential packet loss, reordering and duplication inside your application.
Is there a proper WebSocket library for whatever technology you implement the desktop client in? The websocket protocol is not trivial and it's a rather new technology which is not universally supported yet. When you have to implement WebSocket from scratch using pure TCP/IP sockets you can plan to spend a few days until you have the basic protocol implementation working and can start to implement your own protocol on top of it (been there, done that, threw it away the moment a library was available which worked better than my own implementation).
But if you can find a Websocket implementation for your desktop client, then you could save some work and complexity on the server-side by having both the website and the desktop client communicate with the node.js backend in the same way.
I want to use a communication mechanism between a server and a linux client, for messaging and discovery. My only requirement is that, the client should be as lightweight as possible. On searching internet, I cam across XMPP and MQTT. But, I am not sure, which of its version is the most lightweight. Can anybody please guide me regarding which is the most lightweight of all. Please let me know, if any other such mechanism exists.
This isn't an easy question, because it's not clear which aspects of "lightweightness" you are looking for. Are you looking for small implementation (in file size), for minimum CPU usage or minimum network requirements.
MQTT and XMPP can both be pretty slim on the client side. Out of the box without any extensions, MQTT most of the time is (much) more lightweight on the wire, it's a binary protocol while XMPP is (without any extensions) XML based. MQTT focuses on efficient Pub/Sub messaging, if you need something fancy on top, you should choose a sophisticated broker (click here for an overview). XMPP has a bit more out of the box. If you don't need things like friendship requests on the protocol level, MQTT is a solid choice.
Again, both protocols have their use cases (which IMHO don't intersect too much). A pretty good overview of MQTT, XMPP, CoAP and HTTP can be found here on slideshare.
How can I send low latency data to a server and back with phonegap?
Considering I don't have access to php files locally, and don't have experience with node.js or WebSockets I don't know which ones I should use.
WebSockets aren't natively supported by the browsers in Android or older versions of Cordova under iOS, which means you'll need to use a PhoneGap plugin if you want to use them on the client.
There's more information at: http://remysharp.com/2010/10/04/websockets-in-phonegap-projects/
However, I'm not sure (even with the plugin) how resilient WebSockets are likely to be when the device moves between network connections (WiFi -> 3G -> WiFi), so using a simple polling web service may be a more reliable option if your app needs to continue receiving data as your users move around.
If you need to receive data initiated by the server, consider using push notifications instead: both iOS (APN) and Android (C2DM) provide APIs to do this which make more efficient use of the battery than having your app poll your server constantly.
You can use WebSockets in PhoneGap with iOS and Android. WebSockets are natively supported on iOS within Safari. For Android you will need to use a polyfill.
See: https://stackoverflow.com/a/13527585/39904
The answer above provides information about how to make a WebSocket object available within the Android WebView used by PhoneGap and also provides a link to a sample project which you can use to get started.
WebSockets were developed as a solution to 'Comet' hacks. As such they provide a very low latency solution for realtime bi-directional communication between a client and server. This means low bandwidth and low resource usage - battery on mobile - since you are holding a single connection open rather then opening and closing multiple HTTP connections. A polling solution which makes requests at regular intervals is likely to drain the battery much faster than a WebSocket solution. If you are polling at lower intervals then it may be fine - it depends on your use case.
In terms of WebSockets working as you change between network and network type (WiFi -> 3G -> WiFi) then if you are using WebSockets natively you need to detect the onclose and reconnect. You will also need to determine the best type of connection; unsecure (WS) or secure (WSS). I would highly recommend you use WSS for mobile since some mobile network providers use transparent proxies which interfere with WS connections. This might sound complicated but there are a number of libraries that handle this for you. Such as the Pusher JavaScript library (note: I work for Pusher). Libraries such as these also provide fallback to a less efficient HTTP-based solution when the environment will not let any WebSocket connection occur.
Also see: realtime web technology guide.
I'd agree with #rmc47 that you should consider native push notifications if it's for infrequent single notifications
Refer to this link to see WebSocket Support by Browsers and devices : html5test.com site - iOS 4.2+ already supports WebSocket
See this doc that explains how to develop a simple application with WebSocket.
Unfortunately the content is in the Portuguese (Brazilian) language but you can leave comments which I will answer.
I'm not sure what you mean by "access to PHP files locally". The use of node.js and web sockets is also not mutually exclusive.
If you have not made a decision on the server implementation you could go for either node.js or ASP.NET.
node.js has good support for sockets with Socket.io, which abstracts the client implementation for you. So it will use WebSockets if there is support, else it will fall back to long polling.
ASP.NET has a library called SignalR which does something similar for the .NET platform.