after connection initiation rather than 0 seconds after.
Successive PUSH_REQUEST messages after the first will continue to be
sent at 5 second intervals until a response is received. This tends
to speed up the client connection sequence by 4 seconds because the
first PUSH_REQUEST message is usually sent too soon and is dropped,
causing a wait of 5 seconds until the next PUSH_REQUEST message is
sent.
Version 2.1_rc19d
git-svn-id: http://svn.openvpn.net/projects/openvpn/branches/BETA21/openvpn@4965
e7ae566f-a301-0410-adde-
c780ea21d3b5
check_push_request_dowork (struct context *c)
{
send_push_request (c);
+
+ /* if no response to first push_request, retry at 5 second intervals */
+ event_timeout_modify_wakeup (&c->c2.push_request_interval, 5);
}
#endif
0);
}
#endif
- send_push_request (c);
-
- /* if no reply, try again in 5 sec */
- event_timeout_init (&c->c2.push_request_interval, 5, now);
+ /* send push request in 1 sec */
+ event_timeout_init (&c->c2.push_request_interval, 1, now);
reset_coarse_timers (c);
}
else
et->last = now;
}
+static inline void
+event_timeout_modify_wakeup (struct event_timeout* et, interval_t n)
+{
+ /* note that you might need to call reset_coarse_timers after this */
+ if (et->defined)
+ et->n = (n >= 0) ? n : 0;
+}
+
/*
* This is the principal function for testing and triggering recurring
* timers and will return true on a timer signal event.
dnl define the OpenVPN version
-define(PRODUCT_VERSION,[2.1_rc19c])
+define(PRODUCT_VERSION,[2.1_rc19d])
dnl define the TAP version
define(PRODUCT_TAP_ID,[tap0901])
define(PRODUCT_TAP_WIN32_MIN_MAJOR,[9])