<div dir="ltr">Hiya<div><br></div><div style>We have some servers that get a rapid turn-over of TCP connections, and consequently the [netstat] section of the client report can be huge.  When this happens, the ports and procs (because the process list comes after [netstat]) reports are impacted.</div>

<div style><br></div><div style>I'm working on reducing the number of TIME_WAIT sockets, as well as limiting client connections.  But it's not unreasonable for some hosts to just operate this way.  But the 512kB limit on the client messages also seems reasonable - I don't want to consume too many Xymon resources (bandwidth, disk).</div>

<div style><br></div><div style>So I think it would be really neat to be able to send compressed [client] messages to Xymon.  If the xymond_client process detected the gzip header, it could automagically decompress on-the-fly.  A 500kB message would typically shrink to around 50kB.  Either the whole message could be compressed, or each [section] could contain optionally compressed data.</div>

<div style><br></div><div style>Some risks with this include:</div><div style>1) extra CPU resources required on client and server, potentially leading to delayed processing - but probably not significantly more than normal</div>

<div style>2) a rogue process could send in a gzip bomb - this could be mitigated by wrapping a timer around the call to inflate*() and limit execution time to a few seconds.</div><div style><br></div><div style>Thinking more generally, it could allow specifying other filters such as base64-encoding, authentication or encryption.</div>

<div style><br></div><div style>J</div><div style><br></div></div>