Originally posted by **ofacklam** August 13, 2024
Hello @paullouisageneau!
Thanks a lot for the great libdatachannel and libjuice libraries.
I recently came across an interesting behavior in our application which was related to the conn_lock handling of the libjuice agent.
Basically, the flow was as follows:
1. The application receives the remote offer and some ice candidates.
2. libdatachannel PeerConnection starts the ICE agent with a STUN server.
3. At this point the internet connection breaks away.
4. Even though [here](https://github.com/paullouisageneau/libjuice/blob/master/src/agent.c#L314) `agent_resolve_servers` is started in a separate thread, it still locks the connection with `conn_lock`. However, the STUN server address cannot be resolved, so this is stuck for ~30 seconds.
5. In the meantime, the app tries to `addRemoteCandidate`, but this need the connection lock.
So now the app and the entire system is blocked waiting for the address lookup to time out. Nothing critical, but feels a bit weird.
**My question would be:**
- is this expected behavior?
- is it really required to have the `conn_lock` for the whole duration of resolving the servers?
- or is there a way to configure the address lookup timeout to make this process snappier?
Thanks
Oliver
Discussed in https://github.com/paullouisageneau/libjuice/discussions/264