GNOME Bugzilla – Bug 759777
Add "max-clients" property to limit number of connecting clients in GstRTSPServer
Last modified: 2018-11-03 15:39:27 UTC
GstRTSPServer currently has a way of limiting the number of work being done in parallel by setting the maximum number of threads on the GstRTSPThreadPool being used. But there is no way to limit the number of connecting clients (some of which may later be accepted, and some be denied e.g. by the ->prepare() virtual function denying access). If there is no limit then some resource may be depleted, e.g. the number of file descriptors that may be open in the process running GstRTSPServer. The proposed patch adds a property on GstRTSPServer exposing a max-clients limit. Once this limit has been reached the server will simply disconnect any connecting client without letting it send its request and without sending any RTSP response. I'm of course available for further discussions concerning this patch.
Created attachment 317788 [details] [review] Proposed patch.
FWIW, you can already limit the number of clients by implementing GstRTSPServer::create_client() and returning NULL from there if the max number of clients is reached.
That's indeed true. Do you prefer that rate limiting is kept outside of gst-rtsp-server and then implemented by each project as it sees fit? Perhaps there are other ways that projects would like to decide whether a client should be denied? Can't think of any of the bat though.
I like the idea of having a generic max-clients, but I'd like better to return a meaningful error. Maybe set it to reject DESCRIBE/PLAY requests with a "453 Not Enough Bandwidth" and an explanatory message. It will make users life easier when their cameras start rejecting clients for no clear reason!
Actually when you have even more clients than your hardware can handle you can't even bother to read the request and responde with a 453 or a 503 because doing so would consume more of those precious resources that you don't have enough of. Also 453 seems to be related to bandwidth reservation which is not really what I'm trying to get at here. The scenario is a pure denial of service attack using RTSP-clients that basically attempt to do DESCRIBE and then disconnect.
Comment on attachment 317788 [details] [review] Proposed patch. + * The maximum number of connected clients that the server can handle. If + * this number of exceeded the server will being to close connections to + * connecting clients as a means of rate limiting the number of clients. The second sentence was hard to parse for me. Is it "If this number is exceeded the server will begin to close connections" that is intended?
Created attachment 320776 [details] [review] Proposed patch.
Anders, thanks for checking not my Swedish translations for other projects, but also my code comments here! I wasn't really expecting this. :)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/issues/17.