Difference between revisions of "Commercial Hosting"

From Mumble Wiki
Jump to: navigation, search
m (Fixed all typos of "it's" that are really "its")
 
(34 intermediate revisions by 11 users not shown)
Line 1: Line 1:
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.
+
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.
+
We are therefore interested 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.
+
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.
 +
 
 +
If you aren't looking to start a host yourself, and are just looking for a commercial host, the Mumble Wiki maintains a non-exhaustive [[Hosters|list of hosts]].
  
 
= Murmur technical requirements =
 
= Murmur technical requirements =
Line 9: Line 11:
 
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.
 
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.
+
Based on data from our testserver, murmur will use about 40 MB of virtual memory, of which about 4 MB are resident in physical memory.
 +
 
 +
Since only minimal processing, as required for cryptography and "visibility checks" between users, 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 quality network cards and infrastructure capable of handling high packet load are recommended on servers hosting a big number of clients.
  
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 CELT, and using the highest quality and lowest latency, the peak bandwidth is 134kbit/s per speaker per listener (with IP and UDP overhead). However, this is the ''max'' bandwidth, and the recommended bandwidth (that has a very unnoticeable quality reduction for normal speech) is 63kbit/s. In other words, a server with 10 users and 1 user speaking will need to replicate the datastream 9 times, for a total of 63*9=567kbit/s outgoing bandwidth. If all 10 users speak at once, each stream has to be replicated 9 times, for a total of 63kbit/s*9*10=5.67 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; it is only possibly in a real world scenario for at most two people to be talking at the same time and still understand what they are saying.
  
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).
+
As one data point you can take a look at silencerru's post about the resource usage for a ~800 user server [http://forums.mumble.info/viewtopic.php?f=2&t=597 in the forum].
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 =
 
= 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.
+
Murmur and Mumble is BSD and GPL licensed, 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.
 +
 
 +
If you want to repackage and rebrand the client without also distributing its source code, the Mumble source code is BSD licensed, which allows you to do this. You will also need commercial licenses for the packages Mumble uses, namely Qt and Ice, as well as a patent license for [http://www.cs.ucdavis.edu/~rogaway/ocb/ OCB]. The owners of these packages and patents have all kindly granted Mumble a license, but that only covers open source distribution. Note that if you just use our binaries from sourceforge, you don't need to worry about any of this.
  
 
= Requirements for Murmur for adoption by commercial providers =
 
= 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.
+
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 in the discussion section (even if you agree, it helps to know we're on the right track), or add new sections.
  
 
== 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 "[[Murmur.ini#users|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 "[[Murmur.ini#bandwidth|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 be done through the [[Ice]] RPC interface of Murmur.
  
 
== SQL-Server ==
 
== 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.
  
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.
+
== Multiserver support ==
 +
From version 1.1.0 onwards, Murmur fully supports multiple independent virtual servers per process.
  
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.
+
Additional servers can be added either with the [[Ice]] or [[DBus]] RPC interface. You can use the newServer() call which returns a server id, then use start(id) or stop(id) to stop the server. Before you start it, you probably want to configure it, which is done through setConf(serverid, key, value).
 +
 +
Known configuration keys are:
 +
* [[Murmur.ini#host|host]] - IP bound to
 +
* [[Murmur.ini#password|password]] - server PW
 +
* [[Murmur.ini#port|port]] - server port
 +
* [[Murmur.ini#timeout|timeout]] - client inactivity timeout
 +
* [[Murmur.ini#bandwidth|bandwidth]] - bandwidth restriction
 +
* [[Murmur.ini#users|users]] - max # of users
 +
* [[Murmur.ini#welcometext|welcometext]] - the blurb sent by the server on connect
 +
* [[Murmur.ini#registername|registername]], [[Murmur.ini#registerpassword|registerpassword]], [[Murmur.ini#registerhostname|registerhostname]], [[Murmur.ini#registerurl|registerurl]] - The data for registration in the public server list
 +
* [[Murmur.ini#certificate|certificate]] - x509 certificate in PEM form
 +
* [[Murmur.ini#sslkey|sslkey]] - x509 private key in PEM form
 +
 +
If a config key is not present, the default is to take the value from the .ini file (except port, which defaults to inifile+server_id-1)
  
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.  
+
== RPC ==
 +
Murmur supports [[Ice]] 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.  
  
Hope this is an useful idea ...
+
[[3rd_Party_Applications|Here]] is a list of the web-interfaces available.
  
== Query Protocol ==
+
[[Ice]] has all but replaced [[DBus]], given its multi-platform features and usability.
  
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).
+
[[Category:Documentation English]]

Latest revision as of 00:26, 16 April 2020

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 interested 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.

If you aren't looking to start a host yourself, and are just looking for a commercial host, the Mumble Wiki maintains a non-exhaustive list of hosts.

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 our testserver, murmur will use about 40 MB of virtual memory, of which about 4 MB are resident in physical memory.

Since only minimal processing, as required for cryptography and "visibility checks" between users, 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 quality network cards and infrastructure capable of handling high packet load are recommended on servers hosting a big number of clients.

Mumble uses CELT, and using the highest quality and lowest latency, the peak bandwidth is 134kbit/s per speaker per listener (with IP and UDP overhead). However, this is the max bandwidth, and the recommended bandwidth (that has a very unnoticeable quality reduction for normal speech) is 63kbit/s. In other words, a server with 10 users and 1 user speaking will need to replicate the datastream 9 times, for a total of 63*9=567kbit/s outgoing bandwidth. If all 10 users speak at once, each stream has to be replicated 9 times, for a total of 63kbit/s*9*10=5.67 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; it is only possibly in a real world scenario for at most two people to be talking at the same time and still understand what they are saying.

As one data point you can take a look at silencerru's post about the resource usage for a ~800 user server in the forum.

Licensing

Murmur and Mumble is BSD and GPL licensed, 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.

If you want to repackage and rebrand the client without also distributing its source code, the Mumble source code is BSD licensed, which allows you to do this. You will also need commercial licenses for the packages Mumble uses, namely Qt and Ice, as well as a patent license for OCB. The owners of these packages and patents have all kindly granted Mumble a license, but that only covers open source distribution. Note that if you just use our binaries from sourceforge, you don't need to worry about any of this.

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 in the discussion section (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 be done through the Ice 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.

Multiserver support

From version 1.1.0 onwards, Murmur fully supports multiple independent virtual servers per process.

Additional servers can be added either with the Ice or DBus RPC interface. You can use the newServer() call which returns a server id, then use start(id) or stop(id) to stop the server. Before you start it, you probably want to configure it, which is done through setConf(serverid, key, value).

Known configuration keys are:

If a config key is not present, the default is to take the value from the .ini file (except port, which defaults to inifile+server_id-1)

RPC

Murmur supports Ice 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.

Here is a list of the web-interfaces available.

Ice has all but replaced DBus, given its multi-platform features and usability.