diff options
author | Paul Sokolovsky <pfalcon@users.sourceforge.net> | 2016-06-19 15:53:59 +0300 |
---|---|---|
committer | Paul Sokolovsky <pfalcon@users.sourceforge.net> | 2016-06-19 19:15:20 +0300 |
commit | 5071ceea077dec32536315549f8d28614f7e0cfc (patch) | |
tree | 647dccdc9fccd0498d3d79596e200d500fc41b04 /py/objrange.c | |
parent | c7fba524cb023be57f4f34c50f116197d198ec0a (diff) | |
download | micropython-5071ceea077dec32536315549f8d28614f7e0cfc.tar.gz micropython-5071ceea077dec32536315549f8d28614f7e0cfc.zip |
extmod/modlwip: Store a chain of incoming pbufs, instead of only one.
Storing a chain of pbuf was an original design of @pfalcon's lwIP socket
module. The problem with storing just one, like modlwip does is that
"peer closed connection" notification is completely asynchronous and out of
band. So, there may be following sequence of actions:
1. pbuf #1 arrives, and stored in a socket.
2. pbuf #2 arrives, and rejected, which causes lwIP to put it into a
queue to re-deliver later.
3. "Peer closed connection" is signaled, and socket is set at such status.
4. pbuf #1 is processed.
5. There's no stored pbufs in teh socket, and socket status is "peer closed
connection", so EOF is returned to a client.
6. pbuf #2 gets redelivered.
Apparently, there's no easy workaround for this, except to queue all
incoming pbufs in a socket. This may lead to increased memory pressure,
as number of pending packets would be regulated only by TCP/IP flow
control, whereas with previous setup lwIP had a global overlook of number
packets waiting for redelivery and could regulate them centrally.
Diffstat (limited to 'py/objrange.c')
0 files changed, 0 insertions, 0 deletions