Unfortunately, it is still not correct. For the first time, my client
gnutls_init(&m_session, GNUTLS_CLIENT | GNUTLS_DATAGRAM |
GNUTLS_NONBLOCK);
/* .... */
gnutls_dtls_set_mtu(m_session, 1000);
gnutls_handshake_set_timeout(m_session,
GNUTLS_DEFAULT_HANDSHAKE_TIMEOUT);
requests pull_timeout with @ms = 0. But when server became to respond,
it tries to set 4000 ms. Maybe I have to call
gnutls_handshake_set_timeout differently? Using
gnutls_dtls_set_timeouts? But will gnutls_dtls_get_timeout return
correct values in that case?
С уважением,
Юрий Шведов
WiMark Systems
On 04/30/2015 03:28 PM, Nikos Mavrogiannopoulos wrote:
On Thu, Apr 30, 2015 at 12:52 PM, Nikos Mavrogiannopoulos
<[email protected]> wrote:
On Thu, Apr 30, 2015 at 9:49 AM, Yury Shvedov
<[email protected]> wrote:
Thank you for Your reply.
So If i set my pull and push functions, which behave as non-blocking sendto
and recvfrom respectively, gnutls won't call pull_timeout function because
of GNUTLS_NONBLOCK flag in gnutls_init?
Actually I was not correct. The pull timeout can still be called in
non-blocking DTLS case, but then only with an @ms parameter of zero.
That is to know whether there are data waiting or not. If you can not
use select for that you can use recv in PEEK mode.
regards,
Nikos
_______________________________________________
Gnutls-help mailing list
[email protected]
http://lists.gnupg.org/mailman/listinfo/gnutls-help
