smbwall

[David Lee]

On Fri, 1 Feb 2002, Toomas Soome wrote:

> David Lee wrote:
> 
> > 
> > We have a Solaris 8 machine here, as a telnet/rlogin/slogin timesharing
> > machine, which has 1024 "/dev/pts" entries.
> > 
> > Our main Samba server can push at the 1000 mark.  But this is a dedicated
> > server, specifically with never more than a tiny number of non-Samba
> > connections.  (Of course *if* 1024 really is an absolute, never-be-topped,
> > limit, then I'm a little concerned about pty-per-smbd.  I need to
> > investigate and test, I suppose.  But my gut reaction is that I'd be
> > surprised if recent Solaris didn't allow in excess of 1024 telnet-like
> > connections...)
> > 
> 
> there is no upper limit on solaris 8 and up pts.  4096 is for example
> the largest pts in one system I have access to... 

Excellent.  Thanks.  I have just done a quick search and found an article,
dated 1996, on Sun's WWW site, which mentions:

   A practical limit is imposed by the format of the utmp file entry of
   62*62 =3844 telnets and another 3844 rlogins; it is best to keep
   'pt_cnt' under 3000.

That was over five years ago, and only goes up to the old version 2.5 of
Solaris.

So it is looking promising: almost 4000.  I wonder how many Samba sites
are pushing ~4000 simultaneous connections, even now.  Probably very, very
few.  And even if they are, then we can probably easily overcome it... 


Detail: feel free to skip:

What is the 3844 limit in utmp?  (Or perhaps more accurately "...in
telnet/rlogin use of utmp".)  I don't absolutely know, but I suspect it is
the encoding of the unique "char ut_id[4]" field.  Probably two bytes
fixed for type-of-connection, and the rest encoded using two alphanumeric
characters as 10 digits + 26 lower-case + 26 upper-case (=62).  This is
the model I borrowed in writing Samba's utmp code, so the limit would
currently apply to Samba too.

But if 3844 really is a problem, then we can probably use a different
encoding to relax this.  I kept Samba's coding of this is cleanly
contained in utmp.c's subroutine "ut_id_encode(...)".  And, judging by the
comments in the source file that I inserted at the time (which may, of
course not be entirely accurate!), it seems other services (CDE etc.) have
the capability to go higher. 

It would seem close to being a non-issue.

Hope that helps.


-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham                :
:  Phone: +44 191 374 2882                  U.K.                  :