RFC trying to support non RPC Pipe service(s)
nopower at suse.com
Wed Jul 30 03:36:38 MDT 2014
So, I'm trying to get my head around this stuff again :/
On 08/07/14 10:03, Stefan (metze) Metzmacher wrote:
>>> The raw socket handling is already generic:
>>> - tstream_npa_accept_existing_send/recv() handles this for the server
>>> see the code arround setup_named_pipe_socket() in
>>> or tstream_setup_named_pipe() in source4/smbd/service_named_pipe.c
>>> - tstream_smbXcli_np_open_send/recv handles it for the client.
>>> something like your patch to change the fragment size should be fine.
>>> So basically the client and server just have a tstream socket, which
>>> the named pipe. The server decides it is used in message or byte mode.
>>> So each side can read and write bytes to the socket.
>>> Then we helper functions to read a pdu from the socket
>>> and a helper function to write a pdu into the socket.
>>> They can use idl generated structures, but only it's easy to represent
>>> the protocol in something similar to ndr.
>>> The server can be a completely separated binary or forked from the main
>> I am still fond of the idea of getting as much stuff for free as I can,
>> if you don't see the value in having a more generic solution then would
>> there be objection to still using the (non idl generated) server side
>> hooks (e.g. raw_pipe_entry in source3/rpc_server/srv_pipe_register.c) I
>> could then manually register the server etc. instead of using the my idl
>> generated server hooks ?
> source3/rpc_server/*.c is going to die soon see
have to admit dont see the part about rpc_server/*.c going away,
unfortunately I don't fully even understand what the details involved in
that task are :-( Is there anything that gives a highlevel or more
descriptive view of what will replace source3/rpc_server/* ?
> The code from source3/rpc_server/srv_pipe_hnd.c can be simplified
> as we only have FAKE_FILE_TYPE_NAMED_PIPE_PROXY and don't really need
> this layer anymore.
I'd like to try and understand what you are suggesting above for the
> It can move to source3/smbd/pipes.c
Well moving that code to pipes.c is clear but not sure what you mean
with regard to the simplification of the code, do you just mean np_open
& friends can be simplified wrt handling testing/switching on
FAKE_FILE_TYPE ? because only FAKE_FILE_TYPE_NAMED_PIPE_PROXY is used,
or do you mean some deeper changes to the internals of those methods, if
so could you elaborate a little more what you mean
> And there we could have the very tiny infrastructure I described above.
>> I guess when I got to the point of thinking about how to provide the
>> server code (and following the rpc stuff for reference/learning) it
>> looked neater to hook into the existing loop there (and indeed there is
>> only a small amount of code on the server side is needed to do that)
>> That is in part because I didn't seperate it out either, it was
>> convienent to just make the decision in new method
>> 'handle_internal_pipe_socketpair' routine and I don't need to do any
>> hard coded switching on pipe names.
> There we can share some of the code, but first we need to remove
> everything that's
> dcerpc specific. We just need an infrastructure to register a wellknown pipe
> names and a function (+ private_data) that starts the server loop for
> the internal service.
By server loop (in the dcerpc case) I assume you mean the call to
And the infrastructure you mention, and you expect that this is handles
all pipes eg. the normal dcerpc ones and weird ones like the 'raw' one I
am trying to handle? If so would I be correct in saying for all dcerpc
pipes a single 'function' will exist to call
dcerpc_read_ncacn_packet_send (and setup the associated callback) and
that for each other exotic pipe a custom 'function' can exist to provide
a similar server loop? If that is correct then np_open would still call
'make_internal_rpc_pipe_socketpair' (maybe renamed to
'make_internal_pipe_socketpair') passing FILE_TYPE_BYTE_MODE_PIPE or
FILE_TYPE_MESSAGE_MODE_PIPE as determined by the pipename from
registered info. In this case 'make_internal_rpc_pipe_socketpair' would
no longer call the dcerpc related server loop, instead np_open would
call the assocated server_loop function (again determined by the
pipename from registered info) Am I off the mark here or did you mean
something entirely different?
More information about the samba-technical