NSCA bottleneck / NSCA Timestamp

Thomas Guyot-Sionnest thomas at zango.com
Fri Nov 23 19:41:25 CET 2007


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

Andreas Ericsson wrote:
> Thomas Guyot-Sionnest wrote:
>> 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;

Just FYI the "int16_t   return_code;" should have been removed (replaced
by  uint16_t  count;).

>> 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;
>>
> 
> This is bad. Look up modbus for how to write header + body part
> messages which allows for near-unlimited protocol extensions.

Thanks for your insightful reply. As I said I don't have much experience
in network protocols. My example was some kind of merge between the NTP
protocol (which I know in details) and the current NSCA protocol with
backward compatibility, and provided as an example as to what I had in
mind. The idea is to leverage limitations without breaking old clients
(so that an upgrade can be seamless and won't require upgrading clients
that don't need it).

> With this way of doing things, you're limiting yourself to a
> definitive size of each host/service. It makes for (a little)
> easier coding, but it's a useless limitation to put on people.

The current limit for the payload would be 65k (uint16_t characters),
and I see no way to way to increase that without splitting further the
header struct (i.e. first get the packet_version (int16_t), then you can
know what to expect next).

> 
> [ code examples and comments... ]

This indeed looks great but I don't see how to make that
backward-compatible. Also note that one data packet (with header) is
sent per check result, so we must define the length of the packet to
know where to expect the next header.

As for the padding, I not sure what the purpose is (I guess
performance...). While we could pad any version >3, the current version
(3) is a static size.

If you have time to look at the current protocol and draft something
backward-compatible, convenient and extensible it would be awesome.

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

iD8DBQFHRx7V6dZ+Kt5BchYRAv+wAKC4jh63Z76wo6YVMJnzctqEIB4LZQCdFbTq
mmSHCSdNOEgEyhRVWuOxlMc=
=GEV3
-----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