-----------------------------------------------------------

New Message on BDOTNET

-----------------------------------------------------------
From: SitaramanM
Message 4 in Discussion

Hi Arshu/Harsha   Arshu -> Lease determines a total lifetime of the Server Activated 
Object and does not influence timeout of a client method call to a Remote Object   
Harsha -> Cant be Done.  The TCP Channel does not support the timeout property.  If 
you look at the constructor of the  HTTPChannel you will find that the following 
properties are initialized   name, priority, clientConnectionLimit, proxyName, 
proxyPort, timeout, useDefaultCredentials, useAuthenticatedConnectionSharing, bindTo, 
listen, machineName, port, suppressChannelData, useIpAddress, , exclusiveAddressUse   
whereas in the constructor of the TCPChannel the initialized properties(and therefore 
supported properties are) : name, priority, bindTo, machineName, port, 
rejectRemoteRequests, suppressChannelData, useIpAddress, exclusiveAddressUse   so 
timeout is not supported in the case of  TCPChannel   To stree my point you might want 
to take a look at Ingo Rammer's Remoting UseCases 
Paper(http://www.ingorammer.com/RemotingFAQ/RemotingUseCases.html), he recommends that 
"For a LAN environment, HTTP+BinaryFormatter is recommended but not TCP".  In a 
subsequent discussion of the article 
(http://www.ingorammer.com/weblog/archives/001299.html )Ingo specifically mentions the 
non-availability a timeout property as a reason for this.        Chris Cavanagh   June 
12, 2003 02:36 PM     
Hi Ingo, 
For a LAN environment, why do you recommend HTTP+BinaryFormatter but not TCP? Is it to 
leave the option of hosting in IIS? 
Thanks! 
Chris    Ingo Rammer   June 13, 2003 01:31 PM     
Chris: Because TcpChannel lacks a "timeout" property. This can lead to problems in 
distributed applications when your server doesn't react as expected because - in this 
case - your clients would just hang. 
There's no such problem with the HttpChannel because it provides a configurable 
timeout value. 
-Ingo        However Check out another article by Ingo at 
(http://www.ingorammer.com/Software/OpenSourceRemoting/BiDirTcpChannel.html) where he 
discusses  .NET Remoting Bidirectional Tcp Channel.  In that he lists the timeout as a 
known issue for the demo code and talks of  handling it in a customized way(using a 
guid to identify every client uniquely, caching the results of a method call and if 
the same client issues a call for the same method within a specific time, then he 
serves it out of the cache.  This is my basic understanding as i have not gone thru 
the article fully and have only browsed it.  probably you could take a lead from 
there....)  Known issues          Needs support for automatic client reconnection 
include a server side timeout. Whenever the TCP connection drops due to network 
outages, the server should assign a grace period to the client. The server will in 
this case simply cache the event for some amount of time (like 10 seconds) and if the 
client reconnects during this time, no data is lost and no exception is thrown.        
It only works with IP addresses in the configuration file. It should however also 
support 
hostnames.      Performance: Too many new Threads. Will port to ThreadPool usage 
later.     regards,   sr

-----------------------------------------------------------

To stop getting this e-mail, or change how often it arrives, go to your E-mail 
Settings.
http://groups.msn.com/BDotNet/_emailsettings.msnw

Need help? If you've forgotten your password, please go to Passport Member Services.
http://groups.msn.com/_passportredir.msnw?ppmprop=help

For other questions or feedback, go to our Contact Us page.
http://groups.msn.com/contact

If you do not want to receive future e-mail from this MSN group, or if you received 
this message by mistake, please click the "Remove" link below. On the pre-addressed 
e-mail message that opens, simply click "Send". Your e-mail address will be deleted 
from this group's mailing list.
mailto:[EMAIL PROTECTED]

Reply via email to