Re: handling dead clients/servers, suggestions?

[Brian Craft <bcboy thecraftstudio com>]

Anyone have any suggestions about how to implement this usage pattern?

o Clients can request a resource be created server-side. The resource has
  to be server-side because the server needs it. Sorta like an X client
  creating some graphic object in an X server. Also, implementing client-side
  resources would defeat the advantage of using corba (I'd have to
  reimplement for every language binding).

o These resources can't just disappear through an Evictor pattern. The client
  may run an arbitrary length of time (i.e. as long as the desktop machine is
  running), and so may sleep for days or months. When it wakes up in three
  months, the server needs still have the resources defined.

o The server can't just leak these resources, since a client may generate many 
  of them, and may generate them dynamically based on events.

Using any other client/server mechanism you just free resources when a client
dies.

With corba there seem to be two problems:

  o Associating allocated resources with a particular client. If you just 
    implement a factory method, it appears you have no way of knowing which
    client requested which object. Is this correct? So then you need some 
    kludge, like an empty factory method just to generate an id, which the 
    client then passes in to the real factory method, so the server can 
    associate objects with some id representing the client. But then the
    server is relying on the client to be "nice", so it's not much better
    than requiring explicit destroy by the client.
   
  o Figuring out when a client dies, so you can clean up the resources they
    were using.

I was looking through the panel code. It appears to detect when clients die,
but perhaps via X, instead of corba. Anyone know if this is the case?

It seems odd that corba would require you to trust that clients are properly
coded, or spew memory like a fire hose. There must (I hope) be some way to make
robust servers.

b.c.