Remoting: Inter object communication.

Nathan Tran

Hi, I'm trying to code a chat server that supports tcp/udp connections as well as connections through remoting if the client is behind a firewall. How can I implement the server so that it will support both types of clients? The problem is that remoting requires the server object to be activated by the client but I need the server to be running all the time to support clients that are not using remoting to connect to it. So the question is, how does an pre-existing object ( instantiated before the activation of the remoting object ) communicate with an object that is activated remotely by a client? The existing object and the activated object are in the same application domain ( I presume ). This problem has been bugging me for days. I searched the net and there are a whole bunch of remoting tutorials, but none touches on this particular subject. Hopefully, some one here has a clue. Nathan.

John Rayner

Well, if I understand you correctly you are trying to get your chat server to send a message to the chat client. This message would probably be a new posting to the current discussion. Not having done this before, I'm probably a little out of my depth but here goes anyway ... Firewalls are obviously going to limit a direct TCP / UDP connection from the server to the client so that option is out. That means that all communication has to be initiated by the chat client. So two options spring to mind:

Have the client poll the server every so often - you don't really get instant chat here and the closer you get to it (i.e. by polling more frequently) the more it clogs up your network and your server.
Have the client initiate an asynchronous request to the server which blocks until the server services it. Then, when a new message comes in to the server it hands the message off to the client. The client sees the response come back and immediately opens another async request.

You'll need a reliable way of identifying individual clients - if you're concerned about firewalls then I don't think IP address will be good enough. Probably each client would need to get an ID from the server and send that along with every request made.

I'd say the second is preferable from a network traffic and immediacy point of view, but it probably won't scale with the number of users (e.g. 5000 users = 5000 connections at the server waiting to be filled). But then who'd want to be in a discussion with 5000 people?!? It will also make the server quite complex to implement as it will have to keep track of which messages have been passed out to which clients. Also, if you have a very active discussion, the client may struggle to keep up - this could be avoided by each client having a number of outstanding requests to the server, but that would further limit the scalability. Anybody else have any other ideas?

Nathan Tran

John, AFAIK .NET remoting supports serialization of client objects across channel by reference. I am banking on this reference to the client object to maintain a "connection" between server-client. To send a message back to the client I can simply call clientObjectRef.MsgServicingDelegate( Msg ); Indeed this solution will pose a scalability issue since, in affect, the client maintains an open channel with the server. Is this a wise solution? To what extent is the overhead required to maintain an open httpChannel? More importantly, how does the underlying framework acheives this feat? Nathan.

John Rayner

Well, I wrote a little test app to try what you are suggesting and it didn't work. I got the very long error message "This remoting proxy has no channel sink which means either the server has no registered server channels that are listening, or this application has no suitable client channel to talk to the server.". Hats off to MS for at least trying to make their error messages informative ... ;) A little digging on the web revealed a sample chapter from a Wrox book (http://www.wrox.com/books/sample-chapters/SampleChapter_186100740x.pdf[^]) which discusses a similar problem. If you look on page 24 of the PDF you'll see that they set the client app with a Remoting channel in order for the server to communicate with the client. Once I'd modified my test app in this way, everything worked. However, I very much doubt that this will work if there's a firewall in the middle of the connection (which was the problem we were discussing).

Nathan Tran

Hi John, For communicating across a firewall I believe you have to set the HttpChannel on the client side to port 80 or a port that is not blocked. I haven't tried this myself since I'm still coding the message/user handling routines for my chat server. If you have time on your hands could you verify this? Thanks. Nathan.

John Rayner

It's not the port number that you've got to worry about. It's more the address translation and usual firewall rules base which are going to be issues. Firewalls, in general, don't allow incoming requests to an arbitrary machine protected by them, whatever the port number, unless they have been specifically configured to do so. It's quite usual for them to allow outgoing connections to any server on port 80, but that's a very different thing. And no, I'm not going to setup a firewall with machines on both sides just so I can test something for you which I don't think will work anyway. Sorry mate, I'm not quite that helpful ...