I would like to develop an application that will allow a user to live streams audio from his computer and broadcast it through the network.
My main concern is the performance of this application. I want the quality of the sound to be preserved as its highest and I would like as few "delay" as possible.
Can I reach such a level of performance with web-based languages such as AJAX, NodeJS, or Ruby (Ruby on Rails?) or should I consider more low-level languages such as C/C++?
Thanks!
The performance of sound of the application is not affected so much by the language you choose. That level of performance is achieved by using the correct protocols to send the audio stream over the network. One common mistake is to use HTTP which user TCP protocol because is has a lot of certificates to be verified and this delay the information from streaming live. The best protocol which is used by all big stream companies like Facebook, Instagram, Skype, Lync is the UDP protocol which is super fast because of the minimum level of certificates to be checked.
The companies mentioned above uses different programming languages in order to build the streaming servers and get almost the same results so this is my opinion that the protocol makes the difference.
You can use Java if you want, I have friends that work for 8x8 one of the best companies of live streaming in the USA and they have used JAVA for building the servers and the clients.
Related
I want to build a one to many users streaming app where admin can stream video and users can view that video in live. I have to use node.js. which is best approach and what are good tools for that.
Does using webrtc one to many affect performance at large scale?
Suggestions please...
Thanks
given my extensive experience in the subject and the use of many WebRTC libraries, I would recommend that you use an SFU or MCU where you can cover high-level conferences on a large scale, I do not recommend the use of WebRTC one to one due to you'll no doubt have a lot of performance issues.
My recommendation is that you use an SFU or MCU library, for example:
https://github.com/livekit/livekit
LiveKit is easy to use, great scalability (depends on your server), it has tools to measure the server so you know if you need a better one, it also has many server-side and client-side SDKs such as: Javascript, ReactNative, Flutter, Android and Server Side: PHP, Nodejs, Etc.
It also allows you to have total control of the room, who can enter a room, who can broadcast, etc.
I hope my answer helps you.
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.
I am trying to create an on-demand audio streaming platform (similar to Spotify) from scratch. It will have 1000 users (I am optimizing for time to build, not scalability as of right now).
I want to use web-based technologies ( I am experienced with React/Redux/Node). Could I get some advice on the architecture (what technologies I should use for the project)?
Here are things I need help with
What Storage service I should use for my music files (my song catalog is about 50000)
How to stream music from the storage service to each user
What server protocol I should use (RTMP/WebRTC/RTS)
(Optional) How to store data in cache to reduce buffer
I know this is a huge ask so thank you guys for your help in advance
What Storage service I should use for my music files (my song catalog is about 50000)
S3 (or equivalent).
Audio files fit this use case precisely, and you're already using AWS. If you find the cost too high, there are compatible services that are more affordable, all the way down to DIY on Minio.
How to stream music from the storage service to each user
Use a CDN (or multiple CDNs) to optimize delivery and keep the latency low. CDNs are also better at spoon-feeding slow clients.
What server protocol I should use (RTMP/WebRTC/RTS)
Normal HTTP! That's all you need, and that's all that's been necessary for decades for this use case.
RTMP is a dead protocol, only supported by Flash on the client side. Its usage today is limited to sending source streams from video encoders, and even that is well on its way out the door.
WebRTC is intended for low latency connections, like voice calls and video chat. This is not something that matters in a unidirectional stream. You actually want a robust streaming mechanism... not one that drops audio like a cell phone to keep up to realtime.
RTSP is not something you can use in a browser, and is overly complex for what you need.
Just a simple HTTP service is sufficient. Your servers should support ranged requests so that the browser can lose a connection and still pick up right where they left off, without the listener even knowing. (All CDNs support this, as does any properly configured web server.)
(Optional) How to store data in cache to reduce buffer
CDNs will generally improve performance of the initial connect and load. I also recommend pre-loading the next track to be played in the list so that you can start it immediately. In most browsers, you can actually start the next track at the tail end of the previous track for a smooth transition.
Say you have microservice A,B, and C which all currently communicate through HTTP. Say service A sends a request to service B which results in a response. The data returned in that response must then be sent to service C for some processing before finally being returned to service A. Service A can now display the results on the web page.
I know that latency is an inherent issue with implementing a microservice architecture, and I was wondering what are some common ways of reducing this latency?
Also, I have been doing some reading on how Apache Thrift and RPC's can help with this. Can anyone elaborate on that as well?
Also, I have been doing some reading on how Apache Thrift and RPC's can help with this. Can anyone elaborate on that as well?
The goal of an RPC framework like Apache Thrift is
to significantly reduce the manual programming overhead
to provide efficient serialization and transport mechanisms
across all kinds of programming languages and platforms
In other words, this allows you to send your data as a very compactly written and compressed packet over the wire, while most of the efforts required to achieve this are provided by the framework.
Apache Thrift provides you with a pluggable transport/protocol stack that can quickly be adapted by plugging in different
transports (Sockets, HTTP, pipes, streams, ...)
protocols (binary, compact, JSON, ...)
layers (framed, multiplex, gzip, ...)
Additionally, depending on the target language, you get some infrastructure for the server-side end, such as TNonBlocking or ThreadPool servers, etc.
So coming back to your initial question, such a framework can help to make communication easier and more efficient. But it cannot magically remove latency from other parts of the OSI stack.
I need to write a WebSocket server and I am learning Node JS by reading some books I purchased. This server is for a very fast game so I need to stream small messages to groups of clients as quick as possible.
What is the difference between:
Autobahn | JS : http://autobahn.ws/js/
and
Einaros : https://github.com/einaros/ws
?
I have heard that Autobahn is very powerful and capable to deal with 200k clients without a load balancer so I was wondering if someone with more experience could advise me whether there is any advantage in opting for one or another library.
The functional difference is: Einaros is a WebSocket library, whereas Autobahn provides WebSocket implementations (e.g. AutobahnPython), plus WAMP on top of WebSocket.
WAMP provides higher-level communication for apps (RPC + PubSub - pls see the WAMP website). And AutobahnJS is a WAMP implementation for browsers (and NodeJS) on top of WebSocket.
Now, say you don't care about WAMP, and hence only need a raw WebSocket server. Then you can compare AutobahnPython with Einaros primarily based on non-functional characteristics, like protocol compliance, security and performance.
Autobahn has best-in-class protocol compliance. I dare to say that, since the Autobahn project also provides the quasi industry standard WebSocket testsuite - used by most projects - including Einaros. Autobahn has 100% strict passes on all tests. Einaros probably also - I don't know.
Performance: yes, a single AutobahnPython based WebSocket server (4GB RAM, 2 cores, PyPy, FreeBSD in a VirtualBox VM) can handle 200k connected clients. To give you some more data points: here is a post with performance benchmarks on the RaspberryPi.
In particular, this post highlights the most important (IMO) metric: 95%/99% quantile messaging latency. You shouldn't look only at average latency, since there can be big skews and massive outliers. What you want is consistent low latency.
Achieving consistent low latency is non-trivial. E.g. one factor for languages/run-times like NodeJS or PyPy (a JITted Python implementation) is the garbage collector. Every time the GC runs, it'll slow stuff done - potentially introducing large latencies in messaging. I have done extensive benchmarking (unpublished) which indicates that PyPy's incremental GC is very good in this regard. Better than HotSpot (JVM) and NodeJS (Google V8). When in doubt, and since I haven't (yet) published numbers, you shouldn't believe me, but measure yourself.
The one thing I'd strongly recommend: don't rely on average latency, measure quantiles, do histograms.
Disclose: I am original author of Autobahn and work for Tavendo.