Consideration of initial Read() buffer size

[codedance]

Following on from comment here:

3e6fc99

Auto scaling the initial buffer size based on the oid count is clever (marshal.go => dispatch() ). It's a compromise between memory usage vs possible network re-requests. For typical numeric values the current defaults will be fine but it may cause issues with OctetStrings?

For reference, both snmp4j and net-snmp defaults to ~64k buffers (e.g. max datagram size). Max OctetString in the RFC is 65535

I have a dozen or so different snmp devices in here. I'll do some scanning and see what pops up.

[codedance]

Distributions of OctetString size (bytes) across 20k+ values all from many different real-world devices (mostly printers and routers)

Mean: 10 bytes
Max: 256 bytes

[codedance]

I've done some more real world testing and experimenting. I'll put together a pull request to make a minor buffer size change building on @benjamin-thomas wonderful addition. In short, when we're walking (GetBulk) the pdu count is only 1, but the returned number of PDUs will be many more (MaxRepetitions). This leads to many retries. It's an easy fix.

Also while playing I found a Windows specific bug. A read on a buffer that's too small results in an error rather than a partial buffer read. I'll fix this in the same pull request.

[codedance]

OK. I've just filed a pull-request for @soniah to do a quick review (#46).

Summary of findings:

• A 1k initial buffer is fine for all real-world GET requests. The max size OctetString I found on a real-world device was 256 bytes.
• GETBULK needed some special handling.
• Interestingly SNMP4J and net-snmp have fixed buffer sizes like the old code.

[codedance]

Closed a while back in #46