TCP Remoting.

  • Thread starter Thread starter GobinathP
  • Start date Start date
G

GobinathP

Hi All,

I have a remote C# application running and I need a client to create an
object of the remote application.

I use TCP connection for the remoting.

In the Server side I have this code.


RemotingConfiguration.RegisterWellKnownServiceType(typeof(URTServiceFactory)
,"URTServiceFactory",WellKnownObjectMode.Singleton);



In the client side I have this code.


//make the tcp string based on the machine.

string sTcpStr = "tcp://";

sTcpStr += ( (machine=="") ||
(string.Compare(machine,"local",true)==0) )?"localhost":machine;

sTcpStr += ":801/URTServiceFactory";

//step 3 register all objects

RemotingConfiguration.RegisterWellKnownClientType(typeof(URTServiceFactory),
sTcpStr);

URTServiceFactory fact = new URTServiceFactory();

m_PlatService = fact.GetPlatformService();



The problem is - I'm able to create the object and use it. But the client is
a UI and I store the object created as member variable and use it when
necessary. If the object doesn't get used for sometime then it starts giving
error. I assume there is a timeout interval after which the connection gets
dropped.

Any idea how to set the timeout interval to infinity. Or is the mechanism
I'm using is wrong?

Thanks,
Gobi.
 
Take a look at RemotingServices.GetLifetimeService - although you need to be aware that you are probably trying to implement a bad design by holding an object live on the server for the lifetime of the client.
 
Thanks for the reply. I was able to get it working.

Why is it a bad design to hold an object in Server for the lifetime of the
client. Isn't this what we do in our COM days?

Or it there any mechanism other than tcp which is ment for COM like approach
and I'm using the TCP channel for the wrong purpose?

I have just entered the .net arena... Your inputs would be of much help.

Gobi.

Niroo said:
Take a look at RemotingServices.GetLifetimeService - although you need to
Click to expand...
be aware that you are probably trying to implement a bad design by holding
an object live on the server for the lifetime of the client.
 
Yes it is what people did in the COM days and it was bad then. MTS / COM+ provided a variation on this theme where the client held a long lived reference but the server objects came and went (JIT activation). This is a better model since it makes the server more scalable

I'm not certain what the requirements for your software are, so what I'm saying applies in general and there will be specific cases where other choices are better. If there is just one client app talking to your service then the design is fine

The best general design pattern is for your server objects to be single call. If they need to maintain state across calls this can be persisted somewhere e.g. a database or a singleton object in the same appdomain (with appropriate locking to preserve consistency in the face of updates from multiple threads)

Bottom line is that Remoting is very flexible and supports a range of designs from COM to MTS/COM+ to service-like. History shows that service-like designs have won out and distributed object style designs were bad.
 
Back
Top