-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: bandwidth accounting #3
Comments
This is easy to implement and has very little cost either in cpu or space, so I don't mind adding it. Likely I will go with the signal to pre-specified file approach as that would avoid the parsing required for the command port. |
Thinking about it more, I think the approach I would choose is to require logging to be enabled, then at connection termination, print the number of bytes (octets) sent and received to that client IP. Then whatever accounting could be done via an awk script or similar that aggregates transfer counts per ip over a desired date-time range. Keeping a table of client IPs to sent/receive counters in memory in muonsocks has the risk of allowing a malicious client to greatly bloat the memory size of a muonsocks process, although it wouldn't be an arbitrary OOM DoS. |
Well, it would be a fixed 1MB for a 16-bit unsigned to 2x 64-bit unsigned counter table [edit: which would still require a hash construction to map 32-bit IPs to 16-bit slots, and probably some expiry mechanism based on bytes exchanged], but it would require each worker thread to take a lock to update that table for each transfer or disconnection, depending on the logging precision (stats in realtime for the former, stats only at disconnect for the latter). So I still prefer the log-based approach, which has no memory cost, and the same or less locking overhead. The stats would of course only be emitted at socket disconnection, but that's likely what I would choose in either case. |
I've implemented the disconnection log messages with bytes sent and received in commit 036c094. |
It would be extremely helpful if muonproxy stored counters for the amount of data (bytes) transfered from and to every client IP, and provided a way to request this data from the server at runtime.
Some ways to implement this that I can think of are:
a) signal handler - output the counters into a specified file or file descriptor upon receiving a specific signal (like SIGUSR1)
b) dedicated "admin" UNIX or UDP socket that accepts commands and returns data
The text was updated successfully, but these errors were encountered: