Timeout during UPnPContext shutdown

The function PUPnP::terminate(std::condition_variable&), which is called when UPnP shuts down, includes the following line:

cvOngoing_.wait(lk, [&]() { return ongoingOps_ == 0; });

This line frequently (though not always) takes a very long time to complete due to a timeout in PUPnP::downLoadIgdDescription. More specifically, PUPnP::downLoadIgdDescription calls UpnpDownloadXmlDoc, which calls UpnpDownloadUrlItem, which calls http_Download, which calls http_RequestAndResponse. The http_RequestAndResponse function returns a UPNP_E_SOCKET_CONNECT error code after its attempt to establish a connection (via a call to private_connect) fails. This can cause a delay of over two minutes when closing Jami if multiple downloads fail (which does happen - I often got four failure while testing, e.g.:

PUPnP: Discovered a new IGD [uuid:C084EDD9-1DE4-9E6A-DEAD-34A8C7031F76 url: http://192.168.51.82:1780/InternetGatewayDevice.xml]
PUPnP: Discovered a new IGD [uuid:0F2A137C-6FF1-C2BE-A962-0150A7DA9FA9 url: http://192.168.51.82:1780/InternetGatewayDevice.xml]
PUPnP: Discovered a new IGD [uuid:64D4257E-8CFC-3924-97C1-9183CCBFEDB1 url: http://192.168.51.82:1780/InternetGatewayDevice.xml]
PUPnP: Discovered a new IGD [uuid:08780A31-017A-6198-F7A9-0B060FA1B336 url: http://192.168.51.82:1780/InternetGatewayDevice.xml]
[...]
Error downloading device XML document from http://192.168.51.82:1780/InternetGatewayDevice.xml -> UPNP_E_SOCKET_CONNECT
Error downloading device XML document from http://192.168.51.82:1780/InternetGatewayDevice.xml -> UPNP_E_SOCKET_CONNECT
Error downloading device XML document from http://192.168.51.82:1780/InternetGatewayDevice.xml -> UPNP_E_SOCKET_CONNECT
Error downloading device XML document from http://192.168.51.82:1780/InternetGatewayDevice.xml -> UPNP_E_SOCKET_CONNECT

)

changed the description

The private_connect function behaves differently depending on whether the UPNP_ENABLE_BLOCKING_TCP_CONNECTIONS macro is defined or not. If it is, then private_connect simply calls connect (the system call), which can take a long time to return in case of a ETIMEDOUT error. If the macro is not defined, then private_connect will call Check_Connect_And_Wait_Connection, which sets a more reasonable timeout limit (5 seconds).

It seems that the blocking_tcp_connections option is enabled by default in the upnp library, which was causing the issue described above.

closed

mentioned in commit 808db4f6