On 7-Sep-09, at 11:44 AM, Raphael Manfredi wrote:
Your patch ties the ban logic to the Foxy servent name. This is probably not what we want: I'd prefer something that looks for the authentication headerin the handshake, regardless of the servent name.
More like this? It wasn't as difficult as I thought, once I got used to the functions. I've been thinking more, and in my opinion this is still kinda kludgy, because the simplest behavior for a good open/closed dual servent would probably be to try to authenticate first, and then act as a portal servent upon failure. And there might well be legitimate reasons to forms sub-networks like that, especially with GWebcache or hub organized servents. However, here's the patch for your consideration; its better than nothing in the current network environment.
patch -p0 <Foxy.patch - Matt
Foxy.patch
Description: Binary data
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
