smbwall

[David Lee]

On Thu, 31 Jan 2002, Garry J. Garrett wrote:

> [...]
> My point is, I'm sure that there is a limitation somewhere; we just 
> don't know what that limit is.  It may be smaller than you are inclined
> to think at first glance.  That's all I'm trying to say.

We also need to keep a distinction between a default limit (e.g. I think
it was 48 in early Solaris a few years ago) and a maximum-configurable
limit (if any). 

> Again, my concern with allocating a real pseudo terminal with each
> and every SMB connection (and I realize that that question has
> not been settled) is running out of pseudo terminals.  Even if
> Linux can go higher than Solaris, you'd want to stick with the
> lowest common denominator in terms of determining wether or not
> it was a good idea to do this.

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...)

> I, personally, think it would be a good idea to issue a real
> pseudo terminal (if you issue some other kind of pseudo terminal,
> how to you get "wall" to be able to send messages there without
> hacking the code to wall, which you can't do on more turn-key
> Unices, like commercial ones), but I just don't think it's 
> realistic to issue one per smb client.  That means that you
> can send wall messages to all the smb clients, but there would
> be no way to send write messages to individual smb clients
> (though you can do that with smbclient - you just can't use
> the stock standard "write" to do it).

I take the point you are making.

But I would be keen to adopt the telnet-like model of pty-per-client
wherever reasonably practicable. 

If an OS has only been able to support a relatively low, un-increasable,
limit of telnet-like sessions (traditional use of ptys), how realistic is
it to expect it to support significantly more samba clients anyway?  In
such a context, making an approximate equivalence between telnet-like
sessions and Samba sessions seems reasonable enough. 

You have highlighted my key issue of enabling out-of-the-box UNIX/server
applications to address samba clients, as though they are telnet-like. 
That includes both "wall" and "write".

Suggestions:

1. We endeavour to support pty-per-smbd where reasonably possible.

2. Yhe relevant code be done in general-purpose fashion, so that other
   applications can be built.  One such example might be a "wall-listener"
   for an OS which cannot do pty-per-smbd (or choose/configure not to).

-- 

:  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.                  :