NSCA bottleneck / NSCA Timestamp

[Thomas Guyot-Sionnest]

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

On 21/11/07 04:09 AM, Gerd Mueller wrote:
>> I'm guessing the change would just involve a new flag to send_nsca to  
>> expect a timestamp from the input so (for example) the first field is  
>> the timestamp to use. 
> 
> Yes, what about a "-t" option for send_nsca and the nsca daemon.

If you use the timestamp already sent in the NSCA communication the
server won't require much modification (and probably no additional
switch). but the max_packet_age will likely have to be changed (defaults
to 30 seconds, and hard-coded to avoid exceeding 900 seconds). Also
time-sync between server and client will be critical unless the server
starts accepting timestamps in the future.

Ideally if you can find a way to change the server/client init so that
it's backwards-compatible while allowing newer server/clients to detect
 the version (i.e. adding a version string ignored by older clients),
the new send_nsca could always send a timestamp (set to 0 if there's no
- -t switch) on newer servers.

As I understand it the -t switch on the server would require all clients
to use the switch as well(*); in other words it breaks the protocol.
IMHO if we're to break the protocol we'd be better adding a version
string to handle gracefully any future version.

Just my 2 cents...

Thomas

* 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHRYil6dZ+Kt5BchYRAgg2AJ9qiwPOFPZHoF/XhxDZKzemIKFAaQCfaUQl
CT8MLrDGhQfOQ0WvpE2Enrs=
=oXNI
-----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/