Feature request: bandwidth accounting about muonsocks

[niklata]

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]

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]

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]

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