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

Receive backpressure support #1020

Closed
ambrop72 opened this issue Mar 27, 2020 · 2 comments
Closed

Receive backpressure support #1020

ambrop72 opened this issue Mar 27, 2020 · 2 comments

Comments

@ambrop72
Copy link

Hi,
Is is possible for the application to indicate that it isn't ready to receive any more messages at this time. so the library will stop recv()-ing data from the client, until the application indicates it is ready to receive more?
Suppose that I am putting received data into a queue and I have another thread that is processing from the queue, and it is resource-intensive. I can't let the queue grow without bounds if data is being received faster than it is being processed. I need to pause receiving data until the queue has drained sufficiently.

@ghost
Copy link

ghost commented Mar 28, 2020

For compatibility with TLS you cannot stop receiving without also stopping writing, TLS cannot receive without also sending.

If you want to stop both, that could be added in uSockets like us_socket_throttle but you could probably just use us_poll_change on the socket. If you look in uSockets it should be reasonably simple to add.

A WebSocket pointer is a struct us_socket_t pointer, which is also a struct us_poll_t pointer so you can just change events being polled to nothing until done. I can't help right now but that's the idea

@ghost
Copy link

ghost commented Apr 3, 2020

This is tracked in uSockets repo, closing this as duplicate. Feel free to PR something at uSockets.

This issue was closed.
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