A quick thought. I was working with the Javagroups folks when I made the auxiliary. They were making some changes that would improve performance and callbacks for JCS. I never implemented the new methods. I'll go through their email archive to see.
Aaron > -----Original Message----- > From: James Taylor [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 09, 2002 11:26 AM > To: 'Turbine JCS Users List' > Subject: RE: newbie question on remote caching > > On Fri, 2002-08-09 at 11:22, Hanson Char wrote: > > 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. > > Ahhh, okay. I agree with both conclusions actually, but building on top > of javagroups addresses these concerns I believe. By using multicast UDP > we can eliminate the n(n+1) issue. Then, by implementing a reliable > retransmit protocol on top of that (which javagroups does already) we > get reliability. > > It's a really clean solution IMHO. Javagroups provide so much. It can be > configured to simulate multicast with unicast if required, or to > traverse firewalls, or any number of other things... > > I'm still testing, but I'm planning on moving to it from the TCP lateral > soon. > > > -- > To unsubscribe, e-mail: <mailto:turbine-jcs-user- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:turbine-jcs-user- > [EMAIL PROTECTED]>
