These are what I am talking about:
https://github.com/meetecho/janus-gateway
https://github.com/jitsi/jitsi-videobridge
The scalability I am looking for is say 1 to 10k users in a single live stream.
None of those are going to scale to 10k streams out of the box. If all you want is for 1 participant to be seen by 10k people, that is, a one direction broadcast, YouTube or Twitch are better suited for this purpose.
Disclaimer: I'm a developer on the Jitsi team.
"None of those are going to scale to 10k streams out of the box."
The question wasn't "which one of these can do it out-of-the-box", it was "which one would be cheaper".
I've been fiddling around for months with both Janus and Jitsi trying to get them to work on a server and I've had no luck, so I can't exactly tell you which one would be cheaper, but I imagine they are roughly similar if you are just relaying the video/audio feed without doing any additional transcoding on the server.
I think what it comes down to cost-wise is probably your setup and configuration. Will you run it on a PaaS like AWS or GCP, or will you set up on some hosted servers and configure the cluster yourself? Which PaaS or server host will you use? How much work are you or your team willing to put into the setup and configuration? Do you even know what you're doing?
Going through a PaaS would save you a ton of work and probably be much more reliable and robust, but will probably be much more expensive. And there are different price ranges among different platforms and services and hosts.
I think the cost will be much more affected by these factors than by the differences between Janus Gateway and Jitsi Videobridge.
But what do I know, I can't even get the ***king things to work on one simple server.
Related
I'd like to implement a simple video chat system for students to tutor each other. I'm a one man show, and would like a system I can run in a cost effective way starting with 10 users, and hopefully scale up as needed.
WebRTC seems like a great, low latency, and cheap option to build this feature. However, if clients are communicating, then they must know each other's public IP. Is this a significant privacy or security issue?
What is the worst case scenario of somebody getting my IP address? Wouldn't any malicious actor have to get through my ISP to get my specific location?
Thanks!
If you host it yourself, WebRTC can be extremely cost-effective. I've been running the SFU at galene.org (disclaimer: I'm the main developer), which is used for multiple lectures with up to a hundred students. Even though this is a full-fledged SFU (and not a mere TURN server), hosting amounts to just over €6/month.
If your tutoring sessions involve just two or three people, then peer-to-peer WebRTC might be enough, but even then a TURN server will be required, especially if some of your users are on university networks. For larger groups, you will need to push your traffic through an SFU.
If you do peer-to-peer WebRTC, then any user can learn the IP of any user they are communicating with; this is most probably not an issue, since the IP addresses are most probably already being disclosed (e.g. in mail headers). If you go though an SFU, then the IP addresses are not deliberately disclosed, but they might still leak; for example, the SFU implementation mentioned above (Galene) discloses IP addresses when a user initiates a file transfer since file transfers happen directly between clients, in a peer-to-peer fashion. (It may be possible to avoid this disclosure by setting the iceTransportPolicy field to relay in the PeerConnection constructor, but I haven't tested how effective it is.)
WebRTC doesn't have to be P2P. You could run a SFU. Each user will upload their video to your server, and the server will distribute via WebRTC. Then the users will never know each others IPs.
I don't have any exact numbers, but it isn't expensive either. Your biggest expense will probably be bandwidth. Lots of Open Source SFUs exist, this is a good list to get started.
I'm trying to create a virtual classroom. Since I'm not familiar with the web conferencing (or conferencing) terminology, I'm not sure if I'm understanding WebRTC's capabilities as I should.
I've looked in the examples for WebRTC, and all that I've found seem to be peer-to-peer connections. As I understand it, peer-to-peer connections are between two entities. However, virtual classrooms are different as far as I know; they require all parties to be connected to each other, so that when one user speaks/types, all users hear her.
Is such a thing possible with WebRTC? If so, what is it called and how can I read more about it?
Check out the open source Big Blue Button project (http://bigbluebutton.org/). They're currently Flash based but are actively moving towards webRTC. Rumor has it they'll be using Kurento as their MCU. They also have open source mobile (Android/iOS) application code.
According to http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/, such a thing is possible:
Beyond one-to-one: multi-party WebRTC
You may also want to take a look at Justin Uberti's proposed IETF standard for
a REST API for access to TURN Services.
It's easy to imagine use cases for media streaming that go beyond a simple
one-to-one call: for example, video conferencing between a group of colleagues,
or a public event with one speaker and hundreds (or millions) of viewers.
A WebRTC app can use multiple RTCPeerConnections so to that every endpoint
connects to every other endpoint in a mesh configuration. This is the approach
taken by apps such as talky.io, and works remarkably well for a small handful
of peers. Beyond that, processing and bandwidth consumption becomes excessive,
especially for mobile clients.
Maybe you can try searching in the webrtc google group
hope this helps
Basically, I'm about to launch a music streaming app, and I'm trying to figure out cost.
Cloud services like S3 and RackSpace cloud are expensive. As far as scalability is concerned... I'm assumign that an average user listens to music for an hour and lets say our app scales to 100,000's of users. It's about 90MB / hour per user of bandwidth... Let's make another assumption and say that we have an average of 10,000 concurrent users streaming music in a 24 hour period (90MB (avg/hr) * 10k * 24 = 21,600,000MB = ~20.5 TB)... That's a shit load of bandwidth! According to Rackspace's pricing, that's $3,780 USD per day... holllllly crap! Anoher thing, services like Rdio, Grooveshark, etc have roughly 15 million (licensed) songs... If I through that into the mix, that's 15,000,000 * 3MB (avg song) = 43,945GB = $4,300 a month.
So at these rates, companies like Rdio and Grooveshark, etc, in no way pay this much.
So my question is simple... generally, what are some routes to take when creating a streaming service? Being specific would earn my vote! (AKA, links to well rated companies offering cheaper CDN services or unmetered colocation for a flat rate)
Thanks duders!
More)
Application servers will be hosted on Rackspace... but this is somewhat irrelevant considering the fact that I really just need a fast "cdn"
Look at accelerating load balancers like jetNEXUS. They are very simple to set up and use techniques like static caching HTML muxing and compression to dramatically reduce the amount of data hitting the actual servers. This can save you a ton of money in bandwidth costs.
I think Rackspace has some Zeus or Jetnexus offerings, and I know that it's available as an option on Amazon's Cloud.
There are plenty of of ways to reduce that cost. I know Spotify do the following (among other things):
Cache the songs locally.
Use P2P to download from other clients (they mainly use the server to guarantee low latency).
Only allow high bit-rates for paying users.
I recommend you read the following: http://www.csc.kth.se/~gkreitz/spotify-p2p10/
If you're looking for cheap hosting then I suggest you check out: http://www.hetzner.de/. I haven't used them but I've heard lots good things about them.
We've been working on reducing the costs for our high volume email delivery service (http://elasticemail.com) which uses a lot of bandwidth and needs to scale. We found that by switching to OVH we could get much more bandwidth and much more hardware for a lot cheaper and they have great API's to automate a lot of the complexities you'd find in a complex infrastructure.
So kudos to OVH (http://ovh.ie) for saving us a lot of money.
I know Rackspace cloud files for their CDN (which is included in the price) use Akamai. Akamai don't seem to have any pricing around on the web, but they do seem to be expensive after some googling.
I'd try these things.
Tell Rackspace your plans and ask if they can work out some kind of a bulk deal.
Contact Akamai and tell them about your plans and see what they offer.
Google "cheapest content delivery network" and see what comes up.
I think a CDN is what you want, that'd give you the capacity that you need. I don't think it'd be possible to do that much from a simple VPS or cloud provider without a CDN behind it.
Basically, if you're serving a lot of static content, and you're doing it from cloud servers (vps's) it's gonna clog up your pipes at some point, even if you have a few servers, it'll eventually reach capacity, but with a CDN, all the content is pushed out to the nodes, so it basically goes on and on :)
From my experience, Akamai CDN is awesome. I've used it quite a bit (through RS cloud files) and in like 2 years only hit 2 issues, one was the end user's fault for using some far away dns servers, and the other was fixed in about 1.5 days, where a user was in Italy or somewhere and their content was coming out of some other country.
Akamai uses the geo IP database lookup of the DNS server that requests the url to give you the IP of a host nearby. This works great for most people as they'll use their ISPs DNS servers for doing lookup.
On the plus side, most users get ping times much smaller than if they downloaded it from America, for example in Gold Coast, my ping time to akamai is about 20-50 msecs, to USA it's 250-400 msecs.
Update: After doing some googling myself, this looked promising: http://24ways.org/2008/using-google-app-engine-as-your-own-cdn - they're saying to use google app engine as a CDN. On the plus side, last time I checked you could do that for free, but on the downside, I wouldn't base a business by planning that that would stay free; going by google's history of releasing free things, then later charging for them or dropping them.
Well, I tried to ask this question as a comment on this question, but I thought that maybe no one will notice it, so I decided to ask it as a separate one.
The question is about how to do real-time GPS tracking system things; if we have the following scenario:
Rather than connecting a GPS receiver to a PC, the user will have a mobile device with an integrated GPS receiver.
Location data will be sent over mobile network using GPRS data connection to a server side.
The data will be processed and a KML path file will be created and updated on time intervals and used to track the user using Google Earth.
The question is: what is the best method to accomplish this scenario for the server side; is it a web service, a web application, a windows service, a windows application or what exactly? Taking into account that the system will serve a number of users simultaneously, and that more users may use the system in the future(scalability issues).
Thank you in advance and I highly appreciate any help :)
What kind of device are you using exactly, something like this or something more sophisticated / configurable? If we assume that the device sends its data over TCP, I would consider the following approach with separate input/output processes:
Input: a process listening specific TCP port and storing incoming coordinates to database with a device id. Preferably, your listening loop must be able to handle simultaneous connections without them blocking each other.
Output: web application reading coordinates from database for a given device id and displaying them through the Google Earth API.
Use whatever programming language(s) you are familiar with.
For me there is a technical limitation/risk here -> the mobile device, and its connectivity.
1) What are your requirements? Do you need to support various mobile devices or will you focus on only one platform ?
2) More importantly, you have to understand that GPRS data connections differ from a PC connected to the Internet. There are various connection restrictions imposed by different mobile operators.
If I was to design such a system in order to minimise those risks I would go with a web server running on port 80 which the mobile devices would upload their Long/Lat through POST (or even GET to simplify things).
EDIT: Regarding scalability, it would be very easy to scale things up in the future using tried&tested load-balancing techniques.
EDIT2: Whichever technology you decide to use, i would HIGHLY recommend that the first thing you do is to mock up a prototype. Those connection restrictions could be show-stoppers. Ideally you need to explore them before you have made any serious investment.
How can I build a simple 2-player game, that communicates over the internet?
I need to solve the problems of:
lookup or rendezvous - two players want to find each other.
ongoing communications. Either player can initiate an action that requires delivering information to the other side, in a reasonbly quick timeframe (IM-type latency, not email-type latency).
In this regard, I suppose it is equivalent to a 2-way chat, where people want to be able to find each other, and then also, once paired up, intercommunicate.
Further requirements:
for now, assume the endpoints are Windows OS, relatively recent.
assume neither endpoint machine is directly accessible from the internet. Assume they are client machines, hidden behind firewalls that block incoming requests. The machines can make outbound requests. (say, over HTTP, but TCP is also fine)
communication should be private. For simplicity, let's say there's a shared secret already in place, and the endpoints are able to do AES. I guess what I mean by this is, any intermediary should not need to decrypt the message packets. The decryption will happen only at the endpoints.
all custom code should run only on the client PCs.
Assume there is no server in the internet that is under my control.
I'm happy to use third-party servers to facilitate intercommunication, like an IM server or something, as long as it's free, and I am not required to install custom code on it.
What APIs are available to facilitate this design?
Can I do this with IM APIs? WCF? Are there WCF Channels for Windows Messenger?
What protocols? HTTP? I have this tagged as "peer-to-peer" but I mean that virtually; there's no hard requirement for a formal p2p protocol.
What message formats would you use?
EDIT
To clarify the requirements around servers, what I want is NO SERVER UNDER MY CONTROL. And NONE OF MY CUSTOM CODE ON ANY SERVER. That is not the same as "No server".
Think of it this way: I can send an email over SMTP, using custom code that I write on the sending and receiving side. My custom code can connect via a free SMTP server intermediary. This would require no installation of code on the SMTP server. This is something like what I want, but SMTP is not acceptable, because of the latency.
EDIT2
I also found this: library for Instant Messaging, like libpurple, but written in C#
ANSWER
I can do what I want, using libraries for IM frameworks. One simple way to do it using Windows Live Messenger is to use the Messenger Activity SDK. This proves the concept, but is not really a general solution. But, similar things can be accomplished with the IM libraries for various messenger systems, like libpurple, or using libs for IRC channels. In all these cases, the IM servers act as the firewall-penetrating communications infrastructure.
IM is the wrong tool. Instead, use an IRC chat room.
With an IRC chat room, your clients "log in" to the chat room, and that is used for your "presence". Anyone in the chat room is "available" to play the game.
Once that is done, the game instance communicate with each other through the chat room. They can use the global channel, or simply private IRC channels for game traffic.
The issues to solve:
First, all game state is shared on the clients. Many games have done this (RTS's like Age of Empires, RPGs like Diablo). But client states are susceptible to hacking and cheating. That's just a plain truth. If the game is popular, it WILL be hacked.
Ping traffic. Basically the flow is you log in to the room, your client is in "available to play" mode. Then it pings EVERYONE ELSE to see if THEY are available to play. This will happen with every client "sign in" to the chat room. You can then use the public room for broadcast events "Frank is ready for a new game", "Frank started a game with Joe", etc. That can help keeps games in sync and not chatty, but when a client connects to the chat room, it's going to go "Hi All, it's Bob, what are you all doing". So you need to manage that.
Traffic volume. IRC rooms can handle a lot of traffic, but not a LOT of traffic. Most are designed to prevent "spamming", "flooding", etc. So you may well be rate limited on you game play. Not a problem for "Checkers", more so for "World of Warcraft" during a 40 man Raid. That's a game design issue.
Terms of service. The IRC provider may well say "Uh no, you can't do that with our service". I haven't looked in to it, so I don't know, but could be an issue.
Other than that, IRC is a pretty good fit. Lots of IRC bot code floating around on the net, I've never used any of it.
Every two-player game must have some type of server environment by the basic need of having to communicate between two clients/players at the very least. Keep in mind, each of the clients/players can also act as its own server to communicate with other linked clients. But the need to keep tabs on all clients/players at any given time and the need to facilitate searching of other clients/players inherently requires some type of server environment to begin with.
libpurple along with otr can give you the privacy-over-IM such an application would need.
You could setup a message board on one of the free message board servers so that players can find each other. You'll probably want to encourage them to use private messages to exchange IP addresses. Then, use a protocol that connects using IP addresses. Good luck with that. Firewalls make it a pain.
Then, of course, one machine of the pair would need to act as server, the other as client. Your software must contain both sets of code. I've written such a game and can tell you that the communication code gets a little confusing.
I can tell you right now that you'd be much happier in life if you wrote a web service to facilitate communication. But, then, you'd need a server for that.
Good luck. You're going to need it.
OR, you could just write a game for an IM client, like Microsoft Messenger. I've seen games for that one, so I know it can be done.
As somebody has said, it may not yet possible to do so if you don't have any mediated server between 2 players. As you're happy to use third party server, I suggest that you build your system using Google App Engine + XMPP over HTTP. It works nicely over internet and behind firewall. And yet it's free (as long as your system doesn't grow out of GAE quota).
Peer to peer is out due to your firewall constraint. This doesn't really work easily for directory services anyway.
The next easiest method I would use is to toss up a very simple CGI server script on one of the numerous super cheap web hosting sites. It seems that you don't want to go this route. Is there some particular reason? 100 lines of code and a super cheap server should give you everything you're asking for and more.
I suppose you could hook into some sort of third party chat library thing. I don't know about the current IM protocols, but good old IRC and a separate channel for your game would work. You even could cobble something together using FTP. BLOG comments on a free blog site would work too. The question is why?
These are all kludges. They get the job done in obtuse, inelegant, and poorly scaling ways.
I urge you to reconsider the web server solution.
You have a lot of conflicting requirements. Both clients behind a firewall blocking incoming requests pretty much means they can't do peer-2-peer since neither machine can act as the server, and you will need to have a transport server in the middle somewhere routing messages to each client. Right now what you are asking is pretty much not possible given the no server requirement.