Skip to content
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

Support for windows platform #78

Merged
merged 103 commits into from
Jul 10, 2017
Merged

Support for windows platform #78

merged 103 commits into from
Jul 10, 2017

Conversation

jcmichelou
Copy link
Contributor

Add support for the windows (win32 with visual studio 2015) platform.
This PR incorporates as much of PR #47 as possible, after a lot of line by line cherry picking. It should be noted however that PR #47 builds on windows but is not functional, for example it does not cover receiving packets over UDP.
Changes in PR #47 related to TCP transport have been intentionally left aside.
The other notable deviation is that WITH_POSIX is no longer required and coap_config.h is not required to be included as a public header.
The included solution files build the static library, the examples and the regression test. To help building the regression test, a binary distribution of CUnit is included (in the win32 platform directory only).

obgm added 30 commits February 26, 2016 18:09
… handler

When a client sends a GET request with Observe: 1, it must be removed from
the list of observers before the resource handler is called. Otherwise, it
will add an Observe option to its response.
This change introduces a new subtree in the library's directory structure.
Platform-specific code now should be placed into the corresponding directory
in src/platform/. To illustrate this, prng.h has been split into three
distinct files, one for each platform (contiki, lwip, posix) and moved into
the respective subdirectory.
Endpoints will be attached to the context object using a new function
coap_attach_endpoint(). The sockfd component has been removed from
coap_context_t as it is accessible by the endpoint.
coap_endpoint_t has a new field 'context' that refers to the context
object the respective endpoint has been associated with, or NULL
if it is not attached to any context. An endpoint can be attached
to at least one context at a time.
This modification provides two new functions, coap_run_once() and
coap_run(), that can be used by applications to drive the library's
I/O logic.
The prototypes for coap_attach_endpoint() and coap_detach_endpoint()
were missing from this header file.
Non-blocking sockets can set COAP_ENDPOINT_HAS_DATA in flags to tell
coap_read() that this endpoint has new data available for reading.
Making the posix sockets non-blocking was missing from coap_new_endpoint().
This wasn't much of a problem because recvmsg() was called only after
select() had indicated that data is available. Setting this flag explicitly
would also allow for peeking into the socket.
coap_dtls.h defines a generic API for DTLS communication. The
initial version will use tinydtls as implementation.
coap_keystore.[hc] provides a simple data structure for managing
credentials to be used during DTLS handshake. Each coap_context_t
has its own keystore object that is independent of the actual
DTLS context. Applications can access the keystore during the
entire lifetime of the coap context. The existing implementation
is not thread-safe.
The local endpoint object, peer address and data buffer address and
length now are passed as arguments to coap_handle_message(). This
change reverts a previous attempt to provide a more concise interface
for this function that hides the actual implementation-specific data.

As the DTLS implementation needs to deal with this implementation-
specific parts, it has to be made explicit, either by making the
packet abstraction public or passing the relevant parameters
explicitely to coap_handle_message(). As this has worked smoothly
before, this approach has been taken.

This change breaks the LWIP implementation (for now). It will be fixed
when integrating the DTLS code with LWIP in this branch.
The handling of DTLS sessions has been improved so that calling
coap_dtls_send() buffers data for later delivery in case of a
successful handshake.
An application can register a callback function of type
coap_event_handler_t that will be called by the library on certain
events. Currently, the DTLS implementation invokes coap_handle_event()
with session-specific events such as session close or
renegotiation.
coap_read_endpoint() should not be called when no data is available
on the attached endpoint.
get_psk_info() now returns appropriate error codes.
The new option -u allows setting the user name (aka PSK identity) and
-k is used to specify the corresponding secret (the PSK).
The example server creates a new endpoint for DTLS-secured traffic.
The secure endpoint is bound to the port number of the unsecure
port plus one (i.e. if the default port number 5683 is used for
cleartext CoAP traffic, the secure port is bound to 5684).

This server uses the credentials "Client_identity" as user name and
"secretPSK" as password for testing. DO NOT USE THIS FOR PRODUCTION.
coap_send_impl() now decides if outbound data is passed to coap_dtls_send()
or to the registered network_send callback function.

For coap_send_confirmed() this implies that retransmitted PDUs are
passed to coap_dtls_send() as well, causing retransmissions on the
DTLS layer when the session is established. As long as the DTLS handshake
is not complete, coap_dtls_send() caches the outbound application data
for this particular PDU hence avoiding duplicate messages.
When a fatal error is detected for an ongoing DTLS session, any
retransmission is stopped and the session object is released.
…pv6 sockets are implicitly dual-stacked on Linux by default, but not on Windows).

Correctly map / unmap ipv4 addresses into ipv6 addresses so that ipv4 queries to an ipv6 dual-stacked server actually do work.
@obgm
Copy link
Owner

obgm commented May 12, 2017

Okay, now I have a VS2017 up and running. It seems that I have to "retarget the toolset" (huh?) before it even starts trying to build the library. When I do this, it starts building uri.c for "Debug DLL x64" and then complains "fatal error C1083: Cannot open include file: 'coap_config.h': No such file or directory.
So, what is the VS-equivalent of configure?

(Sorry for the dumb newbie questions -- these IDE things just hide too much information about what is really going on...)

@obgm
Copy link
Owner

obgm commented May 12, 2017

The subdirectory win32/coap-rp should be renamed to win32/coap-rd, no?

@jcmichelou
Copy link
Contributor Author

The project files are for Visual Studio 2015. VS2017 is very widespread yet. It is possible to open VS2015 project files in VS2017 as is, they will appear with the mention (2015 project) next to them in the solution or to upgrade them to use the new toolchain of VS2017. Either should work.
I have only set the build configuration for Win32, so please go to build > configuration manager ... and choose "x86" as the "Active solution platform". This should switch all the lines in the "Platform" column to Win32.

@jcmichelou
Copy link
Contributor Author

Good catch for the typo with coap-rd directory name. I will modify this and submit it as new change in the pull request. I will try with VS2017 as well. In the meantime you should still be able to build and test coap-rd.

@obgm
Copy link
Owner

obgm commented May 15, 2017

Thanks, I have managed to convince VS2017 to build the executables in win32\Debug DLL. Apparently, all executables are suffixed with a letter d before the .exe. Why is that?

coap-clientd.exe
coap-rdd.exe
coap-serverd.exe
testdriverd.exe

And: I would have expected for testdriver either to fail because of an unsupported CUnit version or to work correctly. However, calling testdriverd.exe just returns (with $? being False).

@jcmichelou
Copy link
Contributor Author

To avoid confusion, especially with DLLs, I always add a 'd' suffix to librairies and executables from a debug build. Release builds don't have the suffix. This is a personal convention. Let me know if you want the suffix removed. By the way x64 builds should work as well now with df86b74, at least I have tested with coap-client and coap-server.

@jcmichelou
Copy link
Contributor Author

Did you use the CUnit DLL built with VS2015 that I have included in the pull request ? You might have to change the PATH to make sure which one it's using or just copy the dll next to the executable. If you use one built with mingw you must make sure it was linked with the system's C library as a DLL (msvcrt.dll) to be interoperable. In VS2017, you can make testdriver the "startup project", modify the path in the "debug" options of the project if needed and run with F5 it to see the list of DLLs loaded in the "modules" tab.

@obgm
Copy link
Owner

obgm commented May 15, 2017

Regarding the d-Suffix for debug vs. release builds: Okay, this makes sense to me.

@jcmichelou
Copy link
Contributor Author

Did you succeed in running testdriver ?
Here is how I run in it from bash in Debug DLL directory:

PATH=../CUnit:$PATH ./testdriverd.exe

And the end of the output:

Run Summary: Type Total Ran Passed Failed Inactive
suites 11 11 n/a 0 0
tests 109 109 109 0 0
asserts 852 852 852 0 n/a

Elapsed time = 0.012 seconds

Let me know if you have differing results.

@obgm
Copy link
Owner

obgm commented May 17, 2017

Thanks for the hint -- no this has worked as well. I also succeeded in building the library and client/server examples for x64. Apart from a couple of warnings that we can clear up after merging this PR (PR #47 already has proper fixes for them), this looks good so far.
One thing I am not happy with is integrating CUnit. Besides making license-related questions more complex, we would need at least have to provide binaries for both, x86 and x64 platforms. Therefore, I would like to go the same path as we do for Unix platforms and let users use their local installation of CUnit.

@jcmichelou
Copy link
Contributor Author

I fixed the two warnings in libcoap. The more numerous 64 bits / 32 bits size mismatch warnings in coap-client are not platform specific, they are also harmless as far as I can tell.

@jcmichelou
Copy link
Contributor Author

I submitted a 64-bit build of CUnit if you want to test with that.
I don't see any licensing problem with the redistribution of a binary build of CUnit since it's under the LGPLv2 license which allows precisely that. The user is free to substitute its own build of CUnit instead, it's just there for the convenience of having a Visual Studio solution file that you just press "Build solution" and it builds everything. Where it is a bit different from Linux is that there is no tool on Windows to pull a package with a pre-built binary distribution of CUnit and anybody willing to build testdriver would have to modify the solution to adjust the include path and link dependencies to make it point to its own copy of CUnit.
Anyways, CUnit comes with Visual C++ project files and all I have done is open the most recent one in VS2015 and do a build. For x64 it is a bit more complicated because the code in CUnit mixes up int and size_t in printf calls and those must be patched.
If you are uncomfortable with including CUnit, then I have no problem with having it removed either.

@obgm
Copy link
Owner

obgm commented May 31, 2017

I am in favor of removing CUnit.

…oject is no longer by default as part of the solution.
@jcmichelou
Copy link
Contributor Author

OK. I removed CUnit.

…inydtls support

# Conflicts:
#	Makefile.am
#	configure.ac
#	examples/client.c
#	examples/coap-rd.c
#	examples/coap-server.c
#	include/coap/address.h
#	include/coap/coap_io.h
#	include/coap/net.h
#	include/coap/prng.h
#	libcoap-1.map
#	libcoap-1.sym
#	src/net.c
#	src/platform/posix/coap_io.c
@obgm obgm merged commit 5b1a8f6 into obgm:develop Jul 10, 2017
@lgrewe lgrewe deleted the win32 branch August 17, 2017 13:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants