t.d.lee at durham.ac.uk
Fri Feb 1 06:40:25 GMT 2002
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
> 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".
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. :
More information about the samba-technical