Re: ideas

Adrian Chadd wrote:

> Hmm. How would the feedback and 'mirroring' occur? I thought about your
> proposal and I decided to extend it a little to my proposal since all
> the flexibility is there without having to hack in weird methods of
> communiation between the connection manager and the storage manager.

With a handful of simple operations, similar to what we have in the
storage API, but cntered around the requested object and not an abstract
filenumber (which is a storage manager internal thingy).

The exact details of the communication protocol between the different
remains to be defined. If everything was already fixed then there would
be no point in having these discussions would it?

How do you picture the data actually ending up in the storage if
everything only have two ends and the request is not going via the
storage manager?

> Ok. You're talking about seperate processes here, right? I'm talking
> about having it all as one process with a single comm/callback thread
> per CPU. I guess if designed right the modules could support either
> IPC or callback notification depending upon your orientation, but
> my motivation for keeping it all in one process as much as possible
> stems from my desire to have this compile relatively cleanly under
> DOS at some stage.

Right, but it might also be implemented using separate threads in one
process. Does not matter much for the interface designs (only the
"IPC"/"RPC" mechanism is different..), but it matters a lot for
reliability in case of software errors which there will always be some
errors. I cannot make 100% faultfree code, and I am pretty sure neither
can you. I can however try to build a software system which can handle
common faults in a reasonable manner without servere impact on the
function, and I do beleive it can be done without a too large impact on
overall performance.

> Connection 'sharing' ? DO you mean server to multiple client connections
> simultaneously? Hmm. I didn't want to support that. I wanted there to be
> persistent connections but server->multiclient IMHO should be handled
> by the storage manager. A client-speaking clientlet and server-speaking
> servlet should only have two ends - the request end and the socket end.
> The storage manager should handle multiple clients and multiple srvers
> (revalidation). That said, something like request pipelining could be
> a fun thing, where a clientlet can support multiple servlet connections
> but only lets one transfer data at a time..

Yes, I mean one single server connection being split and sent to several
clients.

Yes, it might be handled via the storage manager, but then there is a
couple of ugly situations which will occur:
a) The first client who is driving the retreival aborts the request
while there are other clients going thru the storage manager.
b) The first client is slow or throttled, and the request gets network
bound sending data towards that client. The next client has a faster
connection.

I would not like to have a situation where the storage manager has to
tell the connection manager that "sorry, there are other clients who are
more important. Your client has to 'downgrade' to a storage manager
client, and the storage manager will now be the primary client for this
request". Such decisions are best handled by the connection manager I
think if the request forwarding centers around the request and not a
store entry.

And yes, it can be argued if this is at all needed.

Hmm.. thinking some more about it. Yes it is most likely best handled by
the storage manager. We also have the "not quick_abort" case where
clients can rejoind a already started retreival, and this should be
handled in a generic manner where new clients joining a already started
retreival and the first client aborting and then continuing the
retreival are handled similary.

Yes it means there will be two possible request flows if the default
mode is to not go via the storage manager.

/Henrik
Received on Mon Jun 12 2000 - 03:57:59 MDT