On Fri, 2006-01-06 at 15:00, Eitan Zahavi wrote: > I agree with Todd: a key is to keep the client unaware of the mux existence. > So the same client can be run on system without the cache.
Define same client ? I would consider it the same SA client directing requests differently based on how the mux is configured based on a query to the cache (if it exists) as to its capabilities. -- Hal > Hal Rosenstock wrote: > > On Fri, 2006-01-06 at 09:05, Rimmer, Todd wrote: > > > >>>From: Hal Rosenstock [mailto:[EMAIL PROTECTED] > >>>On Thu, 2006-01-05 at 18:36, Rimmer, Todd wrote: > >>> > >>>>This of course implies the "SA Mux" must analyze more than just > >>>>the attribute ID to determine if the replica can handle the query. > >>>>But the memory savings is well worth the extra level of filtering. > >>> > >>>If the SA cache does this, it seems it would be pretty simple > >>>to return > >>>this info in an attribute to the client so the client would > >>>know when to > >>>go to the cache/replica and when to go direct to the SA in the case > >>>where only certain queries are supported. Wouldn't this be > >>>advantageous > >>>when the replica doesn't support all queries ? > >> > >>Why put the burden on the application. give the query to the Mux. > > > > > > That's what I'm suggesting. Rather than a binary switch mux, a more > > granular one which determines how to route the outgoing SA request. > > > > > >> With an optional flag indicating a prefered "routing" (choices of: to SA, > >>to replica, let Mux decide). Then let it decide. As you suggest it may > >>be simplest to let the Mux try the replica and on failure fallback > >>to the SA transparent to the app (sort of the way SDP intercepts > >>socket ops and falls back to TCP/IP when SDP isn't appropriate). > > > > > > It depends on whether the replica/cache forwards unsupported requests on > > or responds with not supported back to the client as to how this is > > handled. Sean was proposing the forward on model and a binary switch at > > the client. I think this is more granular and can be mux'd only with the > > knowledge of what a replica/cache supports (not sure about dealing with > > different replica/caches supporting a different set of queries; need to > > think more on how the caches are located, etc.). You are mentioning a > > third model here. > > > > -- Hal > > > > _______________________________________________ > > openib-general mailing list > > [email protected] > > http://openib.org/mailman/listinfo/openib-general > > > > To unsubscribe, please visit > > http://openib.org/mailman/listinfo/openib-general > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
