Skip to content
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

Closed
x-qq opened this issue Jan 29, 2023 · 4 comments
Closed

Feature request: bandwidth accounting #3

x-qq opened this issue Jan 29, 2023 · 4 comments
Assignees

Comments

@x-qq
Copy link

x-qq commented Jan 29, 2023

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

@niklata niklata self-assigned this May 5, 2023
@niklata
Copy link
Owner

niklata commented May 5, 2023

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.

@niklata
Copy link
Owner

niklata commented May 5, 2023

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.

@niklata
Copy link
Owner

niklata commented May 5, 2023

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.

@niklata
Copy link
Owner

niklata commented May 7, 2023

I've implemented the disconnection log messages with bytes sent and received in commit 036c094.

@niklata niklata closed this as completed May 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants