Fix ws/wss tcp socket leaks, closes #162

[xadhoom]

Since sofia doesn't have a proper http client, outgoing connections with ws/wss transport are not possible.

Using the default tport_base_connect will lead into socket leaks, because they'll get created but never freed.

Instead just define the proper vtp_connect function in ws/wss tranport which will always return NULL and make outgoing ws/wss connections to fail correctly.

[freeswitch-ci-system]

Scan-build compilation failed: https://public-artifacts.signalwire.cloud/drone/freeswitch/sofia-sip/294/scan-build-result.txt

[freeswitch-ci-system]

Unit-tests failed: https://public-artifacts.signalwire.cloud/drone/freeswitch/sofia-sip/295/artifacts.html

[xadhoom]

No feedback here?

I want to give a feedback from us with a graph that speaks by itself

(The scale is written wrongly M really means GB)

This is the memory usage of FS in a production system where websockets (plain ones, not ssl) are heavily used and a lot of disconnection may happen. Those connections are pinged regularly for reachability using sofia options.

Around 22 July is where the final reboot with the above patch, see the memory graph? Speaks by itself. No other changes has been added since and traffic patterns have not changed.

[andywolk]

Would be nice to have a way to reproduce that.

[xadhoom]

Hi,

there're two points here: first a logic error, since no connect callbacks are defined in sofia ws/wss transport the default tport_base_connect is used, which is not appropriate since has nothing to do with websockets and is not handled correctly (leading to socket leaks).
So, just fixing this logic error imho is a motivation to include the patch or at least a proper fix.

Then, to simulate the leak the question is on how to force sofia ws/wss transport to do outgoing connections (which results into calling the default tport_base_connect which then create the leak because not cleared by the transport itselg).

We reproduce this by:

• set freeswitch to send option pings
• set freeswitch to not de-register the client if tcp connection closes
• abruptly interrupt the tcp ws/wss connection, in order to not clear the reg (this happens in real world scenarios where devices disappears from the network for many reasons)
• from now fs tries to send options to the ws/wss client (because even if unreach is still registered)
• wait for the leak, the rate depends on how many clients do you have and how often the option ping is done

[robertoscarpone]

Hi, I’m curious, do you use WS or WSS in your environment?

[xadhoom]

Hi, I’m curious, do you use WS or WSS in your environment?

Right now WS, proxied by nginx for SSL. WSS has some serious issues in corrupting stuff, like FS sqlite databases... go figure.

Anyway, this patch is not related to WS or WSS, it applies to both.

[robertoscarpone]

Thank you for the reply!

Anyway, this patch is not related to WS or WSS, it applies to both.

Yes, I asked you because we are struggling with SSL handling in sofia's WSS implementation.

Right now WS, proxied by nginx for SSL.

We would also like to use WS with nginx, but since it doesn't handle passing the clients IP, we can't do this right now.

[andywolk]

Fixed by #233