NSCA bottleneck / NSCA Timestamp

Gerd Mueller gmueller at netways.de
Fri Nov 23 10:06:03 CET 2007


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 SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/




More information about the Developers mailing list