Re: Persistent connections: aborting requests in progress.

Paul and I alternate (excerpts only):

    ]     a. Send request
    ]     b. Receive first buffer(s) of response; enough to see that no further
    ]     negotiation (e.g., authentication) or other packet exchanges are
    ]     required for this request.
    ]     c. Send next request (perhaps based on the contents of the immediatelty
    ]     or some other previous response)
    ]
    ] we skipped step (b).
    
    One can skip step b) if one can tell in advance that it won't be 
    required, or that failure to wait when one should have can be recovered 
    from safely.  I take your "presumably" to mean that most of the time 
    everything falls out because initial requests aren't typically 
    pipelinable -- but I wouldn't want to depend on being able to omit step 
    b) in all cases.

An observation: the same potential problem arises for the "fire off N
parallel connections at once" approach, right?  That is, any form of
pipelining suffers from the possibility of a fault.  CPU designers
know this; their pipelines know how to "squash" instructions in progress,
restart them, insert bubbles, do "imprecise exceptions", etc.

I suspect that in most cases, the worst thing that can happen is that
one or more retrieval requests result in "soft" (retryable) error returns,
in which case the client knows what to do.  The only time this could be
a real problem is if certain requests must be executed in a particular
order, in which case pipelining is not advised.  (In modern RISC machines,
the solution is to insert "trap barriers" to force synchronization.)

    So, in order to make things robust, we'd either need to document some 
    restrictions that make skipping b) always safe, or know in advance when 
    it is safe to skip and handle the unsafe cases by waiting to complete 
    the negotiation, or figuring out how to recover if the server gets a 
    GET in response to a request to negotiate something -- maybe just 
    draining the pipe until the client's request-aheads are all gone and 
    the correct response to the negotiation arrives would work, and perform 
    well if it doesn't happen very often.

I think your last suggestion best fits the CPU-pipeline analogy.

-Jeff

Received on Monday, 25 September 1995 10:30:17 UTC