This applies to client-server applications using .NET Remoting over TcpChannels when the client subscribes for data to be delivered from the server asynchronously.
The typical configuration for this kind of applications involves two communication channels:
-One channel is used when the client calls the server on a well-known endpoint to subscribe for data delivery.
-The other channel is the callback channel. Whenever server is ready it calls the client’s callback handler using an endpoint that the client provided when it was subscribing to the data delivery.
There are some issues with this scenario:
1)There are two network connections that have to be established from both sides. Each of those connections should be able to send messages in both directions – this looks like unnecessary use of resources.
2)ChannelServices.RegisterChannel method does not seem to be working when registering a TcpChannel for callbacks on a pre-defined arbitrary port numbers. The port number is assigned dynamically (TcpChannel constructor has to be provided with port property as 0) . This makes it impossible to setup firewall rules in cases when client talks to server from outside of the firewall.
Is there a way to force the server to use the original .NET Remoting channel that the client opens when it establishes connection to the server? This would solve the both problems.
I'm not sure off the top of my head how to accomplish either of those. I will say that the .NET Remoting TCP channel is optimized for inside-the-firewall scenarios and it's relatively poor in features compared something like WCF's net.tcp:// transport (which supports duplex communication over the same connection and lets you choose the port to listen on -- it even goes so far as to allow you to share that port with other processes on the same machine for additional firewall-friendliness).
I know it's a big jump from Remoting to WCF but it's something to consider given that you seem to be pushing the bounds of what Remoting is good at. -steveBrain.Save() -- http://hyperthink.net/blog