Difference between revisions of "Commercial Hosting"

From Mumble Wiki
Jump to: navigation, search
Line 26: Line 26:
 
== Ability to limit number of users ==
 
== Ability to limit number of users ==
  
As bandwidth scales mostly linearly with the number of users (as long as only one user talks at a time), it makes sense to have a price structure reflecting the ammount of concurrent users. I think the easiest way to facilitate this is to add a field for [code]MaxConcurrentUsers=X[/code] in murmur.ini, and then reject connections with an error message at that point. We'll reserve a slot for SuperUser so the "owner" can clean up if desired.
+
Set the "users" parameter in murmur.ini
  
 
== Ability to limit audio quality ==
 
== Ability to limit audio quality ==
  
Bandwidth scales with audio quality. While Mumble's worst-case (top quality, 20ms latency) peak is 65kbit/s with IP and UDP overhead, the best case (minimum quality, 80ms latency, no 3D info) is 11 kbit/s. A sensible middle ground is 40ms latency with medium quality audio, which is 25.8kbit/s peak. It would probably be very helpfull if the quality and latency could be controlled serverside, as a 8-user top-quality server uses as much bandwidth as a 16-user medium-quality server, especially since we can't really hear much of a difference between "high" and "medium".
+
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.
 
+
Perhaps the easiest solution for this is to simply add [code]MaxVBRQuality=X[/code] and [code]MinimumFramesPerPacket[/code] to murmur.ini and have murmur communicate those limits to the clients. If the clients still send with higher quality or more packets-per-second, we'll silently discard them.
+
 
+
'''Update:''' Murmur 0.9.2 contains support for limiting the per-user incoming bandwidth, and it's up to each to each user how to divide that bandwidth between latency (more packets-per-second), audio quality (larger framesize) and 3D position information. New connections will be rejected with proper error messages if their current settings are too high. Bandwidth usage is measured, and if it exceeds the allowed value, clients are kicked. This avoids people recompiling the client without the limits, or just changing the quality settings after they connect.
+
  
 
== No frills ACLs and Groups ==
 
== 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.
 
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 ==
 
== SQL-Server ==
  
It would be nice to use Postgres as SQL-Storage for murmur. Please add another table ("servers") containing a list of all servers (id, name) and a column to each table indicating to which server the row belogs. All configuration parameters (from the ini file) should be moved into the SQL by creating a new table.
+
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.
  
After starting the murmur process, it should read the "servers" table and spawn the subprocesses automatically. I've seen a "command"-table, so I guess it is possible to send murmur commands by inserting them into that table. It would be nice, if it's possible to add/modify/delete servers just by inserting some commands into a table.
+
== Multiserver support ==
  
This would make administration of murmur much more easier cause there is no need to create and maintain an extra process for all customers. A small webinterface or so for editing servers would be helpfull, too.  
+
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.
  
Hope this is an useful idea ...
+
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 :)
  
== Query Protocol ==  
+
== RPC ==
  
External querying of servers (ie, via UDP or TCP) to retrieve server information (name, number of people in the server, channel list, who's in what channel etc) would be a requirement so that people may monitor player statistics as well as allow customers to place the figures on their website (like Ventrilo / TeamSpeak 2).
+
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.

Revision as of 11:00, 13 June 2007

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.