Murmur's reaction on bandwidth limit violation #1617

New issue

Open

opened 2026-02-20 21:08:26 -05:00 by deekerman · 2 comments

deekerman commented

2026-02-20 21:08:26 -05:00

Owner

Originally created by @unterwulf on GitHub (Sep 9, 2019).

Currently, murmur silently discards any packets from a client if the client has already used all its available bandwidth. This leads to interruptions of the audio from the client with no clue to the user about what is going on.

If a client does not behave well and ignores server's suggestion regarding the maximum allowed bandwidth (like Plumble does) the user will experience very lousy quality of audio and is likely to blame the overall technology while the real problem is just wrong client configuration.

I believe it'd be better to somehow inform the user that something wrong is happening.

There are two options I can think of:

Send a text message to the user that bandwidth limit has been exceeded and the problem is probably with the configuration of the user's client software and maybe audio bitrate needs to be decreased manually.
Disconnect the user with such a message.

Unfortunately, neither of the options is ideal. The first one will require some kind of rate limiting not to overwhelm the user with warnings. While the second, since there is no burst handling in BandwidthRecord, is probably prone to false positives that will also result in bad user experience if a user gets disconnected just because of network hiccups.

I personally like the second one better because otherwise a text message can pass unnoticed, but it surely needs to be implemented in some reliable way to avoid false positives.

Originally created by @unterwulf on GitHub (Sep 9, 2019). Currently, murmur silently discards any packets from a client if the client has already used all its available bandwidth. This leads to interruptions of the audio from the client with no clue to the user about what is going on. If a client does not behave well and ignores server's suggestion regarding the maximum allowed bandwidth (like Plumble does) the user will experience very lousy quality of audio and is likely to blame the overall technology while the real problem is just wrong client configuration. I believe it'd be better to somehow inform the user that something wrong is happening. There are two options I can think of: 1. Send a text message to the user that bandwidth limit has been exceeded and the problem is probably with the configuration of the user's client software and maybe audio bitrate needs to be decreased manually. 2. Disconnect the user with such a message. Unfortunately, neither of the options is ideal. The first one will require some kind of rate limiting not to overwhelm the user with warnings. While the second, since there is no burst handling in BandwidthRecord, is probably prone to false positives that will also result in bad user experience if a user gets disconnected just because of network hiccups. I personally like the second one better because otherwise a text message can pass unnoticed, but it surely needs to be implemented in some reliable way to avoid false positives.

deekerman added the

feature-request

server

good first issue

labels

2026-02-20 21:08:26 -05:00

deekerman commented

2026-02-20 21:08:27 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Sep 10, 2019):

I personally like the second one better because otherwise a text message can pass unnoticed, but it surely needs to be implemented in some reliable way to avoid false positives.

Agreed

Maybe we could add a counter and allow x packets to be higher in bandwidth (maybe even without ignoring any packets) and after that kick the user from the server. If the user sends packets with proper bandwidth in between, reset the counter to 0.

@Krzmbrzl commented on GitHub (Sep 10, 2019): > I personally like the second one better because otherwise a text message can pass unnoticed, but it surely needs to be implemented in some reliable way to avoid false positives. Agreed Maybe we could add a counter and allow x packets to be higher in bandwidth (maybe even without ignoring any packets) and after that kick the user from the server. If the user sends packets with proper bandwidth in between, reset the counter to 0.

deekerman commented

2026-02-20 21:08:27 -05:00

Author

Owner

@trudnorx commented on GitHub (Sep 23, 2019):

A properly implemented client would already not only warn but auto-adjust. I would say this is really a client problem. Why should Murmur work around bad implemented client?

@trudnorx commented on GitHub (Sep 23, 2019): A properly implemented client would already not only warn but auto-adjust. I would say this is really a client problem. Why should Murmur work around bad implemented client?