This is important to have for the fine-grained control over the
results from FindServers. Adding to the 1.3 branch as selecting the
correct result from FindServers may impact whether a connection
succeeds.
Commit ef4394b114 may have fixed the
connect timeout, but it broke async connect without timeout. That
made it impossible to continue processing during TCP handshake.
While the connect operation is in progress, the select system call
will return immediately if the timeout is 0. Do not close the
connection in this case, but allow the application to call run_iterate()
again. For the tests in the CI this makes no difference as connect
over Linux loopback interface succeeds immediately.
The client itereate call without timeout in the tests works only
if the TCP connect is instant. That seems to be the case for github
Linux continuous integration. But it may fail on other operating
systems or in real live. Set the iterate timeout after conntect
to 1 second. That should be enough for loopback interface.
Also sending an async browse request may not reach the server before
iterating it. A sleep(0) to reschedule the process is enough for
my setup. Then the server can read the request from its socket.
This commit drops the 'ua_' prefix and changes the public includes
to the form `#include <open62541/server.h>` instead of the old
`#include <ua_server.h>`
This commit adds asynchronous services to open62541 on client side
* Asynchronous service (highlevel read/write) are available through the API that is defined in
ua_client_highlevel_async.h
* Besides the services, the connection procedure is asynchronous as well.
* A client Application that uses the asynchronous API
adds requests by calling an asynchronous service (e.g., UA_Client_sendAsyncReadRequest(), UA_Client_sendAsyncBrowseRequest() )
checks for response with UA_Client_run_iterate() repeatedly
and processes the responses with user-defined callbacks
Julius Pfrommer