NSCA bottleneck / NSCA Timestamp

Thomas Guyot-Sionnest thomas at zango.com
Thu Nov 22 19:15:23 CET 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Guyot-Sionnest wrote:
> * Or did you have another idea to do this? Tabs are currently allowed in
> the last field for service checks so the number of separators isn't an
> option, even when adding two new fields. Perhaps the position of the
> return code + two new fields, but then a service named "0" trough "3"
> would mess the thing up.

Oh, I overlooked a bit too much the protocol (I thought the data was
sent as-it but I believe I actually got confused reading client code
thinking it was server-side code).

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).

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?

Thomas
- --
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFHRcc66dZ+Kt5BchYRAtSCAJ0W28kpaFg4I8NSLkdS15ficDcX5ACYyPHR
oyi0Hi77zgmxOeiMXG6EHQ==
=BY2l
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
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