Remoting, How-to

[kejpa]

Hi,

Currently we're using VB6 and DCOM to establish communication between the server application and the client applications.

We're about to change platform to .NET (VB2005) but not sure how to handle the remote communication.

 

There are a couple of things we'd like to have:

The client should react on events raised in the server app

Connections should be possible over a network

Multiple clients should be able to connect to the server app

One or more client apps can be located on the same computer as the server app

 

Our server app will monitor and control a test environment and the current situation will be visible on client computers in "real time" (time delay ~.2s)

 

What approach should we use? Is there any good samples available. I have searched at MS but it's very hard to find out which technology to use.

Even when I have outruled SOAP it's slippery ;)

 

TIA

/Kejpa

[Diesel]

I don't know how DCOM works, but it sounds like you need to do some socket programming or RPC (Remote Procedure Calls) programming

[kejpa]

Hi again,

from what I've read it seems like I should be using .NET Remoting, but I can't find relevant samples. And I'm not sure if all the things I would like to be able to do is possible with Remoting.

So I thought I'd state what I need and ask you guys for point of directions.

 

TIA

/Kejpa

[Wile]

Before deciding on .NET remoting, there is one important question: will this be done over an internal (open) network, or do you have to take firewalls/routers/NAT/etc. in to consideration.

 

Remoting (especially events as you will find out ;)) is very hard to do if you got anything on the network that might block communication. If you have a firewall or so, your best bet would still be to use webservices.

 

I dont have experience with MS message queue. It can also handle events, but it might give more overhead than your 0.2 sec requirement, something remoting can easily reach. In our prototypes, the client->server->client roundtrip with the server running on a different machine, we didnt notice any delay at all, so it was probably under the 0.1 sec ;).

 

Some tips for remoting:

-Use the app.config file to configure the remoting with the statement RemotingConfiguration.Configure("theapp.configfilename"); , it saves a lot of work in having to open tcp/udp channels with the correct settings by yourself. This has to be done both at the client side and on the server.

-Events are pretty tricky. I've worked with remoted events under a light load and they worked quite well (providing you got some settings correct, see links below ;) ), but everybody (including MS) advises against them so we changed from remoting events to implementing a callback mechanism ourselves. It feels like going back to the stone-age, having to implement your own callback mechanism, but it does give more robustness. If something crashes it is now easier to keep the system running and even 'repair' the system by restarting the crashed component.

-Do you have to take .net framework 2.0 in to account? I dont know all that will change, but considering the new Indigo communication layer MS is working on, it will probably change more than you think ;).

-Make prototypes that use the remoting communication that you want to use in the production and test it. Test it in the same scenario's as the production environment will have. You'll probably find some stuff that behaves differently than expected, but with the prototypes you can easily change stuff. With the real application that is usually a lot harder. Settings like using singlecall vs singleton have a very large impact on the design if you decide to change them.

-You'll need to share a common set of classes/interfaces between the components that remote. In this set (usually best implemented as a dll that is referenced by both client and server) the classes/interfaces that are remoted are implemented. As far as the project i'm working on found out, it isnt possible to only use interfaces between the remoting components, some actual classes have to be shared (we couldnt get around the fact that you can't create an object if you only know the interface it supports, you need to know the actual object you want to create through remoting before you can cast it to the correct interface.)

-You'll need to check threads: calls that are received from a remote object are on an any random thread from the threadpool (25 threads by default). So if you want to update the GUI, check if you need to invoke: use this.invokerequired and this.invoke. Search the forum for invokerequired and you'll find some examples.

-You might have to build in some mechanisms to make sending events from the server asynchronous. We've had a problem when a client called the server, and the server tried to use the callback to the client to send a 'event', the client couldnt update the GUI, because the GUI thread was still waiting untill the original call to the server was handled. Which couldnt get handled until the event was handled, etc. etc. Our solution was to send the events asynchronous. That allowed the original call to return to the client so the event that was send on another thread could be handled.

 

some links:

-http://www.codeproject.com/soap/remotingsimpleeng.asp

-http://www.gamedev.net/community/forums/topic.asp?topic_id=208478

 

And a really good book I can advise about remoting (I've got it on the project and I keep having to get it back from some colleges ;) ) is

Advanced .NET remoting, by Ingo Rammer, ISBN: 1-59059-025-2 and a link to the publisher http://www.apress.com/book/bookDisplay.html?bID=47 although there is a new version of this book so you might want to get that one.

[kejpa]

Hi!

will this be done over an internal (open) network, or do you have to take firewalls/routers/NAT/etc. in to consideration.

Yes, the idea is to have it all in an open network. Later there might be requests for access over internet, but then we might have to add webservices to the system. There's really no need for the main office to have on-line data, what they're interested in is statistics and that can be supplied through webservices.

 

 

-Do you have to take .net framework 2.0 in to account? I dont know all that will change, but considering the new Indigo communication layer MS is working on, it will probably change more than you think ;).

Yes, the idea is to skip the first .NET (beta) versions and jump from VB6 to VB2005

 

 

Thanks a lot for your input!

Regards

Kejpa