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