<p dir="ltr">Thanks Francis. I think I will try to create the http request and have a timeout and if the timeout exception is thrown just return as to not block and impact the actual request being fulfilled.</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Sep 15, 2016 3:44 PM, "Francis Dupont" <<a href="mailto:fdupont@isc.org">fdupont@isc.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yusef Shaban writes:<br>
> I am curious how the hooks lib works in kea, specifically are the user<br>
> built hooks called asynchronously, in that, if a user hook failed it is<br>
> non-blocking and will allow the request to be fulfilled?<br>
<br>
=> hooks are synchronous. BTW it is a bit hard to make DHCP processing<br>
asynchronous, e.g., you need to keep the context without creating state<br>
and possibly memory leaks, but it is not impossible, e.g., DHCPv4 over<br>
DHCPv6 is asynchronous on the DHCPv6 side (this is why the ISC DHCP<br>
implementation of this (Kea follows the same model) is incompatible<br>
with delayed ACKs). Another point is Kea is currently not multi-threaded<br>
(again DHCPv4 over DHCPv6 is an exception because it uses 2 processes,<br>
one managing the DHCPv6 part, the other the DHCPv4 part).<br>
<br>
Regards<br>
<br>
Francis Dupont <<a href="mailto:fdupont@isc.org">fdupont@isc.org</a>><br>
<br>
PS: about your example you have a trade-off between reliable and blocking<br>
vs not reliable and not blocking. Note DHCP itself is not reliable,<br>
this means if you drop a request the client will retransmit, and on<br>
the other side the reply can be lost too.<br>
</blockquote></div></div>