You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Küng <to...@gmail.com> on 2006/01/11 19:16:52 UTC
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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [neon] excessive data transfer with SSPI
Posted by Stefan Küng <to...@gmail.com>.
Joe Orton wrote:
> Hi Stefan,
>
> On Wed, Jan 11, 2006 at 08:16:52PM +0100, Stefan Küng wrote:
>> 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!
>
> Can you capture neon debug logs or ethereal traces and make them
> available to me? (preferably with a small file being committed to
> illustrate the problem)
I first have to rebuild everything again with those debug logs enabled.
But not today anymore, it's getting late here...
> If the server requires authentication only for PUT requests, then it
> might be expected that some of the request bodies have to be resent
> after authentication, when checking in. I can't think why checking
> *out* would lead to problems of the same magnitude, though.
>
> Trying to do GSSAPI-style authentication over HTTP is really inherently
> flawed since GSSAPI provides connection authentication whereas HTTP
> authentication is per-request. Some implementations of the server side
> (mod_auth_sspi in this case) will require the client to reauthenticate
> at every request, for this reason. Enabling KeepAlive in the httpd
> configuration may work around that.
I don't think the KeepAlive is disabled. At least the connection is
persistent and not closed every time. That's what puzzles me: even
though the connection stays open, Subversion/neon still re-authenticates
for every packet sent.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [neon] excessive data transfer with SSPI
Posted by Carlos Alberto Costa Beppler <be...@gmail.com>.
As pointed in here: http://www.innovation.ch/personal/ronald/ntlm.html.
The handshake of NTLM on HTTP envolves 3 transmissions of the request.
To workaround this for big posts IIS sometimes authenticates only the
first request on a keep alive connection. I don´t recall the kb
article where this is explained.
Maybe the Apache implementation is authenticating every request.
On 1/11/06, Stefan Küng <to...@gmail.com> wrote:
Re: [neon] excessive data transfer with SSPI
Posted by Stefan Küng <to...@gmail.com>.
Joe Orton wrote:
> Can you capture neon debug logs or ethereal traces and make them
> available to me? (preferably with a small file being committed to
> illustrate the problem)
Ok, attached are two debug logs. One from the command
$ svn ls -v https://192.168.2.2/svn/DUnit
the other is from the command
$ svn ci d:\test\DUnit2 -m ""
where I added the file 'autogen.sh' from the Subversion working copy.
Hope this helps.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
Re: [neon] excessive data transfer with SSPI
Posted by Joe Orton <jo...@manyfish.co.uk>.
Hi Stefan,
On Wed, Jan 11, 2006 at 08:16:52PM +0100, Stefan Küng wrote:
> 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!
Can you capture neon debug logs or ethereal traces and make them
available to me? (preferably with a small file being committed to
illustrate the problem)
If the server requires authentication only for PUT requests, then it
might be expected that some of the request bodies have to be resent
after authentication, when checking in. I can't think why checking
*out* would lead to problems of the same magnitude, though.
Trying to do GSSAPI-style authentication over HTTP is really inherently
flawed since GSSAPI provides connection authentication whereas HTTP
authentication is per-request. Some implementations of the server side
(mod_auth_sspi in this case) will require the client to reauthenticate
at every request, for this reason. Enabling KeepAlive in the httpd
configuration may work around that.
Regards,
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org