dce/rpc "client" api

Luke Kenneth Casson Leighton lkcl at samba.org
Fri Aug 18 05:11:54 GMT 2000


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

cool.

to disable ncaclrpc, it will then be a matter of commenting out 3 lines of
code.

andrew proposed making it an lp_xxx configureable item.

>  I need to keep rpcclient working as it is through the next release
> (and for testing in the meantime)

cool.

well, i am debugging things at the mo (insure is telling me i am freeing
some mem twice).
 
> > 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 :-)

urr... yeh!
 
> > 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.  

which is what i wanted to avoid.
 
> 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),

that's what i used in the first (2nd) rewrite of nmbd.  it got so bad that
i decided enough was enough and moved to a void* + 2 callbacks (one for
when a UDP response _Was_ received and one for when a response was not).

so the technique (fn-array + void*-typecast) is pretty predominant in
samba, anyway.

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

*shrug*.





More information about the samba-technical mailing list