[Nfd-dev] ndnputchunks memory usage increases linearly with MAX_NDN_PACKET_SIZE

Susmit susmit at cs.colostate.edu
Thu Nov 23 23:41:48 PST 2017


Thanks for the explanation, Junxiao.
I see that the buffer isn't resized automatically after the packet is
signed, not sure if it's easy to do (or necessary).


On Nov 20, 2017 7:58 PM, "Junxiao Shi" <shijunxiao at email.arizona.edu> wrote:

> Hi Susmit
>
> You are not supposed to modify MAX_NDN_PACKET_SIZE constant. It's used
> internally by the library. Modifying it can cause unintended consequences
> and void your warranty.
>
>
>> My next suspect would be ndn-cxx's Encoder, which can preallocate up
>> to MAX_NDN_PACKET_SIZE bytes. However, that shouldn't normally happen,
>> because before encoding we estimate the final packet size and then ask
>> the Encoder to allocate only what's needed.
>>
>
> Correct. KeyChain::sign method allocates a big buffer to encode the Data
> before signing, and then appends the signature. TPM needs the Data's wire
> encoding before it could sign the Data, which isn't possible with an
> estimator. After the signature is created, it's faster to append it to the
> existing buffer than to re-encode (or copy) the Data into a new
> snugly-sized buffer.
> https://github.com/named-data/ndn-cxx/blob/5d0b0106dfc7675f9048976d4dd4ea
> 00e46e6c39/src/security/v2/key-chain.cpp#L438
>
> Yours, Junxiao
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20171124/41db1213/attachment.html>


More information about the Nfd-dev mailing list