ZyanConnection strange thread behaviour on Unity3D

[lzaiats]

Hi,

We are using Zyan inside Unity3D instances to connect our game servers together. One issue we are experiencing is:

1. We start UnityEditor play mode and instantiates a ZyanConnection that connects to a ZyanComponentHost. It works as expected, everything is fine. We can send our objects to the other server.

2. We stop UnityEditor play mode;

3. We start UnityEditor play mode again, expecting the same behaviour as on item 1, but UnityEditor hangs and analyzing the wait chain of the UnityEditor process I found the following message: One or more threads on Unity.exe are waiting to finish network I/O

Something related to the threads inside the ZyanConnection are locking the process... I know its related to ZyanConnection becuase I did an .NET Console Application that connects to the same ZyanComponentHost used on item 1 and UnityEditor do not hangs after restarting the play mode.

I don't know if I am giving enough info, but maybe you guys can have a clue because you know better the code than me and I hadn't enough time to investigate inside your code yet too...

[lzaiats]

After some more investigation I found that this issue only occurs when I dispose and create a new client for every "handover" operation I make... Basically I was connecting to a host, calling a service, disconnecting... Everytime, for each operation... To solve the problem, I am creating a cached connection and leaving it open until the end of my app execution... Maybe I was miss-using the framework, but I think it should be nice to create and dispose multiple connections on the same application, didn't you?

[yallie]

Hello @lzaiats,

Maybe I was miss-using the framework, but I think it should be nice
to create and dispose multiple connections on the same application

Yes, that should work fine in theory, but there is a catch, unfortunately.

Zyan is built on top of the .NET Remoting infrastructure, sinks and channels, all that stuff. Being the most mature .NET communication stack, Remoting provides a very rich set of features and best interoperability between .NET and Mono platforms (used to be much more stable than WCF, by the way).

But Remoting has a bad assumption that the application doesn't usually create and destroy its communication channels on the fly. The API is mostly static, and is primarily designed to be used via configuration files. Remoting channel sink chains don't use the disposable pattern: if a channel sink uses a disposable resource like timer, there is no way to free it up deterministically. And I still don't have a clean solution to this problem.

Zyan protocols create and dispose communication channels and the related sink chains, they register and unregister channels to make sure the resources are freed. If a channel implements IDisposable (like duplex TcpEx channel), then Dispose called before a channel is unregistered. But apparently that's not enough, and sometimes issues like #29 pop up.

So yes, reusing an existing connection is a wise idea (also, it's plain faster than repeating the connection handshake routine every time).

By the way, there is a sketch of a new version of Zyan built from scratch for .NET Core. It's completely decoupled from Remoting stack, but currently it's not even beta: see Zyanea project. It supports sync and async RPC natively, but doesn't yet support LINQ, streams, events and all these Zyan goodies. However if all you need is to transfer serialized objects between servers, you can give it a try :)

[yallie]

Forgot to ask: what channel and what version of Zyan do you currently use?

[lzaiats]

@yallie I am using the latest master!

Actually we will need more than one client per server, since one server will handover to more than one server... I will test more to see if the problem occurs while opening more than one connection to the same host or if it still occurs while connectiong to different ones (our real case)!

I will take a look on Zyanea and see if at this stage it can help me!

Thanks a lot!