What steps will reproduce the problem?
1. Enable mod_limits
2. Exceed the limit
3. Send data while over the limit
What is the expected output?
Data is processed in order
What do you see instead?
Data
What version of the product are you using? On what operating system?
Reproduced with Prosody trunk rev 12a31296d63d
Running Debian Testing
Please provide any additional information below.
When processing the result of reading from a socket, any received data is dispatched to the onincoming listener before processing the error message.
The common case is assumed to be that the error is "timeout", meaning to just wait until it becomes readable again.
When using LuaSec, it will sometimes return "wantread" and "wantwrite", indicating that the TLS layer wants to receive or send more data.
This is handled by ensuring that the socket is set to be polled for the respective state.
This is also how connection pausing is implemented, by changing the poll state to not watch for being readable.
If the connection is paused (by eg mod_limits) this would be reverted by a "wantread" error.
https://hg.prosody.im/trunk/file/12a31296d63d/net/server_epoll.lua#l342
ge0rg
on
This is a very technical description of the internal state. Will this be seen by a user as a "not-well-formed" stream error or another stream shutdown?
Zash
on
Seems I submitted a bit early.
What do you see instead?
Data arriving in different reads get mixed.
E.g. given an input stream like (newlines represent packet / read boundaries)
aaaaaa
bbbbbb
May end up like (once rate limits set in)
aaa
bbb
aaa
bbb
Likely to mess up everything with a syntax.
If you are very lucky, you might end up with
<message><body>hello <message><body>hello hello</body></message>hello</body></message>
Changes
owner Zash
tags Status-Started
titlenet.server_epoll net.server_epoll handling of 'wantread' condition unintentionally resumes paused connection
What steps will reproduce the problem? 1. Enable mod_limits 2. Exceed the limit 3. Send data while over the limit What is the expected output? Data is processed in order What do you see instead? Data What version of the product are you using? On what operating system? Reproduced with Prosody trunk rev 12a31296d63d Running Debian Testing Please provide any additional information below. When processing the result of reading from a socket, any received data is dispatched to the onincoming listener before processing the error message. The common case is assumed to be that the error is "timeout", meaning to just wait until it becomes readable again. When using LuaSec, it will sometimes return "wantread" and "wantwrite", indicating that the TLS layer wants to receive or send more data. This is handled by ensuring that the socket is set to be polled for the respective state. This is also how connection pausing is implemented, by changing the poll state to not watch for being readable. If the connection is paused (by eg mod_limits) this would be reverted by a "wantread" error. https://hg.prosody.im/trunk/file/12a31296d63d/net/server_epoll.lua#l342
This is a very technical description of the internal state. Will this be seen by a user as a "not-well-formed" stream error or another stream shutdown?
Seems I submitted a bit early. What do you see instead? Data arriving in different reads get mixed. E.g. given an input stream like (newlines represent packet / read boundaries) aaaaaa bbbbbb May end up like (once rate limits set in) aaa bbb aaa bbb Likely to mess up everything with a syntax. If you are very lucky, you might end up with <message><body>hello <message><body>hello hello</body></message>hello</body></message>
Changesnet.server_epollnet.server_epoll handling of 'wantread' condition unintentionally resumes paused connectionFixed in https://hg.prosody.im/trunk/rev/485231f8b75d
Changesnet.server_epoll handling of 'wantread' condition unintentionally resumes paused connectionnet.server_epoll handling of 'wantread' condition unintentionally resumes paused connection, breaks mod_limits