Re: [Nagios-devel] NSCA bottleneck / NSCA Timestamp

[Guest]

Hi Thomas,


I really like your suggestion to create a newer version of the nsca
protocol.

> Solution #1:
> Since the server only read sizeof(receive_packet) bytes, we should
> normally be able to add things to the struct without breaking anything
> (older server will just ignore it).

Hm, I don't like this idea. Right now it won't break anything but we do
not know which impact this will have on future nsca versions.

> Solution #2:
> Each packet sent have a version number, so we can create new packet
> formats with different version (older servers will discard non-matching
> version). I'm not an expert in network protocols but I guess we should
> do something like this:
>
> typedef struct data_packet_struct{
> int16_t packet_version;
> u_int32_t crc32_value;
> u_int32_t timestamp;
> int16_t return_code;
> uint16_t count; /* bytes of data */
> char payload[MAX_PACKET_SIZE];
> }data_packet;
>
> typedef struct nsca_message_v3_struct{
> int16_t return_code;
> char host_name[MAX_HOSTNAME_LENGTH];
> char svc_description[MAX_DESCRIPTION_LENGTH];
> char plugin_output[MAX_PLUGINOUTPUT_LENGTH];
> }nsca_message_v3;
>
> The server could easily detect version 3, expect a static size and
> fill-in the return code by using the count field (and the rest using an
> offset). Any newer version could have its own struct and variables. What
> I have in mind is possible support for newer features too like bigger
> output sizes and any future addition that we would need.
>
> Does it makes any sense?

Of course. That's my preferred solution.

What I am still missing before I will start to alter the nsca daemon and
client is a statement from Ethan. I would like to know what his thoughts
about multiline pluginoutputs and nsca are.

Cheers.

Gerd






This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]