ietf-openproxy
[Top] [All Lists]

Re: shuttle/CRC

2005-07-13 16:22:45

On Thu, 14 Jul 2005 at 00:10:57 +0200 jfcm mentioned:

 - I name CRC (common reference center) a clearing house for common 
 information to the members of a relation, community, etc.
 - I name "shuttle" the one shot transaction which ask the CRC one 
 information identified by its number, associated to a tag (ex. 
$list_name/1001)

It's called on RPC in the literature.

 - I name "spice box" (shuttled private information cache exchange) the 
 cache of the data received from the shuttled or processed from them. let 
 consider it is an opposite to the cookie (my secret knowledge of the 
 external world).

Like a DNS cache, like a proxy server for http, like any number of
other caches for various protocols?

 This means that when in a text the filter needs to replace $list_name by 
 its value, it will call the 1001 in the spice box which in turn will call 
 on the CRC.

Always, or only when the information is stale?

 I am interested in having the shuttle authenticated.

With respect to what?  The client authenticates the shuttle, the CRC
authenticates the shuttle?  Who authorizes shuttles?

 In most of the case the shuttle transaction will be one datagram. And be 
 used to also to carry a command/signal. So UDP seems adequate. But when the 
 transported information is longer, OCP could be of interest? 

Why not use TCP?

 Then obviously 
 this system is destined in interrelating (on my machine, under my control) 
 with the applications such as SMTP.

What's the architecture?  Does your SMTP server call on the CRC to get
extra information?  Does your SMTP client call on the CRC?  

 Obviously the information of the CRC is more static than in OPES (call-out 
 servers can be quite dynamic). 

We hope not.

But CRC will use IPv6 access grids. This 
 means that each information will be related to a number which is an 
 InterfaceID. So one can call many CRCs to get/prioritised environment 
 (something OPES could also do).

Sounds horrible.  Surly you don't want to tie application information to
InterfaceIDs?  Are you talking about using Anycast to collection of
CRC replicas?

If your primary question is, could OPES be used to implement a caching
service for a nearly stateless RPC protocol, I'd say not really.  OPES
would be relevant if you already had such a service and wanted to
provide added value to it with callout servers.

Or, suppose you were using OPES for SMTP enhancements already, and you
wanted to add CRC information.  We had already decided that in such
cases, the callout server would be responsible for retrieving CRC info,
and it would cache it if needed.

I don't see any reason that the same machine that runs OPES couldn't
also run a caching proxy for CRC, though.  

Hilarie


<Prev in Thread] Current Thread [Next in Thread>