Hi Artmanaged,
Thanks for your posting.
As for the problem you mentioned, here are some of my suggestions:
Yes, the .net remoting has provide the intefaces for us to hook into the
channel sinks on both serverside or clientside to do some custom
processing. Here is a certain tech article discusing on such topic:
#Secure Your .NET Remoting Traffic by Writing an Asymmetric Encryption
Channel Sink
http://msdn.microsoft.com/msdnmag/is...g/default.aspx
But as my opinion, the when processing the exception occcurs at serverside,
we'll have to provide our customized clientside sink and try getting the
exception from the Message Object and try reidirect to another server. This
is a possible approach, but there'll have some particular conditions such
as when the certain server is unavailable, then maybe no such a exception
can be found in the returned message.
My suggestion is that we encapsulate the remoting object's calling at
client side. For example, we use a certain class to expose the methods that
call the remote object and in the methods, we can use
try....catch blocks to hold on any possible exceptions(clientside or
serverside) in the methods. Then, if on error, we can try request the
remote object from another remote server(querying the existing remote
server list from config file or from a remote service). And we can also put
all the available servers list in the clientsdie app's application config
file which can also be updated when there is a new remote server availabe.
Just some of my suggestions. If you have any other ideas , please feel free
to post here. Thanks.
Regards,
Steven Cheng
Microsoft Online Support
Get Secure!
www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)