How to choose the best workaround for the unresponsive connection after `ProtoOAAccountDisconnectEvent`

I've opened this issue on OpenAPI Support Telegram Chat 8 July. At moment no fix was proposed by the support, so I'll open this thread hoping someone working in the Sportware dev team can help me to choose the right workaround for the issue.

The Problem

Randomly accounts authorized on an OpenAPI application receive ProtoOAAccountDisconnectEvent without any reason. It's fine, it's the network, can happens. However, immediately after this event the TCP socket become unresponsive to ANY new message I sent. Every request goes in timeout, but it still continue to receive ProtoOASpotEvent even for the account that was supposed to be disconnected :)

In this state it's impossible to send a new ProtoOAAccountAuthReq for the culprit account, the only way to get my application back is to kill the TCP connection and establish a new one (following the full auth process App → Accounts).

 The real problem comes when multiple access tokens and accounts are authorized on the same socket, each one needs to be re-authenticated… This means that if I fallow the Best Practices (https://help.ctrader.com/open-api/connection/#best-practices) and I add, let's say 300 accounts from different users, if a single one disconnect all 300 accounts needs to be reconnected from scratch. As you can see this is a terrible solution, and doesn't seems to what should be the best.

Temporary Workaround

My temporary workaround is at moment divide accounts in multiple TCP connections. Specifically, I create a new TCP connection for each user's Access Token, so each connection handles few accounts that belongs to a single user. When a disconnection happens only those are affected by the forced re-connection mitigating the issue above.

However, this solution put much more pressure on my infrastructure. More TCP connections means more threads, which means more CPU and RAM usage. Depending on the context this could have a significant impact. Moreover, this workaround doesn't fit in your Best Best Practice. 

I don't know which consequences could have on your servers too. I'm really afraid to get banned or limited because abusing of multiple TCP connections. if I have 300 users my IP will establish 300 parallel connections, is it really fine for you? 

How to reproduce the unresponsiveness

During months I was able to discover a way to always reproduce the issue. Telegram Support also confirmed that issue and with those steps also to reproduce on their side. 

It needs both an OpenAPI client and the official cTrader Desktop client (Windows tested):

1. [OpenAPI] Authorize application with protobuf protocol.
2. [OpenAPI] Authorize a trading account, add tick listeners, etc.
3. [cTrader Desktop] Login with to the same account.
4. [cTrader Desktop] Logout from cTrader Desktop.
5. [OpenAPI] Immediately a ProtoOAAccountDisconnectEvent is received and the whole connection become unresponsive, cannot send messages but still receive SpotEvents.

However, no other additional info were provided, this makes for me impossible to take a final decision on this issue. Without an official answer I really cannot go forward.

Of course, I would prefer that the issue could be fixed, but since are passed almost 6 months, I'd be happy even to have an official answer to know how to deal properly with all this mess.