RFC trying to support non RPC Pipe service(s)

[Stefan (metze) Metzmacher]

Hi Noel,

> I have been looking into MS-WSP which communicates over SMB with named
> pipes. However, unlike other named-pipe services it doesn't use RPC. The
> patchset attached is a WIP implementation of some infrastructure heavily
> based/influenced by the RPC framework to help provide services that use
> pipes in that manner and/or create clients that want to communicate with
> such services.
>
> In my own mind I have been calling this mode of operation 'raw' pipe (as
> opposed to RPC) and I use that term heavily in naming of functions,
> files etc.  However, it strikes me that probably the term might mean
> something completely different in the SMB world (which I know little
> about), if so it would be good to get input for a different term or name
> to use if appropriate.u
> One of my main worries is that I have missed something completely
> obvious and that my little bit of work here is completely unnecessary so
> it would be good to know if that is the case, e.g. is this nuts?, should
> I have done/used something else?
> Some other random notes:
>   * Currently although the code here should (afaict) be independent of
> the RPC implementation it is based on, it lives in the same directory
> structure, I can change that of course but I would like to get some more
> direction before make possibly useless changes
>   * perhaps more could be shared with the existing RPC code :-/ but for
> me at the moment there is clarity in the separation
>   * I'm aware the DEBUG statements are too many and at inappropriate
> debug levels ;-)
>   * there is only a source3 implementation, I notice there are also
> source4 implementations for rpc servers (but I confess I haven't looked
> to see what differences there are or why they are duplicated)
>   * similarly the idl only generates a synchronous client helper at the
> moment
>   * there is a reference implementation of a server and client in the
> patch set which probably illustrates things better

I'm not sure we really need a heavy wight infrastructure like this,
basically copying multiple layers of DCERPC infrastructures.

And as every protocol that's implemented on top of named pipes
is different, I'd propose to avoid a generic infrastructure at all.

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
source3/rpc_server/rpc_server.c
  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
represents
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
smbd.

If required we can test the detailed behavior of named pipes, we can
implement
an npecho server, I've started something like this a while ago,
(totally work in progress hacks,
https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-named-pipe)
It also has a server and client tests for windows.
We can then implement the same server and client tests using the
mentioned tstream based infrastructure within Samba.

I hope my summary is not too bleak, given the large patch you already
produced:-)

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140701/1a082ee7/attachment.pgp>