Re: Keep-Alive Notes

On Wed, 18 Oct 1995, Shel Kaphan wrote:

>  > 
> The question that occurs to me is whether this is worth the additional
> complexity in terms of bandwidth savings.  I can't see any reason
> other than bandwidth savings in the chain of requests that such a
> construct would be wanted. (Is there one?).  If this is right, then it
> seems unlikely to produce enough savings to be worth the trouble.
> This seems especially true if proxies are going to be multiplexing
> requests from multiple clients onto a single connection to an 
> "upstream" server. It's certainly possible to make this work, but does it
> buy enough to be worth the trouble?

I'll describe the HTTP-NG approach to the issue of header caching as used 
in  1.0->NG->1.0 relay mode. 

Each  request takes place in a Context; a context is a bunch of state 
associated with a set of requests. When a client proxy relays a 1.0 
request, it can set a boolean indicating whether headers should be 
reused or not. If headers are reused, then any request headers sent with 
this request are merged with those used for the previous request; if a 
header is not sent, then its value is reused as is; if they are sent then 
the value is replaced. 

A typical client might use two contexts; one for base pages, another for 
renderable inlines. 

The savings can be quite useful, especially if some sort of application 
nagle like algorithm is used to merge short requests into a single 
packet; an entire pages worth of cache checks can fit into a single 
packet. The effect becomes even more pronounced when native NG requests 
are used.


(defun modexpt (x y n)  "computes (x^y) mod n"
  (cond ((= y 0) 1) 
	((= y 1) (mod x n))
	((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n))
	(t (mod (* x (modexpt x (1- y) n)) n))))

Received on Wednesday, 18 October 1995 10:23:36 UTC