CVS update: samba/source/msrpc (fwd)
Luke Kenneth Casson Leighton
lkcl at samba.org
Fri Jan 21 19:00:38 GMT 2000
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
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!
therefore, i have to do a read_data_with_timeout(minsize=1 byte, maxsize =
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.
More information about the samba-technical