Re: A comment about changing kernels

[Bernhard Kauer]

On Sat, Oct 29, 2005 at 11:42:28AM -0400, Jonathan S. Shapiro wrote:
> > > 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.

If the performance of a session-based protocol is not needed than build
easier but slower session-less server. If they are a map() slower for every
operation, they should not care whether a copy() takes an IPC more.


> > > 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?

If the party who gives the resources to the client want them back, it needs
to get a notify of the dead. And if this party can or will not force other
servers, for example the network server, to release the buffers, it has to
notify them to release the memory.


> > > 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.
>
> 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.

The badge is a session identifier for the server, comparable with an IP address
or better a MAC address in a network. If a client gives his badge directly to
another party, it allows to act on behalf the client. I do not know whether this
is needed, but optional sending a return endpoint should solve it.


    Bernhard