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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Waiting for <N> bytes of socket input #158

Open
lukego opened this issue Jun 22, 2018 · 1 comment
Open

Waiting for <N> bytes of socket input #158

lukego opened this issue Jun 22, 2018 · 1 comment

Comments

@lukego
Copy link

lukego commented Jun 22, 2018

Is there a way for an event handler to detect when at least N bytes of input are available on a socket?

I am implementing a protocol where I know how big each message will be and it seems neat to allow partial messages to be buffered in cl-async and only read when completely available. Just now I am not seeing a way to e.g. check how many bytes of input are available on a stream.

(I am also confused by the examples of reading from streams in socket callbacks. Are those blocking reads that can hang the event loop? Can you use the non-auto-draining stream interface when you want to strictly avoid blocking operations?)

@lukego
Copy link
Author

lukego commented Jun 26, 2018

Just thinking aloud...

I saw a crossroads. On the one hand I can keep my code simple and have cl-async accumulate data in the input stream and always give me complete messages. That seems to require exposing more information about the buffer inside the stream object. On the other hand I can do the buffering myself. That seems potentially simpler in operational terms because then I operate on the data immediately when it is delivered by the libuv callback without intermediate buffering in a cl-async stream object.

I am trying the second route at the moment. Instead of reading whole known-size messages from cl-async streams I am just running a state machine on each byte of input.

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

1 participant