DCE/RPC over SMB - code walk-through.

[Luke Kenneth Casson Leighton]

ok.  the next item to cover is non-handle-based DCE/RPC functions.  these
are basically "one-off" functions, for example, net_srv_get_info(),
net_share_enum() of \PIPE\srvsvc and the net_req_chal(), net_auth2(),
net_sam_logon() sequences of \PIPE\NETLOGON which i will work my way round
to covering eventually (they're used in a... slightly unorthodox manner :)

examine cli_srvsvc.c's implementation of NetServerGetInfo, here named
srv_net_srv_get_info().  like in lsa_open_policy, it calls
cli_connection_init().  the arguments are then flattened,
rpc_con_pipe_req() is called, the data shipped, response arguments
received, turned into modified parameter arguments (in this case, the
status code and the NET_SERVER_CTR) and then...

cli_connection_unlink() is called directly.  eh??  what happened to the
policy handle like in lsa_open_policy()?  well, there isn't one.  
strictly speaking, there _should_ be, and it should be (i.e there should
be one returned by cli_connection_init(), and srv_net_srv_get_info()
should call close_policy_hnd() on it.  but that's another matter to deal
with, there are too many of these functions to make such a change, i have
better things to do, unless it can be done with sed).

this is therefore an example of "implicit" handles, which is, as i
understand it, DCOM terminology for when you're messing with IDL files
(which we don't have) to get the code to manage connections _for_ you.
whereas, lsa_open_policy() is an example of "explicit" handles, which
means that you actually _see_ the policy handle with which the connection
is associated, and you have to call a close function to disconnect
(eventually).

the implementation of "implicit" policy handles in the rpc_client/ code is
_really_ expensive at the moment.  for each "implicit" connection, the
connection is re-established if there isn't one, and existing one used if
there exists one with the right user credentials for the client (which is
why i wrote smb-agent, by the way: it thunks all these connections from
the same user down onto one _actual_ smb connection, over-the-wire).

when the function is done, cli_connection_free() drops the connection
count. at the moment, that means that if there are no other users on the
connection, it's torn down.

and setting up SMB connections is inordinately expensive, effectively
turning a function call turnaround time from the milliseconds range to the
order of seconds.  this is unacceptable.

as a result, it is necessary to _maintain_ the SMB connection, even though
there are no active users on it.  on NT, the SMB connection is maintained
for maybe 10 to 15 minutes at idle, before eventually being automatically
dropped (actually, it's put into a disconnected state, which i'm also
going to have to emulate, eventually).

the alternatives -- tearing it down and reestablishing on-demand -- are
just too costly.

there's not exactly much to say about the server-side implementation of
_srv_net_srv_get_info in srvsvc/srv_srvsvc_nt.c, so i won't.

:)

luke