[omniORB] bug report

[Gary D. Duzan]

In Message <3A14065B.E15AED91@magellan.umontreal.ca> ,
   Stefan Seefeld <seefelds@MAGELLAN.UMontreal.CA> wrote:

=>I'm sorry, I should have thought more before posting. My reasoning was
=>that I couldn't imagine that I have to be prepared on every (potentially remote)
=>request which involves parameters for that kind of errors. I'm trying to write a 
=>server which is stable even in the face of buggy (or malicious) clients. 
=>I would have thought that attempts of the client to communicate 'bad parameters' 
=>to the server are cought by the ORB, insulating the server's implementation
=>code completely from such stuff !
=>
=>However, as I understand now the problem for return values is conceptual.
=>Even if the client would issue an exception to the server returning a
=>'bad response', it has to continue somehow, i.e. it can't wait in an endless
=>loop until the server decides to return a correct result.
=>
=>Anyway, this now opens up a whole new can of worms, as I have to think about
=>how to react in this kind of situations...

   Right. Basically, location transparency is a double-edged sword.
You get to write your code as if it is a local call, but it really
isn't, and the implications of that fact have to appear somewhere.
Dealing with them leads you back to having to deal with the issues
involved with remote calls, though differently, so basically you
come full circle.
   For CORBA, in particular, catching and dealing with SystemExceptions
in general should be a matter of course for the client, since almost
anything can raise them. If you want to bulletproof things, you
should also worry about having unbounded delays executing callback
methods. OmniORB has a flag to terminate long-running remote calls
after a timeout period, but you have to use it with care in case
there are other calls that you are making that may legitimately
take a long time. I believe that CORBA Messaging will provide finer
control over timeouts, but it will be a while before you see
implementations of it and using it exposes the remote execution
even more. As for dealing with truly malicious clients, that could be
tough unless you have some way to bound per-client server resource
use. You may also want to bound the number of active clients to
prevent floods of client sessions from bringing down the system.
   Good luck, and let us all know when you've solved all these
problems. :-)

					Gary Duzan
					Verizon Laboratories