|
|
You're in the
dotnet remoting
group:Consuming A Remoting Server
dotnet remoting:
In my code, I consume a remoting server with: RemotingConfiguration.Configure("ChatClient.exe.config"); // Create a proxy to the remote object. ChatCenter chatcenter = new ChatCenter(); // Create a remotely delegatable object MyCallbackClass callback = new MyCallbackClass (_alias) ; In another examle I see: HttpChannel channel = new HttpChannel(); ChannelServices.RegisterChannel(channel); ICustomerManager mgr = (ICustomerManager) Activator.GetObject( typeof(ICustomerManager), "http://localhost:1234/CustomerManager.soap"); Console.WriteLine("Client.Main(): Reference to CustomerManager acquired"); Customer cust = mgr.GetCustomer(4711);
[quoted text, click to view]
peter wrote: > Hi John, > > The first allows you to use config files, and the 'new' operator. The > second will work for interfaces and abstract base classes (neither of > which can be instantiated using new). > > I always use the first method unless there really is no alternative. It > allows me to use text files for configuration, which is a huge advantage > (IMHO) Thanks Peter. I am using the config file as well -- it seems far more flexible so I agree -- I am just wondering if the code method provides any additional configurability such as reconnect/retry attempts, or if I would have to write that code myself regardless of what method I use... [quoted text, click to view] > > Peter > > jabailo@texeme.com wrote: >> >> In my code, I consume a remoting server with: >> >> RemotingConfiguration.Configure("ChatClient.exe.config"); >> >> // Create a proxy to the remote object. >> ChatCenter chatcenter = new ChatCenter(); >> >> // Create a remotely delegatable object >> MyCallbackClass callback = new MyCallbackClass (_alias) ; >> >> >> In another examle I see: >> >> HttpChannel channel = new HttpChannel(); >> ChannelServices.RegisterChannel(channel); >> >> ICustomerManager mgr = (ICustomerManager) Activator.GetObject( >> typeof(ICustomerManager), >> "http://localhost:1234/CustomerManager.soap"); >> >> Console.WriteLine("Client.Main(): Reference to CustomerManager >> acquired"); >> >> Customer cust = mgr.GetCustomer(4711); >> >> What is the difference between these two methods? -- Texeme Textcasting Technology
Hi John,
The first allows you to use config files, and the 'new' operator. The second will work for interfaces and abstract base classes (neither of which can be instantiated using new). I always use the first method unless there really is no alternative. It allows me to use text files for configuration, which is a huge advantage (IMHO) Peter [quoted text, click to view] jabailo@texeme.com wrote:
> > In my code, I consume a remoting server with: > > RemotingConfiguration.Configure("ChatClient.exe.config"); > > // Create a proxy to the remote object. > ChatCenter chatcenter = new ChatCenter(); > > // Create a remotely delegatable object > MyCallbackClass callback = new MyCallbackClass (_alias) ; > > > In another examle I see: > > HttpChannel channel = new HttpChannel(); > ChannelServices.RegisterChannel(channel); > > ICustomerManager mgr = (ICustomerManager) Activator.GetObject( > typeof(ICustomerManager), > "http://localhost:1234/CustomerManager.soap"); > > Console.WriteLine("Client.Main(): Reference to CustomerManager acquired"); > > Customer cust = mgr.GetCustomer(4711); >
[quoted text, click to view]
jabailo@texeme.com wrote: > > Thanks Peter. I am using the config file as well -- it seems far more > flexible so I agree -- I am just wondering if the code method provides any > additional configurability such as reconnect/retry attempts, or if I would > have to write that code myself regardless of what method I use... > Hi John, I think you've had a far better answer to your connection(less) question than I could ever give you, so I'll concentrate on this one - which seems to be at the root of your problem. I'm not sure I entirely understand what you're getting at, but let's try for an answer anyway. If you try to connect to a server that is not responding, you will get an Exception back saying that the server is, "Actively refusing connections". You could trap that, I suppose. However, I'm surprised that you have such an unreliable connection. It is possible, I guess, that a service could fail to start after a server reboot, for example - but where I work, at least, we always check for that sort of thing after every reboot. If you were really concerned about outages in mission-critical situations you would presumably have failover strategies and the like such that a request would be diverted to a different server. Of course if your servers are not exact replicas of each other, then you might lose some state. I always make sure that my applications check the consistency of their internal states at every significant move - and send messages back to users about how to recover if there's a problem. But mainly I try very hard to keep things stateless. I only use CAOs when I absolutely must - which is once, so far. Why do you consider it a problem worth worrying about, John? Do you have a specific scenario in mind? Cheers
Peter, THat is good information so far. This is more of a 'workgroup' multiuser type application. It's not real-time, but as far the user experience goes, I want them to be able to connect to the remoting server with a high degree of reliability. And, if say, our network ( which is flimsy ) caused a 'burp' while something was being sent or received, there would be a way to recover in the client. [quoted text, click to view] peter wrote: > jabailo@texeme.com wrote: > >> >> Thanks Peter. I am using the config file as well -- it seems far more >> flexible so I agree -- I am just wondering if the code method provides >> any additional configurability such as reconnect/retry attempts, or if I >> would have to write that code myself regardless of what method I use... >> > > Hi John, > > I think you've had a far better answer to your connection(less) question > than I could ever give you, so I'll concentrate on this one - which > seems to be at the root of your problem. > > I'm not sure I entirely understand what you're getting at, but let's try > for an answer anyway. > > If you try to connect to a server that is not responding, you will get > an Exception back saying that the server is, "Actively refusing > connections". You could trap that, I suppose. However, I'm surprised > that you have such an unreliable connection. It is possible, I guess, > that a service could fail to start after a server reboot, for example - > but where I work, at least, we always check for that sort of thing after > every reboot. > > If you were really concerned about outages in mission-critical > situations you would presumably have failover strategies and the like > such that a request would be diverted to a different server. Of course > if your servers are not exact replicas of each other, then you might > lose some state. I always make sure that my applications check the > consistency of their internal states at every significant move - and > send messages back to users about how to recover if there's a problem. > But mainly I try very hard to keep things stateless. I only use CAOs > when I absolutely must - which is once, so far. > > Why do you consider it a problem worth worrying about, John? Do you > have a specific scenario in mind? > > Cheers > > Peter -- Texeme Textcasting Technology
[quoted text, click to view]
jabailo@texeme.com wrote: > Peter, > > THat is good information so far. > > This is more of a 'workgroup' multiuser type application. > > It's not real-time, but as far the user experience goes, I want them to be > able to connect to the remoting server with a high degree of reliability. > > And, if say, our network ( which is flimsy ) caused a 'burp' while something > was being sent or received, there would be a way to recover in the client. > OK. I'm on unfamiliar ground here, so treat what I say with some suspicion - and hope that someone with more knowledge comes up with some better suggestions. The first thing to do is to check whether you can trap the Exception thrown when the server fails to respond. Make sure your client code is in a try/catch block, set a debugger breakpoint on the first call to the remote object (not the 'new' operation as that just calls the proxy), stop the server and then try to make the remote call, which will obviously fail because the server is not listening. Hopefully you'll end up on the catch part of the try/catch block. Try that first. If the Exception can be caught, and I'd be surprised if it couldn't, the next step might be to find out exactly what type(s) of Exception(s) get generated so that it/they can be caught specifically and not just with the generic Exception type. Then you can do whatever your program requires - e.g. show an error message and ask the user to try again, or resend, or whatever. HTH
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |