RE: excessive data transfer with SSPI

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:tortoisesvn@gmail.com]
Sent: Wednesday, January 11, 2006 9:17 PM
To: dev@subversion.tigris.org; neon@webdav.org
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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org