Commercial Hosting

From Mumble Wiki
Revision as of 11:00, 13 June 2007 by Slicer (Talk | contribs)

Jump to: navigation, search

Mumble (and murmur) are open source, and therefore completely free of charge. However, to fully experience the quality of Mumble, a quality server with good network connection is needed. Home-based DSL or Cable servers are far from optimal, and do not scale to much more than 5-6 users.

We are therefore interrested in facilitating commercial hosting of murmur, to enable users who lack either the server hardware and network connection or the skill to compile and maintain murmur to use Mumble.

This page is specifically targeted at commercial hosting providers. This is where we'll present a short summary of murmur's expected resource requirements, and where you can edit it to provide us with information on what you need to make your job easier.

Murmur technical requirements

Murmur runs on any operating system where Qt can compile. At the moment, that is "most" UNIXes, Windows and MacOSX. Our internal testserver runs on Linux, and a binary version for Windows is included in the mumble installer.

Based on data from out testserver, murmur will use about 40 MB of virtual memory, of which about 4 MB are resident in physical memory.

As no processing is done serverside, we were not able to push even 1% of actual CPU usage with 4 users on a Xeon 3.4Ghz. We do see quite a few context switches though, so high quality network cards is likely a requirement.

Mumble uses VBR speex, and using the highest quality and lowest latency, the peak bandwidth is 65kbit/s per speaker per listener (with IP and UDP overhead). In other words, a server with 10 users and 1 user speaking will need to replicate the datastream 9 times, for a total of 65*9=585kbit/s outgoing bandwidth. If all 10 users speak at once, each stream has to be replicated 9 times, for a total of 65kbit/s*9*10=5.8 Mbit/s. Note that these are absolute worst-case scenarios, and the average bandwidth use is around 20-30 kbit/s during speech, multiplied by the number of listeners.

Licensing

Murmur and Mumble is GPL, which means that much like the Linux kernel, you are free to use it in commercial hosting without royalties. You are selling a service, not a program.

Requirements for Murmur for adoption by commercial providers

I'll note down what I can imagine commercial hosting providers would like to see implemented in murmur before they start offering it as a service. If you are a commercial provider, please comment on the below in the discussion (even if you agree, it helps to know we're on the right track), or add new sections.

Ability to limit number of users

Set the "users" parameter in murmur.ini

Ability to limit audio quality

Set the "bandwidth" parameter in murmur.ini, which limits the per-user incoming bandwidth. Multiply this by the number of users in a channel to find the used outgoing bandwidth per active speaker.

No frills ACLs and Groups

The multi-channel ACL and Groups system in Mumble enables easy setup of linked channels that can match most any scenario. On the downside, it's also easy to mess up, especially if you're an inexperienced user. While this might ultimately be up to the hosting providers, we should probably provide a small example of how to use a webpage to "configure" a very basic access system, and give no users the actual "Write" bit, even the admin. This would allow those users who feel they are competent enough to log in with superuser and foul things up as much as they want, and will also allow for simple management for less sophisticated users.

If anyone wishes to do so, this can now be done through the DBus RPC interface of murmur.

SQL-Server

The default and recommended SQL engine for murmur is SQLite, since it is faster than all the other alternatives and requires less resources. From 0.9.5 onwards, murmur also supports MySQL, Postgres and any other engine that has a Qt database driver.

Multiserver support

Murmur is coded as a "one process, one server" system. This allows us to make quite a lot of optimizations to reduce overhead, since we don't need to pass the server context around with every function call we make. Hence, you probably won't see a single murmur process able to control several independent servers in the near future.

That being said, murmur is reasonably well behaved, and it would be no problem to create a management script in perl that spawned and killed of processes according to a master "server table". If anyone makes such a management script, please let us know :)

RPC

Murmur supports DBus RPC calls, which allow querying all information of the server in real time, and also allow management. Hence, it's fairly easy to write scripts to query and display server status, and also to create web frontends for server administration.