CVS update: tng/source/passdb
David Allan Finch
david.allan at finch.org
Tue Jan 8 12:57:03 GMT 2002
"Christopher R. Hertel" wrote:
> Being pedantic, he's right that SMB can be seen as a primitive RPC-style
> protocol.
which was my point.
> The packets identify operations and pass parameters to those
> operations. In the more formal sense of RPC, that is, an RPC system in
> which the marshalling, unmarshalling mechanisms are prescriged and the
> interfaces are defined using some form of IDL... well, SMB doesn't
> qualify.
I don't think an IDL is a requirement of an RPC protocol
after all an IDL is only a method of specifing the the
on wire seralization.
> Of course, many client-server protocols can be seen as RPC-style
> protocols.
but not all
> 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'
> 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?
> 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?
> 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 :)
> > Please tell us how an 'RPC protocol' differs from a client/server protocol?
>
> The distiction was not clear in David's original message, nor was it
> important. RPC protocols *are*, by their very nature, client/server.
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.
> 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.
> 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.
More information about the samba-technical
mailing list