<div dir="ltr">Hi all,<div><br></div><div>we've been working on some stress tests of our Janus WebRTC server, which uses libnice for all the ICE related stuff. While it works great in general, we reach a wall much sooner than we expect, and performance start to degrade quite a bit. By doing some digging and diagnostic in the code we wrote and the one we use, we found out something we thought was weird.</div><div><br></div><div>Specifically, we noticed that the internal method that is used to send packets, nice_agent_send_messages_nonblocking (which nice_agent_send itself uses internally) has a lot of code wrapped in an agent_lock()/agent_unlock(), which locks/unlocks a global mutex, and this includes the process of physiclly sending the packet. This means that the whole library is locked until that code is called, which seems overkill. I guess the same happens in other parts of the code as well. I'd understand locking the specific agent if the purpose is thread-safety, but why lock ALL agents at the same time for each packet you send? I tried searching the archives for some info on that, but couldn't find any discussion related to this choice.</div><div><br></div><div>Since I'm already handling thread-safety for most stuff in my own code, is there any way for preventing this from happening? I guess that one possible way could be to retrieve the file descriptor from the agent object and send the packet manually myself, but while this may work in simple (host/prflx/srflx) connectivity, this would definitely not be the case when, for instance, TURN is involved, as that's one of the things the library would take care of for me.</div><div><br></div><div>Looking forward to your thoughts, thanks!<br>Lorenzo</div></div>