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

How to implement backpressure on imap-flow? #98

Open
superboum opened this issue Jan 8, 2024 · 1 comment
Open

How to implement backpressure on imap-flow? #98

superboum opened this issue Jan 8, 2024 · 1 comment
Assignees

Comments

@superboum
Copy link

superboum commented Jan 8, 2024

TCP/IP is great as if you don't read the socket, once the TCP OS buffer will be full, the information will be back-propagated through the network to the client, that will slow-down its sending. Unfortunately, we break the "backpressure-chain" as, to send data on imap-flow, you also have to read them, and thus either store it or drop it.

My current workaround is closing the socket if the client sends 10 commands in a row. But it's not ideal, and still can lead to DoS: if we consider 25MB literals, with 10 commands, it's 250MB of memory that can be allocated. Doing that in 10 or 100 of connections, and you can easily trigger an OOM on the server.

@duesee duesee added this to the 9. Higher-level, async-first, IMAP library for client- and server milestone Jan 15, 2024
@duesee duesee modified the milestones: 9. Higher-level, async-first, IMAP library for client- and server, 9. Reworked: Higher-level, async-first, IMAP library for client- and server Apr 6, 2024
@duesee duesee modified the milestones: 9.1 -- Higher-level, async-first, IMAP library for client- and server, 9. Release (draft) low- to high-level IMAP stack Jun 29, 2024
@jakoschiko
Copy link
Collaborator

We investing heavily in separating the IMAP state machine from the I/O bits. The I/O bits are now located inside of imap_next::stream::Stream and are optional. We tried to keep Stream simple because complex I/O features should not be part of imap-next, at least for now.

If something like backpressure is necessary, I would suggest to omit imap_next::stream::Stream (you can remove it with default-features = false and implement the I/O bits yourself. The state machine should give you enough control to implement anything you want and that fits your use case.

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

No branches or pull requests

3 participants