Client/Server connection woes

I've written a client/server model in C# using .Net remoting. If I have the client connected to the server, then kill the server and restart it without trying to call any server methods from the client whilst the server is down, I can reconnect happily.

If I close the server then try to ping the server from the client (which I do from a separate thread to avoid an endless wait) then when the server comes back online, the client can never talk to it and my Ping thread that was fired during the downtime waits forever deep in the guts of the remoting libraries. I try to Abort this (if trying to Join the thread fails after a short time) but it won't abort. I'm wondering if this is part of the problem.

If I start up another client, then that client can talk to the server just fine. I figured I needed to restart some aspect of the original client but cannot see what would need to be shut down. I certainly null the server I'm connected to and call Activator.GetObject with the same address (something the second client does to connect to the server, which works fine), but re-getting the server doesn't help at all.

The server is running a as singleton via RegisterWellKnownServiceType.

From stackoverflow

• I would start with wireshark and use it to see what is really going across the wire.

• Is .NET remoting a requirement, or could you consider moving to WCF instead? The protocols are better factored and more clearly exposed when needed.

  Pontus Gagge : Well, DCOM is an older far more widely used API (underpinning WMI, for instance), but has even more issues than .NET remoting (especially when aiming for security). IIOP was anything but. Part of the answer is that .NET remoting has always played second fiddle to web services, but part is that remoting protocols are just plain hard to design and implement well to cover all cases...