NSCA bottleneck / NSCA Timestamp

[Andreas Ericsson]

Thomas Guyot-Sionnest wrote:
> -----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.
> 

Oh gee, that means I won't have time to go buy a vacuum-cleaner today.
What a shame ;-)

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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