CVS update: tng/source/passdb

[Christopher R. Hertel]

> "Christopher R. Hertel" wrote:
> 
> > Being pedantic, he's right that SMB can be seen as a primitive RPC-style
> > protocol.
> 
> which was my point.

It did not seem to have anything to do with the message you sent to Simo.

> I don't think an IDL is a requirement of an RPC protocol
> after all an IDL is only a method of specifing the on wire seralization.

The marshalling... Yes, IDL provides a tool for formalizing the 
marshalling process.

Generally, a true RPC architecture will have a separate
marshalling/unmarshalling layer.  This is part of the RPC abstraction.  In
SMB, that layer is minimal and generally hand-tooled.  Remember that SMB
was based on DOS calls. 

> > Of course, many client-server protocols can be seen as RPC-style
> > protocols.
> 
> but not all

Not all rectangles are squares.

> > All that's required in order for a protocol to look like RPC
> > is that each packet identify the proceedure it is calling.
> 
> and that there is a 'call' and a 'responce'

Replies are not required.  Only that the local library stub routine return
when it completes. 

> > The original idea behind RPC is that the RPC call not look any different
> > to the programmer than a local proceedure call.
> 
> true but are you saying that inside the SMB library it
> was not implemented as a local api?

Which SMB library?  Samba's?  MS-DOS's?

I'll guess the latter, and I'll say it probably wasn't.  It was the DOS
Redirector code that was given an API, most likely, and SMB redirection
was just one bit of code that used that API.  The SMB code, most likely,
just re-packaged the DOS call parameters and sent them via the NetBIOS
API. 

I put a lot of weasle words into the above because, in fact, I don't 
really know how it was done.  That's my best guess based on what I know 
of SMB and NetBIOS, and the ancient lore I've heard.

I think that libsmbclient is the closest Samba has to an "SMB API".

> >  The original idea behind
> > SMB was that it bundled up local DOS calls and shoved them into NetBIOS.
> > Again, a primative RPC mechanism.
> 
> just like an api call to DOS the procedure is called and
> the result is returned, is this not what SMB does?

No, the API call is made to DOS and the redirector code within DOS 
packages it up in a NetBIOS frame.  How the NetBIOS frame is sent is a 
different issue.  Windows/DOS can send NetBIOS frames over multiple 
transports.  Again, I don't know if DOS or, nowdays, Windows has a 
separate SMB API.  W2K might.

> > None of that is important, however, as none of it supports any of David's
> > original argument's against Simo's message.
> 
> attual I think you have made my point for me :)

No, I don't think any of this argues against Simo's point at all.

> correct, but not all client server systems are an RPC, for example
> the TIB uses a atomic messaging system where there is no
> reply. The reply is just multicast on another message queue
> it is up to the programmer to handle the asyncronious nator
> of the system.

RPC does not need to be synchronous, nor does there need to be a network 
reply.  RPC is *typically* synchronous, and there is *typically* a reply 
(to ensure that the message was sent).  These are not requirements of the 
general case RPC architecture.  They are good ideas, though, as RPC is 
rather sloppy without them.  Serialization, as you point out, being a 
good thing.

> > Again, what makes RPC RPC is simply that a function-call interface is
> > available to the programmer.
> 
> yep
> 
> > There are details underlying that interface.
> > A more formal RPC system will have things like IDL,
> 
> it might
> 
> > a hidden
> > [un]marshalling layer, etc.
> 
> if the wire level is equal to the ABI then this is not always needed.

That cannot be guaranteed cross-platform.  Byte ordering, word alignment 
and such are common problems in RPC.  Microsoft doesn't care, because 
they specify the hardware platform.

> > SMB over NetBIOS has primitive analogs, so it
> > can be viewed as an RPC system, if it's useful to view it that way.
> 
> it is, but it can be view to be not.

...which, again, shoots you right out of the water.  SMB is often seen as
a simple client/server protocol.  Samba implements it as such, rather than
implementing it as an RPC protocol.  Again, libsmbclient may be different,
offering an API that maps to the SMB messages.  If so (and I don't know
because I have not had enough time to dig into libsmbclient...I should),
then libsmbclient is a stub library for SMB viewed as an RPC protocol.

No biggie.

Chris -)-----

-- 
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services

    Ideals are like stars; you will not succeed in touching them
    with your hands...you choose them as your guides, and following
    them you will reach your destiny.  --Carl Schultz