Re: A comment about changing kernels

[Jonathan S. Shapiro]

On Sat, 2005-10-29 at 09:54 +0200, Bernhard Kauer wrote:
> On Fri, Oct 28, 2005 at 04:41:08PM -0400, Jonathan S. Shapiro wrote:
> > > Session based mean, that I open a session to a server, send my return 
> > > endpoint
> > > to it, get perhaps another session-capability from the server and use this
> > > capbility to talk to the server. The server can answer my calls through my
> > > initially send return endpoint.
> > 
> > Three questions for Bernhard:
> > 
> > 1. Who pays for the storage for all of these endpoint capabilities that
> >    the server must retain?
> 
> Think of a server who offers session based protocols: for example a network 
> stack.
> A TCP/IP network server has to hold TCP connections, receive and send buffers.
> In this situation accounting the resources to the client is needed, if denial 
> of
> service should be avoided. Therefore, let the client pay for the storage the
> server need to keep the return endpoint.

I understand that there are servers that must operate this way. These
servers are extremely difficult to build, and they must manage their
storage with tremendous care.

My problem with your proposal that a server must hold many endpoint
capabilities is that it has the effect of insisting that *all* servers
undertake this error-prone and complex management task.

> > 2. If the client dies, how does the server learn that the session is
> >    terminated and the server's endpoint capability for that client can
> >    be dropped?
> 
> In the network server example: if a connection timeouts. Otherwise the parent,
> who deletes the client, has to reclaim the memory  or notify the server.

So the party who deletes the client must have complete understanding of
the actions of the client? Doesn't this violate encapsulation?

> > 3. Consider a server that has multiple clients, each with a session.
> >    One of these clients invokes the server. How does the server know
> >    which client it is supposed to respond to?
> 
> We use the badge for this.

Bernhardt: I believe that *I* know what you mean, but it would be useful
to explain this a little more to the rest of the list.

In any case, the badge is insufficient. Two clients can hold the same
capability (including the same badge) and the server must be able to
know which one it is replying to in this case.

How does this work?


shap