CVS update: samba/source/msrpc (fwd)

[Luke Kenneth Casson Leighton]

On Fri, 21 Jan 2000, Nicolas Williams wrote:

> On Sat, Jan 22, 2000 at 05:08:13AM +1100, Luke Kenneth Casson Leighton wrote:
> > On Fri, 21 Jan 2000, Nicolas Williams wrote:
> > > I like it.
> > > 
> > > I've not had a chance to use SAMBA_TNG so some of what I'm about to
> > > suggest may already be there.
> > 
> > i'll review what you say / confirm.
> >  
> > > Here goes:
> 
> [...]
> 
> > >     - client transport addresses (NetBIOS name, IP address)
> > >     - share name (IPC$)
> > 
> > i'm going to have to do this, and it needs to be _much_ more than just
> > this.  from standard_sub_basic():
> > 
> > - local_machine
> > - remote machine
> > - remote proto
> > - logged-in username (changes for a NetrSamLogon or a NetWkstaGetInfo!!!)
> > - remote arch
> > - pid
> > - VERSION string
> > - ENVIRONMENT variables
> > - client ip
> > - automount server
> > - unix username
> 
> But storing that in a tdb keyed by <PID, vuid> as I suggested below
> would save you the trouble.

oh!  sorry!  that's what i meant to say :) :)  you pass the info over, and
reference it there.

 
> > 
> > >     - username used to authenticate to share (user, guest, null [anonymous])
> > 
> > yep, got that.  i also send the unix username + unix groups, to save me
> > having to do a getgroups() and getgrnam() on thhe othe side: why go to all
> > the hassle of generating more work for aan mssrpc daemon than is necessar:
> > it's already had to do a fork() just like smbd and we're even considering
> > optimising things so we don't have to do too many forks().
> 
> So that falls under the "various  information" clause I used below. Put
> it in the tdb record indexed by <PID, vuid>.
> 
> Why write the same data many times?

... *blink*. [various lights go on in luke's head.  candles, if anyone's
interested]

i like it!
 
> > i discovered that if i use read_data_with_timeout(min bytelength =1, max
> > bytelength = MAX_SMB_DATA_SIZE) that you don't _need_ to send the length
> > of the DCE/RPC data.
> > 
> > cool, huh?
> 
> Hmmm, so you pass SMB packets to the DCE/RPC daemons? Wouldn't it be

no, i don't: i strip out the SMB headers and just send the data.

> easier to just pass the [reassembled] DCE/RPC payload?

:-) :-) that was, as i mentioned, my first implementation.  i reassembled
individual DCE/RPC PDUs and then shipped them over.  i _did_ first of all
send a 2-byte "length-of-PDU", which i figured was redundant so instead
read the "length-of-PDU" from the actual DCE/RPC 16-byte header.

then i decided that i didn't _like_ the way that smbd had to know abot
DCE/RPC headers, so i just trashed the reassembly system and did a
read() and a write() to the unix socket!

well, i soon ran into problems with that, because if you do a read() you
don't know how much data is going to come back.  it's going to be a
minimum of 16 bytes (a DCE/RPC header) and it's going to be a maximum of a
DCE/RPC max_rcv_udp_size (up to 5680 bytes, but this is negotiable).

but, if you have multiple SMBreadXs, say, the minimum data size of 16
bytes is bullshit, because the last bit of a DCE/RPC pdu could be as small
as one byte!

AGH!

therefore, i have to do a read_data_with_timeout(minsize=1 byte, maxsize =
SMB_READ_BUFFER_MAX_SIZE).

and this is the _short_ story, not the long one :-)

> > so no, i don't want to go down this road.  i'll make it as easy as i can
> > for someone _else_ to do this, but no, it's not one for me.
> 
> Just leave the door open.

okie.  as long as i understand what's required.

it's not going to be trivial, i can guarantee that.
 
> > samba installations out there which peak at around 3,000 simultaneous
> > connections.  you think threads can cope with 3,000 connections?  i don't!
> 
> That limit varies from platform to platform. Anyways, Samba isn't ready
> for threading, though that could come on a daemon by daemon basis if the
> IPC system you use leaves room for it (i.e., SMBD processes should talk
> to a master daemon for each DCE/RPC service -- let that master daemon
> choose to fork(), pre-fork(), thread, whatever.

yehh... so as long as i make the code reentrant (code review needed!)
everyone should be happy.