-
Notifications
You must be signed in to change notification settings - Fork 119
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
Microsoft Windows not fully supported #27
Comments
If I modify the
And then modify the call in
Then if I request
Not sure yet what the root cause is. Somebody else had the same problem here: http://stackoverflow.com/questions/31371055/trying-to-connect-to-coap-resource-with-python-library |
mh, the options in create_datagram_endpoint you've changed basically turn everything into ipv4-only. while windows is not exactly on my planned list of supported platforms, it'd be nice if it worked there too; suggestions on how to properly open an ipv4 and ipv6 socket on windows are welcome. (note that it might not be possible to open a IPv6_V6ONLY=0 socket on windows at all, even some BSDs refuse that, and i might need to adapt the endpoint implementation to support multiple interfaces for them too). |
Hi, |
koikos, can you please provide an example of how this declaration is made? |
With the latest HEAD, most socket stuff is packed in |
HI chrysn, have this issue been sloved yet ? And what's your " explicitly spell out the IPPROTO_IPV6 " means ?? |
There have not been any updates; I don't have any version of Windows in use, so I need to rely on user feedback and patches. "spell out the IPPROTO_IPV6" refers to koikos' comment about using the constant value instead of the import. Mapped to the current code base, that would mean replacing all occurrences of Of course, if those constants were defined somehow in Windows as well, instead of dropping code, the proper constants for Windows could be substituted like should be for IPPROTO_IPV6. On my system, |
hello chrysn !
Thank you !!!! |
On Sun, Jun 12, 2016 at 12:47:58AM -0700, ChangSam wrote:
The only file this should need replacement in is
Well, finding IN.IPV6_RECVERR is one step in dropping all contants about
The test suite passes after replacing all occurrences of You can limit the tests to the server-side tests ( In case this works with github mail replies, I've attached the |
@ChangSam, could you try again with current master and an up-to-date Python? The IN module failures now have a fallback, and with https://bugs.python.org/issue6926 closed, the numbers in socket should be complete again. |
Hello chrysn:
Thanks for your reply !
but it seems still have some issues in windows environments (0001.jpg)
( I use IPv6 as my Coap url )
and if there are other fix solution will be great!!
By the way, This project running very well in the linux environments,
Thanks a lot !!!!!
2016-11-17 16:20 GMT+08:00 chrysn <notifications@github.com>:
… @ChangSam <https://github.com/ChangSam>, could you try again with current
master and an up-to-date Python? The IN module failures now have a
fallback, and with https://bugs.python.org/issue6926 closed, the numbers
in socket should be complete again.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#27 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AQJUysh8oz0i6vnUUYDohiqIKoVA2rwtks5q_A5KgaJpZM4FtfbZ>
.
|
Some platforms (read: Windows) don't have a readline; things still work without, it's just more clumsy to use. Contributes-To: #27
@ChangSam, the attachment got stripped, but i got myself guest access to a Windows machine now. @2trc, could you subscribe here too? then i can close #52 and focus windows efforts here. The sub-issues seem to be:
i see three ways to go on about this:
c) looks like the sanest one – i just have no clue where to find the suitable api documentation, and whether that api would be available in python. b) sure would be a lot of work, and while i had contemplated doing it before i found recvmsg, it'd be too much effort for me just for windows support. a) sound like asking for bug reports. |
Hello chrysn:
I wanna ask a question about observe CoAP, and thanks for answer to me
The IEFT defines that the
observer can subscribe to listen for "any change" in the state of an
observable subject.
which means that if the "state change" or "after a certain second(max age
time)doesn't appear state change" ,it will return the observe payload
so ,if the observe server uses "time" as observable_resource ,by
IEFT difinision, it will sent oberserve value return to observer "every
second"
because time update every second,rather than by a certain (max age time) to
sent.
Or we can just say that because time varies to fast, so we only need to
sent by certain seconds, is this statement also follow observe rules by
IEFT?
thanks!!!
Sam Chang
2016-12-13 3:17 GMT+08:00 chrysn <notifications@github.com>:
… @ChangSam <https://github.com/ChangSam>, the attachment got stripped, but
i got myself guest access to a Windows machine now. @2trc
<https://github.com/2trc>, could you subscribe here too? then i can close
#52 <#52> and focus windows
efforts here.
The sub-issues seem to be:
- Asyncio's sock.getsockname() seems to be untimely or otherwise wrong
(that's the WinError 10022 also discussed on stackoverflow), but this looks
like a Python problem to me. i've crudely removed the line where the
exception is raised from from the system library; obviously, that's
something one can only do during development if at all.
- aiocoap-client's readline import got a try-except-pass guard around
it, given that readline is completely optional there, and just not
available on windows.
- socket.IPPROTO_IPV6 is not defined on windows; that can be fudged by
just setting IPPROTO_IPV6 to a constant value (41) – should go into
aiocoap/util/socknumbers then
- setsockopt IPV6_RECVPKTINFO does not work, because RECVPKTINFO is
not defined. even if we defined that, it would be no good, because
- (and that's the gravest) there is no recvmsg on windows. recvmsg is
used instead of recvfrom to get information about the package's destination
address (that bites when a host has multiple fully-routed ip addresses),
and information about icmp errors (without, waiting for errors does become
boring).
i see three ways to go on about this:
- a) implement a "stupid" udp transport that only uses recvfrom,
ignores icmp, and just will just randomly work or not work on systems with
multiple ip addresses
- b) implement a udp transport that only uses recvfrom, but internally
creates a connect()ed socket for each communication partner for outgoing
connections, and/or (?) a socket for each local interface (which also means
enumerating ip addresses and binding to new ones as they appear to simulate
being bound to "::" / "0.0.0.0"). that should allow receiving (at least
some) errors and gives a sending address on returns.
- c) implement a udp transport that is windows specific; it could use
any windows api that's suitable, as posix systems would just use the
existing one.
c) looks like the sanest one – i just have no clue where to find the
suitable api documentation, and whether that api would be available in
python. b) sure would be a lot of work, and while i had contemplated doing
it before i found recvmsg, it'd be too much effort for me just for windows
support. a) sound like asking for bug reports.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#27 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AQJUyk5qG-XX27dbfrv-ksYNSuugVgm8ks5rHZ3CgaJpZM4FtfbZ>
.
|
@tcareynokia has implemented a) in https://github.com/tcareynokia/aiocoap/commit/f1e8e5ad3d8233ee67d90350d3ec0078119301d4 . tim, could you tell about how things worked out with your changes? |
Hi - I have it "working" but there are problems - related to windows.
BR, |
Not a full solution, but the simple6 backend in the simple6 branch allows at least client operation; by setting Could someone who has a Windows instance around give this a try? coap://coap.me/ is a usable test server, given that aiocoap can't provide a test server on the same host. |
The simple6 branch is now gone and merged into master; please test whether the latest development version can run |
I think this only works if you actually have V6 connectivity, which is not available here. I've followed this bug into aicoap – the problem for me seems to be that aiocoap requests AI_V4MAPPED addresses, but IPV6_V6ONLY is set on sockets by default on Windows. There does not seem to be a way to switch V6ONLY off in asyncio. I've reported a python bug at https://bugs.python.org/issue36208. Additionally, I have "implemented" a "simple4" transport by copying the "simple6" transport and replacing every mention of V6 with V4. See PR #141 for this. |
@jeeger, I don't have a Windows machine to test, but could you try out the simple6 transport and just remove the family and flags lines there? I haven't run all the relevant tests yet, but looking at your PR it occurred to me that we might not need to keep two separate versions around. |
Uh, of course. There are only 2 relevant changes in the simple4 transport (removal of those two lines), but the addition of a new transport was the easiest way to integrate it "cleanly" into aiocoap. What would you suggest as a way to pass configuration arguments to the transport? Then we would just remove AF_INET6 and the AI_V4MAPPED argument if this argument is passed. |
My hypothesis is that we don't need configuration here -- I'd go for just removing the two lines from the simple6 transport (which'd then be renamed to simpleclient transport or so). I can test that on Linux (it works for the simple cases) but could need help testing that on Windows. (The simple transports should not rely on any structure of the address anyway but are more "make do with what's everywhere" alternatives for platforms that don't support all the POSIX flags to do it right.) |
Ah, okay! I'll make it another pull request then! |
I've removed the flags, however, I'm unable to test it on a device with V6 connectivity. |
Thanks, merged; that looks good and should make working on Windows less painful. Still not closing this whole issue as the discussion on python/cpython#11784 (following some links from the issue you opened at bpo) indicates that full support on Windows can be possible. |
This issue practically depends on https://bugs.python.org/issue36217 now; please open a dedicated issue if something doesn't work on Windows. |
I've posted a long summary of the current status in the MacOS thread, which applies to Windows as well. |
and
The text was updated successfully, but these errors were encountered: