dce/rpc "client" api
Luke Kenneth Casson Leighton
lkcl at samba.org
Fri Aug 18 02:42:49 GMT 2000
> 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.
correct.
> Luke will have to answer why you would want the
> possibilities of multiple transports (other than
> because of the spec).
exchange client/server.
> 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?
yep.
the format of the connection "endpoint" actually contains full info
required to make the decision:
ncatype://server/dcerpcconnectpoint:portnum
e.g:
ncacn_tcp://192.168.138.2/123456789ABCDEF-1234-5678-123456-2:8080
connects using TCP to 192.168.138.2 on port 8080 to service 123456....
e.g:
ncacn_np://server/pipe/netlogon
connects using SMB to server on SMB-IPC$-DCE/RPC pipe NETLOGON.
at present, that's not implemented because i haven't added ncacn_tcp yet
so have no need - yet - of such a sophisticated specification method.
>
> > 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.
exactly.
a good example of this is when joining a wksta to a domain. *two*
connections are required: one to the wksta, the other to the PDC.
> 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;
removed.
> union
> {
> struct ncacn_np *smb;
> struct msrpc_local *local;
> }
> msrpc;
becomes a void* conn_info and add cli_connect_fns *con_fns.
>
> cli_auth_fns *auth;
> void *auth_info;
> void *auth_creds;
> };
More information about the samba-technical
mailing list