> Quoting Bill Pringlemeir <[EMAIL PROTECTED]> from >> "http://ghostwhitecrab.com/crab/doc/specs/gwc_v3_draft.txt";
On 18 Sep 2005, [EMAIL PROTECTED] wrote: > You know, the more I think about it, the more I'm convinced that > HTTP is not the proper protocol for GWCs. It makes hacking too > easy, because there's so much tools that handle HTTP... > Don't misunderstand me: I really love HTTP, I know it well enough. > But it has an intrinsic overhead that I think is too large for GWCs. Ok, I didn't find too much on UHC. However, it seems to be a lot better than GWC because regular nodes on the network are used afaiu? So, I would propose a server that only handles "ip", "refer" and "vote". I am using the "ip" like the GWC concept. The mechanism could work like this, Client A connects to bootstrap server and supplies it's IP and port. A secret key (Sa) is sent to the client A. Client B connects to the bootstrap server. IP and port are sent and key (Sb) is generated. Client B is refered to client A with a token. The token is some text encrypted with (Sa). Client B connects to Client A and requests host cache info providing the token. Client A verifies that Client B has been referred by the server and supplies servent information. Client B returns a "vote" to the server. This allows the server to verify that client B has communicated with client A. The bootstrap server must keep track of clients returning an excess of no votes and possibly revoke them. The server can priorities the clients based on time, number of votes and round robin type scheduling. Most of the bandwidth would be off loaded from the server as the clients would be communicating host cache information to each other. The only reason to use secret keys is to prevent abuse of the protocol. The keys don't have to be unique per client. The could be generated by some dynamic hashing of ip, etc... as long as the pool is large enough. The server can store a unique secret key with each IP address as well. The token should contain information about client B and the referring bootstrap server. Client's might have several keys for each bootstrap server they have contacted. Many bad requests from a server could allow a client to ban tokens from that server. In this case the bootstrap server is only a pointer to host caches instead of the source of the host caches. The clients would have to be non-proxied to communicate their servent cache to other clients. I think that is a mix of GWC and UHC with a little encryption thrown in to prevent abuse. Ie, it is difficult to get a list of all servents in the network. Instead of GCEP to communicate UDP host cache capability, a vote mechanism is used. fwiw, Bill Pringlemeir. ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Gtk-gnutella-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
