RFC trying to support non RPC Pipe service(s)

[Noel Power]

Hi Volker
On 01/07/14 09:22, Volker Lendecke wrote:
> On Mon, Jun 30, 2014 at 06:47:38PM +0100, Noel Power wrote:
>> Hi,
>>
>> 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.
>> 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
> Why do you make the raw pipe support depend on the RPC
> infrastructure?
it doesn't, it *currently* should be completely separate

 I'd rather say the RPC infrastructure should
depend on raw pipes. That's the basic question I have when
looking at the code.

I agree and this is exactly the kindof thing I wanted to get to :-), in
essence afaics most of the code in the 'rpc' related modules seems to be
potentially common SMB Pipe code but is all under the 'rpc' naming
banner with some built in dependencies to support DCERPC specifics (e.g.
the fragment/pdu handling, RPC bind, rpc specific client/server
interaction with the generated code etc.).
In my initial implementation I was piggybacking (by harcoding) on top of
the existing code in the rpc tree, the reason I separated it out
completely was to try to clearly see what I was using and what I wasn't
(and hopefully be able to identify what could be common) In addition to
trying to find out if there was not already something that allowed easy
access to this sort of pipe communication I really want to tease out how
to munge this stuff together with the existing code in a sensible way

>  Please be patient with me, I haven't
> looked at that code for quite a while.
thanks for taking the time!!

Noel