My assumptions are based on the use of either TCP or UDP transport protocols.
For UDP, the broadcasting is not reliable, hence cache items will gradually get out-of-syn. For TCP, a peer-to-peer broadcasting model means n(n+1) TCP connections among the n nodes, versus 2(n-1) in the case of using RCS. Hence it's just too expensive. The catch-22 of either being too expensive or too unreliable leads me to my (potentially incomplete) conclusion. Hanson > -----Original Message----- > From: James Taylor [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 09, 2002 11:08 AM > To: Turbine JCS Users List > Cc: 'Mar�y �kos' > Subject: RE: newbie question on remote caching > > > > > Another question: do I undestand correctly that the lateral > > > cache lacks > > > the invalidate-message sending of the centralized remote cache? > > > > My impression is the idea of lateral cache is fundamentally > flawed. So I > > just igore it. > > Can you back that up? > > I like the lateral cache, it makes a lot of sense to me -- especially > built on top of a reliable multicast messaging system. > > All peers share elements as they are added to / removed from > the cache. > For more consistency, a member can broadcast a get request to > its peers > just in case it never received the broadcast (if it was rebooted > perhaps). > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> >
