dce/rpc "client" api

[Gerald Carter]

Jeremy Allison wrote:
> 
> typedef struct cli_connect_fns
> {
>       /* create new connection.  strictly speaking, 
>	   one arg should be full dce/rpc format: e.g
>	   "ncacn_np:\\server\pipe\pipename" */
>       void *cli_connect_add(const char *pipe_name,
>                                 const vuser_key *key,
>                                 const char *srv_name,
>                                 const struct ntuser_creds *ntc,
>                                 BOOL reuse, 
>				  BOOL *is_new_connection);
>
>       /* terminate client connection */
>       void cli_connection_free(void *con);
>
>       /* get nt creds associated with an msrpc session. */
>       struct ntdom_info *cli_conn_get_ntinfo(void *con);
>
>       /* get a server name associated with a connection */
>       BOOL cli_con_get_srvname(void *con, char *srv_name);
>
>       /* write to a pipe */
>       BOOL rpc_api_write(void *con, prs_struct *data);
>
>       /* read from a pipe */
>       BOOL rpc_api_rcv_pdu(void *con, prs_struct *rdata);
>
>       /* detect dead servers. The fd is set to -1 when we 
>	   get an error */
>       BOOL rpc_con_ok(void *con);
>
>       /* read and write to a pipe */
>       BOOL rpc_api_send_rcv_pdu(void *con, prs_struct *data,
>                         prs_struct *rdata);
>
> } cli_connect_fns;

I think the purpose of these functions is to provide 
a means of abstracting the transport layer over which 
the dce/rpc pdu's are sent.  The dce/rpc client
would have not notion of whether or not the underlying 
transport  was tcp or smb.  This is handled by the 
internals of the functions themselves.

Luke will have to answer why you would want the 
possibilities of multiple transports (other than 
because of the spec).  In my mind, "turning on one 
transport support" would be a command line switch
or something.  Say "use smb for the dce/rpc connection
to server 1 and use tcp for the connection to server 2".

Does this sound right Luke?


> The only thing I'm not keen on here is the returning
> of (void *) as the type of a "con". I know it's the
> correct abstract data type thing to do, but I'd like
> to initially see the internal data type of "con" before
> deciding.

While this may change, the purpose (as I understand it)
for a cli_connection is to provide a means of tracking 
connections to multiple servers (whereas the current 
behavior of smbclient only allows one connection at a 
time).  Mostly this shows up in rpcclient.  The 
cli_connection structs are stored in an array.  Each struct 
holds enough information to track the cli_state struct
for a given server.

Since this is client side code, it is the 
equivalent of 

	net use \\server1\share1
	net use \\server2\share2


struct cli_connection
{
        char *srv_name;
        char *pipe_name;
        struct user_creds usr_creds;

        int type;

        union
        {
                struct ncacn_np *smb;
                struct msrpc_local *local;
        }
        msrpc;

        cli_auth_fns *auth;
        void *auth_info;
        void *auth_creds;
};






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 )