one of those horrible realisations

[Luke Kenneth Casson Leighton]

On Fri, 4 Feb 2000, Charles N. Owens wrote:

> Luke Kenneth Casson Leighton wrote:
> 
> > ok,  this is one of those nasty moments when you realise it's much more
> > complex than you thought.
> >
> > multi-user systems, WinDD, WInframe, TSE.  multiplex multiple users onto
> > one smbd process.
> 
> This is the _default_ behavior with TSE, yes.  We've got quite a bit of
> TSE+Metaframe running hereabouts (served by a Samba PDC, of course !).  I've
> read in various places that with WinFrame, WinDD (and perhaps TSE as well)
> that the munging of all users onto a single SMB connection results in all
> access from all users being mapped to the unix uid of the first connected
> user (very bad).  When I first started playing with TSE this had me very

yes, that's because of the usage of sesssetup_user i talked about in a
bug-report or two to samba-technical.

> There is a huge scalability problem on the NT side, however, (and maybe with
> Samba as well).  The number of open files for a single SMB connection is
> limited (by NT) to 2048.  Once your TSE server approaches this limit
> stability goes out the window (snicker).  We were seeing blue screens daily

_actually_, it's not a limit for samba, the limit is... hmmm, probably
close to 65536 (maybe 50,000) on samba.

microsoft chose to only use the first 11 bits of the smb file handle for
files, and the rest for MSRPC pipes, instead of sharing the [limited] 16
bit file handle properly!!!

>      To maintain compatibility with existing Server Message Block
>      (SMB)-based products (for example, Windows NT 3.x and 4.0, Windows
>      95), Terminal Server's use of SMB has not been modified from
>      Windows NT Server 4.0. This can cause a problem if many Terminal
>      Server users connect to a single network share, either on the
>      Terminal Server or elsewhere on the network. The potential problem
>      is an SMB limitation of 2048 open file handles.

bullshit, it's _not_ an SMB limitation, it's microsoft own self-imposed
implementation limitation.

> [speculation] A possible implication here is that there may be some kind of
> future (Win2K?) enhancement planned that will remove this limit on the
> number of open file handles.  If not, then I think that Samba is fine as is,

well, hopefully, someone on this list will notice this message and post a
bug-report.

they _might_ have fixed it in nt5 TSE, but i doubt it.

> There is probably some room for improvement on the Samba side in terms of
> scalability.  With this registry fix in place, of course, each TSE user gets
> their own smbd process... consuming 1.5-2 MB of RAM.  I'm guessing that the

the samba-tng library architecture reduces the size of processes
dramatically.