dce/rpc "client" api

[Gerald Carter]

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
this better?





Cheers, jerry
----------------------------------------------------------------------
   /\  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
       http://www.eng.auburn.edu/~cartegw

       "...a hundred billion castaways looking for a home."
                                - Sting "Message in a Bottle" ( 1979 )