[omniORB] bug report

[Stefan Seefeld]

"Gary D. Duzan" wrote:
> 
> In Message <3A14065B.E15AED91@magellan.umontreal.ca> ,
>    Stefan Seefeld <seefelds@MAGELLAN.UMontreal.CA> wrote:
> 
> =>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.

Right. The problem here seems that I write one application in a statically typed
language, which is pretty comforting, while the other side is scripted. This whole
location transparency now makes it appear as a single huge application, so it
clearly isn't statically typed any more (at least not in the original sense, which
implied that type errors are caught at compile time).

> 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

Right. We currently use a 'heart beat', i.e. a ping invoked in the server
to all client contexts. If that fails, we assume the client is dead, and release
all the client resources. Having a multi threaded environment really helps...

> 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

see above.

> prevent floods of client sessions from bringing down the system.

well, this isn't such a pain, at least not in the context of the berlin
server. It is the user who runs the server, and who invokes clients, or
at least, who can authorize clients to be run. All the authorization is
part of the initial construction of a ServerContext/ClientContext pair,
so arbitrary criteria can be used to determine whether a new client is
allowed to connect or not (and if so, what degree of trust you have into
it, i.e. which resources it can access...)

>    Good luck, and let us all know when you've solved all these
> problems. :-)

will do...;)

Regards,	Stefan
_______________________________________________________              
              
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: seefelds@magellan.umontreal.ca

_______________________________________________________

      ...ich hab' noch einen Koffer in Berlin...