search

jbaublitz / neli

Rust type safe netlink library
BSD 3-Clause "New" or "Revised" License
180 stars 35 forks source link

Evaluate nom for better parsing of packets #101

Closed jbaublitz closed 3 years ago

jbaublitz commented 3 years ago

serde might be an option for a layer underneath the Nl trait to replace or use beside the macros for serialization and deserialization. This could be beneficial for users that want to serialize a JSON representation of netlink packets for logging, etc.

jbaublitz commented 3 years ago

~@joshtriplett I've been a bit absent on GIthub mainly because I've been working on this issue for a while. I know you had previously asked why I was storing flags as a vector and I am beginning work on fixing that up in my serde implementation. I wanted to ask what you see as the best design choice here. The options I see are:~

~1. allocate a slice that has a size large enough to hold all flags~ ~2. keep it as a Vec~ ~3. store it as an integer representation~

~3 is probably the best option for obvious reasons but it will take a little bit of special handling (using TryFrom instead of From for example to make sure the Flags passed in don't overflow the integer in the case of the UnrecognizedConst variant).~

Whoops! Disregard this. I hadn't had enough coffee when I wrote this.

jbaublitz commented 3 years ago

I'm beginning to think that serde won't be flexible enough to handle this. The ultimate problem here is that serde, to some extent, doesn't seem to be targeted towards something like network packet parsing. netlink has quite a bit of conditional parsing that varies widely from struct to struct (for example, the payload type differing depending on whether the packet type is an error or not, the payload of the packet that caused the error only being returned only if the error code is non-zero and not for ACKs). serde seems to be targeted at creating a unified serializer and deserializer for a standard data-type based format and I don't think netlink works very well with this paradigm. For example, there is no way, without context, in netlink to differentiate between a u32 that is a packet length and a u32 that is simply a value. With serde, it is very hard to communicate this additional context to the deserializer because all it is seeing is a u32 with no additional information.

I've posted a longer issue here and for now, I'm changing focus to using nom which seems like it is a little bit more targeted towards my use case.