| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
It's now used for more than just stream protocol (e.g. pin protocol), so
don't use false names.
|
|
Calling it from lwIP accept callback will lead incorrect functioning
and/or packet leaks if Python callback has any networking calls, due
to lwIP non-reentrancy. So, instead schedule "poll" callback to do
that, which will be called by lwIP when it does not perform networking
activities. "Poll" callback is called infrequently though (docs say
every 0.5s by default), so for better performance, lwIP needs to be
patched to call poll callback soon after accept callback, but when
current packet is already processed.
|
|
|
|
|
|
This requires lwIP built with LWIP_DEBUG (or it will be no-op).
|
|
|
|
|
|
Using usual call_function_*_protected() helper, to avoid NLR jump crashes.
|
|
To use: .setsockopt(SOL_SOCKET, 20, lambda sock: print(sock)). There's a
single underlying callback slot. For normal sockets, it serves as data
received callback, for listening sockets - connection arrived callback.
|
|
|
|
|
|
|
|
|
|
|
|
When lwIP creates a incoming connection socket of a listen socket, it
sets its recv callback to one which discards incoming data. We set
proper callback only in accept() call, when we allocate Python-level
socket where we can queue incoming data. So, in lwIP accept callback
be sure to set recv callback to one which tells lwIP to not discard
incoming data.
|
|
|
|
Between 1.4.0 and 1.4.1, lwIP errors were renumbered.
|
|
Per POSIX http://pubs.opengroup.org/onlinepubs/9699919799/functions/send.html :
"If space is not available at the sending socket to hold the message to be
transmitted, and the socket file descriptor does not have O_NONBLOCK set,
send() shall block until space is available. If space is not available at the
sending socket to hold the message to be transmitted, and the socket file
descriptor does have O_NONBLOCK set, send() shall fail [with EAGAIN]."
|
|
|
|
|
|
|
|
|
|
The code is based on Damien George's implementation for esp8266 port,
avoids use of global variables and associated re-entrancy issues, and
fixes returning stale data in some cases.
|
|
Instead of just delaying 100ms if event isn't yet ready.
So far applies only to default, "infinite" socket timeout.
|
|
Same code repeated for each send*() and recv*() function.
|
|
|
|
|
|
It can happen that a socket gets closed while the pbuf is not completely
drained by the application. It can also happen that a new pbuf comes in
via the recv callback, and then a "peer closed" event comes via the same
callback (pbuf=NULL) before the previous event has been handled. In both
cases the socket is closed but there is remaining data. This patch makes
sure such data is passed to the application.
|
|
For example, the peer may close the connection while recv is waiting for
incoming data.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Any fields changed by asynchronous callbacks must be volatile.
|
|
Polling once in 100ms means dismal performance.
TODO: Propagate this pattern to other polling places.
|
|
|
|
Otherwise for code like:
while (socket->incoming == NULL) {
LWIP_DELAY(100);
}
a compiler may cache it in a register and it will be an infinite loop.
|
|
These MPHAL functions are intended to replace previously used HAL_Delay(),
HAL_GetTick() to provide better naming and MPHAL separation (they are
fully equivalent otherwise).
Also, refactor extmod/modlwip to use them.
|
|
Like foo.bar or foo->bar.
|
|
|
|
With MicroPython codestyle, with pointer casts, "*" packs with primary type
without space. Few other similar changes too (git diff -b -w is null).
|
|
Based on the original patch by Galen Hazelwood:
https://github.com/micropython/micropython/pull/1517 .
|
|
|
