Seem like there are two orthogonal issues.

The first is the ability to get more detailed stats in a format you can do something with, instead of just the human-readable one. I've been really hesitant to add a detailed connection stats struct, because that would commit me to supporting the ABI essentially in perpetuity. Especially for structs, this adds a lot of complexity and maintenance burden to support backwards compatible. HOWEVER: what would you think about a format that returned the info in JSON as a string? I know that's a little weird, but it means that the actual ABI interface never really changes, and I could add stuff to the record without breaking anything or adding a big maintenance burden. (On rare occasions I might need to remove or rename things.)

The second issue is the ability to get stats on a listen socket. Right now we don't aggregate any stats at that level, but I could add some it. That seems like a straightforward bit of work.

Let me know what you think on the struct/JSON thing.

I broke off one part of this issue a separate issue #130.

As for reporting aggregate stats at a higher level than the connection. I need to give this some thought on exactly what the API will look like. For example, perhaps we should also add a feature to report stats aggregated at the poll group level? And we need to make sure that "spam" packets not associated with any connection are accounted for (maybe even tracked under a totally separate bucket).

Given the other things on the list that have more clear definitions and more value, it's likely that this will end up getting shoved down on the priority list, at least until I can design something unambiguous and simply to implement under the hood. Right now I don't have a clear picture of what it would be.