[Olsr-dev] rfc5444_reader documentation

[Henning Rogge]

On 07/16/2013 04:21 AM, Benjamin Valentin wrote:
> Thank you a lot, the example really helped understanding how the
> reader/writer is supposed to be used. I think it'd probably be helpful
> to also add addresses with addresstlvs to the example (patch attached)
> because I didn't find how they were handled obvious either.

I will add the 'address level' code to the example.


> I've then build a small 'virtual network' thing where multiple virtual
> nodes can send each other rfc5444 messages. So I had to put all state
> of the 'nodes' in a struct for each, but this didn't work with
> rfc5444_writer_content_provider - _message_content_provider.creator is
> required by the rfc5444_writer_add_address() but the addAddresses()
> callback only gets a rfc5444_writer*, the
> rfc5444_writer_content_provider is expected to be a local variable. [1]
> As a result, addresses don't get added to the packages when the same
> rfc5444_writer_content_provider gets used multiple times.

In earlier revisions the add_addresses callback also supplied the 
content provider, but I removed this from the API.

The reason was that I could not find a real-world usecase for them, in 
all the code I wrote for OLSRv2 I found no use for a content provider 
callback that is used in multiple different contexts.

In your case I would suggest using the writer reference to get the 
necessary content provider. Every "virtual node" in your experiment 
should have its own writer, so you could use a struct like this to solve 
your problem:

struct vnode {
    struct rfc5444_writer writer;
    struct rfc5444_writer_content_provider cpv1;
    ...
};

and then use the container_of() macro to transform the writer pointer 
into a vnode pointer.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:(spam-protected) http://www.fkie.fraunhofer.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6169 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20130722/fab355d4/attachment.bin>