@danim The official client sdk is in use in production games with a vast amount of realtime features from the game server. It’s an extremely stable piece of code that we’ve designed and maintained for over 2 years. There is always improvements we can make but have had no issues with the customers who run it in their production games on mobile, desktop, and web (i.e. WebGL exports).
default one wasn’t doing things properly (no disconnect info, disconnection time out wasn’t handled correctly)
What exactly do you mean that disconnection wasn’t handled properly? Please be specific and open a pull request for any improvements you think would be good to see. This helps all developers and studios in the community and is a nice way to give back.
using a third party websocket when .net has its own seemed reasonable to me
What you probably don’t know is that Unity uses a very old System.Net.WebSockets implementation from Mono that has a known issue where sockets will be disconnected after ~300 seconds. It also has a second issue where DNS resolution fails if the IPv6 address is tried before IPv4. These both continue to be problems on the latest Unity 2018 LTS releases.
There are very specific reasons we manage the socket code the way we do. It is not a limitation of how the team thinks about Unity or .NET libraries. We strive to use the latest and greatest technologies and are always open to new suggestions. Nevertheless we also have to work within the limitations of Unity engine as a platform.
not to mention ninjasockets GitHub tells the implementation is prior 2017, before .net had provided one
You should also look at other popular projects that integrate with Unity engine like the Mirror project which also uses Ninja.WebSockets to work around bugs in the game engine. The reason Ninja.WebSockets is no infrequently updated is because it’s feature complete and stable and not because it is unmaintained.
Hope this helps.