Right, the ```len``` is the length as reported by the server response.  The issue is, I believe, that the response contains more data than the server code is meant to send.  The spec maxes out the heartbeat length at 16384 bytes (2^14 - see https://tools.ietf.org/html/rfc6520#page-5) but since our heartbleed request asks for 65535 bytes by default (```heartbeat_length``` which is an option, so could be lower) we're asking the server to send more than the spec technically allows in response.

Most servers seem to oblige, but report the RFC max in their len field, so by reading only len bytes we're not parsing all the data we've asked for.  Although, we seem not to always get all we've asked for either, which complicates things further...

If we're going to stick with ```len``` here, we should at least set the ```HEARTBEAT_LENGTH``` option to a default of 16384, since that's the most data we're going to actually do anything with.  That's going to limit the amount of memory we get too though.  

In ```KEYS``` mode, anecdotal evidence shows the private key factors tend to be in the later parts of the dump, so it's a bigger deal there it seems.