Subject: CAP TODO: single threaded

From: Doug Royer <[email-masked]>
Date: Fri, 09 Nov 2001 12:40:23 -0700

> - Problems with a single threaded server?
> If yes, then will need to change some things.
> See post "CAP: Bounded latency"

(1) What do you mean by 'single threaded'? Do you mean OS threads?
    If so - I don't know of any issues.

(2) If you mean overlapped requests - as in ask for one item,
    then before it replies, ask for another? And the replies
    can come out of order?

     This was a debate with another name a couple of years ago.

     (a) Given the connection is TCP.

     (b) If the CUA DOES support overlapped requests, and the
         CS DOES NOT support overlapped requests:

         The CS that does not support multiple overlapped requests
         simply does not have to read the pipe until it has sent
         the reply to the pending request.
         
         Any CUA that had hopped for (and sent) overlapped requests
         will simply see the replies in the same order as requested.

         (b.1) If the CS does read multiple requests, but does
               not support out of order replies - then it sends
               the replies in order. And the CUA sees them in order.
	 
     (c) If a CUA DOES NOT support overlapped requests - it
         will not send them and the CS will process any requests
         in order. If the CUA DOES NOT support overlapped requests
         it MUST NOT send more than one without waiting for the CS
         to reply and it will never get out of order replies. If the
         CUA did send multiple - then it is telling the CS it supports
         multiple.

     (d) If both the CUA and the CS support overlapped requests:
         The request and replies are tagged with the TARGET and CMDID.
	 So:

         If the multiple requests are to the SAME TARGET, the
         CS MUST process those to the same TARGET in order.

         For all requests that have unique TARGETS, process them
	 in any order and reply to them in any order. If the CUA
         can not handle that, it would not have sent that.

As far as the bounded latency time issues:

     (e) Bound latency is independent of overlapped requests.

     (f) If you ask for bounded requests - you better be able to
         handle them.

     (g) If you ask for overlapped requests with bound latency,
         then you better be able to handle them.

Each command has a CMDID to identify the replies for
overlapped requests.

Each bound latency request was initiated by the CUA.

The CUA MUST NOT send a request where it can not support the
reply for any such request.

I don't think that any of this is unique to CAP, it would be
true if any wire protocol. But perhaps if it is confusing we
should add these instructions to implementors?

-Doug

---

From: [email-masked]
Date: Thu, 15 Nov 2001 12:13:15 -0500

John replied:
>                                    because the APIs used 
>to access the backend database are typically blocking calls.

That all depends on what your CS uses for a back end store/API.   I know 
of at least 1 API that is built so that calls can be done async for some 
stuff..  :^b

Sorry, couldnt resist that one while playing 'resync my archives'...

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...