Date: Thu, 13 Feb 2003 07:14:22 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Brad Knowles <brad.knowles@skynet.be> Cc: Rahul Siddharthan <rsidd@online.fr>, freebsd-chat@freebsd.org Subject: Re: Email push and pull (was Re: matthew dillon) Message-ID: <3E4BB64E.A9AEED28@mindspring.com> References: <20030211032932.GA1253@papagena.rockefeller.edu> <a05200f2bba6e8fc03a0f@[10.0.1.2]> <3E498175.295FC389@mindspring.com> <a05200f38ba6f51f20eff@[10.0.1.2]> <3E49C434.D8D497EE@mindspring.com> <a05200f44ba6fe5dff1a0@[10.0.1.2]> <3E4A83BC.8A15E7C3@mindspring.com> <a05200f4fba70847460b3@[10.0.1.2]> <3E4B12F5.2608BBB@mindspring.com> <a05200f5cba7146e25655@[10.0.1.2]>
next in thread | previous in thread | raw e-mail | index | archive | help
Brad Knowles wrote: > At 7:37 PM -0800 2003/02/12, Terry Lambert wrote: > >> This problem is already solved -- check out Perdition. > > > > The problem is *not* solved by Perdition. Perdition does not even > > *begin* to solve the problem. > > Okay, what parts of the problem doesn't Perdition solve? Replication and failover. Perdition provides distributed load balancing. The bck end stores that the Perdition proxy accesses have to have the content locally available. Even if you are able to load-balance, you are only able to do so between back-end servers that contain the actual content in question. The result is that you provide a unified view onto a backend farm, but you lack replication and failover in the back-end, and it does not magically appear, merely because you are running Perdition. There are other POP3 and IMAP4 proxies that can do the same things Perdition can: it's no big deal. In fact, it doesn't deal with LDAP, which is probably where the routing to the back end store will occur. > >> You can do this today. Send an e-mail and tell people to go read > >> a specific USENET news message. Doesn't work too well. > > > > Doesn't address any privacy issues. Even encrypted, your data is > > out there for anyone to perform traffic analysis upon. > > I don't see how you can do a flood-fill mechanism without having > the message accessible to anyone who'd want to read it. Of course, > it should be public-key encrypted, so that the only traffic analysis > that could be performed was the path that it took over the flood-fill > servers, which could be obscured. The primary use of such a thing is statistical client location anonymity. Basically, it's useful for terrorists and other covert communications networks (e.g. "Blacknets"), but not for a lot else, unless you put more effort into it. Insertion points are always known. Basically, it's only useful as a replication technology, and then, only behind the scenes at a particular provider, as part of their provider network. You could address these issues, but since Kazaa and GNUtella have failed to address the scaling issues when they tried to address the same issues, it's a complex enough problem that it's probably not going to be solved by Open Source. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E4BB64E.A9AEED28>