Run some tests on Windows#415
Open
chrysn wants to merge 23 commits into
Open
Conversation
This is a bit excessive in terms of the cases it covers, but currently necessary because the regular Site handling of UPA is otherwise not visible to aiocoap-rd.
The fallback check was erroneous as every Message has a request (but it may be None). This triggered when data POSTed to the registration resource had no content format.
The failure to recognize the own remote is covered up by determine_remote creating a sufficiently similar object after it was not recognized in the fast path. This change prepares for remotes being reused more.
The test counts messages, and on loaded systems, it can easily trigger due to the high number of repetitions.
The functions have been split that way already in the lower parts of MID handling, and this allows for a future two-pass interface. This has a regression in that fill_or_recognize_remote now fails when called by a user; a determination has yet to be made whether that is even considered public.
This allows using role reversal when multiple ports are in use: Only if no transport "feels responsible" for a message, other transports (starting from the first) are asked whether they can route it.
On the off chance an application is using this even though it was not described as stable, things should (!) keep working with a warning.
Owner
Author
|
The biggest roadblock to using something udp6-ish (maybe in future by using connected sockets for some tasks to get around the need for recverr, or by using MacOS style ICMP sockets if they run on Win too) even on Windows is that for recvmsg we run an own RecvmsgDatagramProtocol, and that'd need a different impl on Windows because there is no add_reader there. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In the latest update to udp6 I claimed that RECVPKTINFO was widely supported by now, so I thought I'd just run tests on Windows to see whether this even applies there. (Works on the widesprad UNIXes, including Android and MacOS in recent Python versions).
Turned out that while IPV6_RECVPKTINFO is still not there yet, according to https://learn.microsoft.com/en-us/windows/win32/winsock/ipv6-pktinfo they just use a different name for the same thing, so giving it a try.
(Running on GitHub as they're offering Windows runners; I get that Codeberg can't do this, but providing proprietary OS runners is probably the one thing GH is good for now still).