> -----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 [email protected]
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]