Hi, I suppose that the problem of huge transfers is using of per-request authentication instead of per-connection. The widely used mod_auth_sspi uses per-request auth that leads to resending of 3-phase SSPI auth information. I tried to jump from per-request to per-connection by patching mod_auth_sspi module and found it working ok. I'm still investigation the real reason and looking for solution. My team is really interested in fine SSPI/NTLM authorization.
Serge Gotvansky -----Original Message----- From: Stefan Kung [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 11, 2006 9:17 PM To: [EMAIL PROTECTED]; [email protected] Subject: excessive data transfer with SSPI Hi, With my latest patch to the SSPI feature in neon, the authentication now works, whether the user is part of a domain or not. But there's one more problem we (TSVN users) discovered with it: adding or checking out big compressed files leads to excessive data transfers. Some examples: 14.585MB wmv file added with SSPI authentication ==> data transferred: 278.362MB! The same file added (and committed) with basic authentication only transferred 12.88MB data! (a wmv file was used because they're highly compressed, so the zlib compression on the wire wouldn't change the results that much). So you can see, the overhead for authenticating with SSPI is unacceptable high. This overhead slows down Subversion clients a lot. This is easily reproduced: * Subversion client >= 1.3.0, built with neon >= 0.25.1 * connecting to an apache server with the mod_auth_sspi module installed * repository configured to authenticate with a windows domain * client machine is part of that domain $ svn add verybigfile $ svn ci -m "" catch the traffic with e.g. ethereal (or with TSVN, which uses the neon callbacks to sum up all the transferred data) I've spent the last four hours trying to find out where (Subversion/neon, and where exactly in the source) this happens, but all I can see is that neon reauthenticates for every packet sent. I can't see where the authentication is cached (or in this case *not* cached) and where it should be cached. So I'm lost and have to give up on this. I really hope that one of you guys can jump in here and fix this issue. Because it's not just TSVN which suffers from this, the Subversion CL client does too, and so will all other Subversion clients. Since I'm not sure where this must be fixed, I'm posting this to both the Subversion and the neon list. Stefan -- ___ oo // \\ "De Chelonian Mobile" (_,\/ \_/ \ TortoiseSVN \ \_/_\_/> The coolest Interface to (Sub)Version Control /_/ \_\ http://tortoisesvn.tigris.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _______________________________________________ neon mailing list [email protected] http://mailman.webdav.org/mailman/listinfo/neon
