Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parsing binary protocols #31

Open
arthurschreiber opened this issue Nov 27, 2019 · 3 comments
Open

Parsing binary protocols #31

arthurschreiber opened this issue Nov 27, 2019 · 3 comments

Comments

@arthurschreiber
Copy link

I was looking through the code and noticed this project does not (yet) support parsing of binary protocols - is that something you want to add support for later? 馃檱

@indutny
Copy link
Member

indutny commented Nov 28, 2019

Maybe...?

@arthurschreiber
Copy link
Author

So I played around with this a bit more.

I added a new node type called Byte, that works like a mix between Invoke and Match - it matches any byte and then passes it on to a given code function.

It works something like this:

const p = new LLParse('example');

p.property('i16', 'value');

const uint16be = p.byte(p.code.store('value'));
uint16be.skipTo(
  p.byte(p.code.mulAdd('value', { base: 2 ** 8 })).skipTo(uint16be)
);

const artifacts = p.build(uint16be);

I've yet to figure the best way out to expose reading of values coming in in little endian order. 馃

Anyway, is this how you'd implement binary reading in llparse? Or do you have any other ideas how this could be exposed in a nicer / more consistent fashion?

@arthurschreiber
Copy link
Author

arthurschreiber commented Dec 2, 2019

Maybe it would be better to just add two new nodes for reading signed/unsigned LE and BE encoded bytes into a field:

const p = new LLParse('example');

p.property('i8', 'type')
p.property('i16', 'value');

const type = p.uIntLE('type', 1);
const valueLength = p.uIntLE('valueLength', 2);

type.skipTo(valueLength.skipTo(p.consume('valueLength').skipTo(type)));

This could automatically check that the field is large enough to read the required number of bytes into it.

This would already cover most of my needs, and should be pretty straightforward to implement, I think. @indutny What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants