CVS update: samba/source/msrpc (fwd)

Nicolas Williams Nicolas.Williams at
Fri Jan 21 19:14:44 GMT 2000

On Sat, Jan 22, 2000 at 06:00:38AM +1100, Luke Kenneth Casson Leighton wrote:
> 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:
> > > 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?


> AGH!
> therefore, i have to do a read_data_with_timeout(minsize=1 byte, maxsize =
> and this is the _short_ story, not the long one :-)

Ok. Sounds like you got a handle on it! :)

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

Well yes. But the most important requirement is that SMBDs pass the
DCE/RPC calls to a master process for each DCE/RPC service. That allows
each DCE/RPC service code author to choose the implementation
(fork()ing, async, threaded). You can choose to fork() today and a year
from now clean up the code to be reentrant and convert it to async.

As for writing reentrant code, the single most important rule to keep in
mind "avoid statics and globals for storing call-specific state". Pass
around the state as a function argument. The remaining work of making
the code truly reentrant and thread-safe can be done later

-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

More information about the samba-technical mailing list