dce/rpc "client" api
gcarter at valinux.com
Fri Aug 18 04:41:19 GMT 2000
Luke Kenneth Casson Leighton wrote:
> ok, then i rephrase: i am proposing the following api
> in cli_connect.c.
Luke, if this goes into TNG and everyone agrees on it,
I will merge it into rpcclient in HEAD. I need to
keep rpcclient working as it is through the next
release (and for testing in the meantime)
> [the _reason_ for adding it is to make it clearer what
> is going on. i spent an hour and a half explaining the
> purpose of and the difference between the ncacn_np
> and ncalrpc implementations. because it was not
> clear, he removed large segments of code, in the
> interests of simplicity].
So that 'he' would have been me i think :-)
> so, this api marks a clear delineation
> between transport-specific jobs and the _use_ of
> the transports, which was otherwise embedded/hard-coded
> into cli_connect.c with damn-stupid switch statements.
Which is exactly why I thought it confusing. I like the
function pointer struct better as far a code readbility
goes. Maybe harder to debug. but cleaner to write.
> the cli_ncacn_np.c cli_connect_add function calls
> ncacn_np_use_add(). this function will initiate an SMB
> IPC$ and perform an SMBopenX / NTSMBcreateX on the
> DCE/RPC pipe name.
> by contrast, the cli_ncalrpc.c cli_connect_add function
> calls msrpc_use_add. this function will initiate a
> unix domain socket to var/locks/.msrpc/DCERPCpipename.
> cli_connect_add() returns a void*. this is the state
> info required for the connection. each impl.,
> cli_ncacn_np.c, cli_ncalrpc.c, cli_ncacn_tcp.c etc.
> will typecast its state to-and-fro. with 8 functions
> and under 100 lines of code, it is hardly difficult
> to verify that the typecasts are being done correctly:
I think the void* return value is the only way to
generically pass back information from the functions
unless they all share a state information for
representing a connection.
Since you need things like ip_addr and port number
for a TCP connection and a destination netbios name for
an SMB connection, you can either (1) put all in the
information needed to represent all possible
connection environments (very bad idea), or (2) return
a struct* and the struct contains a void* (same as what
you have now). Anyone have a good idea of how to do
/\ Gerald (Jerry) Carter Professional Services
\/ http://www.valinux.com VA Linux Systems gcarter at valinux.com
http://www.samba.org SAMBA Team jerry at samba.org
"...a hundred billion castaways looking for a home."
- Sting "Message in a Bottle" ( 1979 )
More information about the samba-technical