> On 5 Aug 2008, at 08:59, [email protected] wrote:
>
>> [email protected] schrieb am 05.08.2008
>> 01:32:36:
>>
>>> We've made a change to NRPE so that it can accept more data while
>>> still being backwards compatible with existing NRPE servers. Can
>> this
>>> be applied to the core code? More details at http://altinity.blogs.
>>> com/dotorg/2008/08/enhancing-nrpe.html
>> I've read the article, but I'm not entirely sure how you handle those
>> packets. Does it mean your patch raises the default size of the
>> packets to 16k? Right now nrpe allocates its maximum outputbuffer
>> and fills it with null bytes if the output is less - which is already
>> a pain in my opinion.
>> If you'd raise the output buffer from 600 bytes (or whatever it was,
>> can't recall it right now) to like 16k, that would spike up network
>> traffic tremendously and I'm quite sure that would break quite a few
>> setups. We already have someone in the german community who complains
>> about the useless ~400 bytes sent over the network
>
> No, the packets are still 1K in size. You're right that the article
> does not make this clear - I've updated it to hopefully be a bit
> explanatory.
>
> The patch makes a change so that if a response comes back saying there
> is more data to come, then check_nrpe reads subsequent packets. So to
> get 16K worth of data, it reads 16 x 1K packets.
>
> I agree the empty packets are a waste. You can't change the packet
> size without a change in the protocol since both the client and server
> expect packets at a fixed size. That's a larger (and non-compatible)
> change for the future.
>
... and it still won't do anything for the encrypted protocols, since
they require fixed-size blocks to work in any sane setting too.
--
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]