cn-uofbasel / ccn-lite

CCN-lite, a lightweight implementation of the CCNx protocol and its variations
ISC License
74 stars 63 forks source link

remove struct ccnl_buf_s member from struct ccnl_pkt_s #282

Closed mfrey closed 6 years ago

mfrey commented 6 years ago

Description

The struct ccnl_pkt_s holds a complete byte representation of a packet in member buf (of typestruct ccnl_buf_s). However, the information stored in the raw byte representation of the packet is also stored redundantly in the struct itself. The idea is probably to send out a packet on the fly instead of marshalling or unmarshalling the packet.

Expected results

Since RAM is scarce in resource-constrained devices, removing this redundant information and introducing proper marshalling/unmarshalling in some places seems the way to go. We basically would trade a reduced RAM usage by some additional computational overhead.

Any thoughts on it?

blacksheeep commented 6 years ago

I think, the content pointer points on the buf, right?

mfrey commented 6 years ago

I think, the content pointer points on the buf, right?

That's a valid point and we should clarify tomorrow.

mfrey commented 6 years ago

tl;dr can't remove raw byte representation since we can't sign packets of non-local origin

We have to hold a complete byte representation of the packet since we can't re-create the packet out of duplicate information stored in the struct itself. In order to do so we would need be able to sign the (newly created) packets which is not possible since we don't hold the corresponding keys (which is the case if we cache content created from a different node).

An alternative to storing the information redundantly (in the struct) would be just to use the raw byte representation (of the packet) and use constants which point to the corresponding positions in the packet, e.g. if the payload of the packet would be stored at byte 33 we would have constant

#ifndef PAYLOAD_OFFSET
#define PAYLOAD_OFFSET (32u) 
#endif

But that seems to be an awful idea.