DCOM/RPC transport over RDP virtual channel?

In a Win32 application (C++ native code) that runs on a Windows Terminal Server via Remote Desktop  I want to be able to call COM objects that run on the client computer (in order to communicate with local hardware). I could use DCOM over TCP/IP but that requires opening extra ports and extra authentication, in parallel to the already existing RDP link. Instead, I would like to tunnel the DCOM remote procedure calls (RPC) over an RDP Virtual Channel  (similar to the way client-side printer drivers are accessed).

This should work on Windows 2008 Server with Windows XP and Windows 7 clients.

Basically I know about the technologies involved, but I am wondering if someone has invented that wheel already. Can anyone point me to articles, example code, discussions about this topic?

Or perhaps tell me why this would be a bad idea.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

I don't think it's a bad idea at all, but from my understanding RDP VCs worl more like a named pipe rather than a RPC marshaller. So, if the data you have to send is not too complex or structured, that's actually a good way to communicate. And even if it is complex, you can always send a struct as a BLOB. This article here offers a nice implementation: http://www.codeproject.com/Articles/87875/User-Mode-Transport-of-the-Library-Via-Virtual-Cha ("User Mode Transport of the Library Via Virtual Channels")

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Oh, and if you were into Dynamic Virtual Channels, take a look at http://msdn.microsoft.com/en-us/library/windows/desktop/bb540855%28v=vs.85%29.aspx ("DVC Implementation Details ") and both http://msdn.microsoft.com/en-us/library/windows/desktop/bb540858%28v=vs.85%29.aspx ("DVC Server Module Example ") and http://msdn.microsoft.com/en-us/library/windows/desktop/bb540854%28v=vs.85%29.aspx ("DVC Client Plug-in Example ") linked from there.
j66stAuthor Commented:
jkr, thanks for your comments.

I've read several articles about how to use the static and dynamic Virtual Channels, I know how to send blobs to and from a client-side DLL. Named pipes are a supported transport layer for MS RPC, and indeed VC's are similar. I could design my own protocol on top of it, but a generic RPC link would be more universal.

So I was specifically looking for an existing implementation of the plumbing needed to let the DCOM/RPC marshaler use the RDP Virtual Channel as a transport layer.

Our app is used in local and remote desktop contexts. The advantage would be that I can use the same code to access the device control modules (DLLs/EXEs with COM interfaces).
Learn Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

>>So I was specifically looking for an existing implementation of the plumbing needed to let
>>the DCOM/RPC marshaler use the RDP Virtual Channel as a transport layer.

I strongly doubt that this is possible - in order for that to work, you would have to be able to specify a RPC protocol sequence (http://msdn.microsoft.com/en-us/library/windows/desktop/aa374395%28v=vs.85%29.aspx) to use with VCs, and that would have to be supported by MS itself.
j66stAuthor Commented:
I think it could be done. It should be a matter of marshaling and unmarshaling to the virtual channel. By using the same interfaces the COM runtime uses. If I implement an IStream interface around the virtual channel on both ends, and then use interfaces like IMarshal and IStdMarshallInfo and the Proxy/Stub code generated by the IDL compiler.
(Well that must be the chapter I skipped when reading Brockschmidt's "Inside OLE" book :-)
Some expert in the inner workings of COM must be able to tell how to do it, i guess.
j66stAuthor Commented:
Hmm, maybe I should read this article: http://www.codeproject.com/Articles/15223/Understanding-Custom-Marshaling-Part-1
and the "Essential COM" book.
Hm, yet at some point and DCOM code will have to deap with a RPC binding, and that unfortunately requires a protocol sequence for which there is no option to use a VC (so far)...
Just as I've been thinking about your (very interesting) idea tonight at $WATERING_HOLE for a while: Custom marshalling IMO won't help, since that does not address the protocol level. Yet, a relativiley simple thing that I'd find atttractive could be to send your data across the Virtual Channel as JSON, which would allow quite some automated processing/marshalling on either side. I don't want to discourage you, if you are able to come up wih a solution to directly connect RPC via these channels, I'd like to be the 1st one to know how you managed to get this to work ;o)
j66stAuthor Commented:
I found this article:
and contacted the author. I think we might be able to work out a solution.
Well, but you still can't directly use VCs as RPC transport. If I was to do that, I'd use the channels as described in that article (or the one I linked) and send the parameters as JSON - which is quite simple using e.g. libJSON. The making the call on the 'other side' is quite straightfoward.
j66stAuthor Commented:
Sorry, been very busy with other things last weeks.

JSON appears to me as a very light weight data serialization, nice for for script kiddies. Not suitable for large BLOBs and for remoting object interfaces.

My focus is on remoting of COM interfaces. Marshaling data and COM interfaces is all worked out in the DCE RPC and DCOM standards. We don't have to reinvent that. The marshaling code is spit out by the IDL compiler in the proxy/stub DLL. I want to use that. However, that DLL calls into the COM runtime. If the COM runtime cannot be linked to a custom transport layer as you stated, then these calls should be resolved by some replacement DLL, that emulates part of the COM runtime. That's how I see it.

I only expected that someone has done this before, and I think the author of the article I mentioned has developed a similar layer, which can be adapted to my needs.
>>JSON appears to me as a very light weight data serialization, nice for for script kiddies

Don't underestimate JSON, I tended to regard that as "JavaScript guys' lazy way of exchanging data", yet it can be quite powerful. I agree that a custom marshaller might be more efficiant, but the limit is where MS would have to specify a protocol sequence. Yet on the other hand, if you take a look at what a MIDL generated RPC stub actually does, you'll see that there is not a big difference to passing JSON in a technical point of view. It also depends of which type of IF you are trying to remote, I'd agree that e.g. a DirectX data source IF can hardly be encapsulated this way.
Guy Hengel [angelIII / a3]Billing EngineerCommented:
I've requested that this question be deleted for the following reason:

Not enough information to confirm an answer.
Well, cannot see "not enough information". Even my 1st comment contains a link that allows that to be solved, and since there's a lot of information put into this thread, I'd not like to see it deleted. Thus: I object.
Ooops, objecting
j66stAuthor Commented:
The solution marked above as accepted is not the real solution.

The article http://www.codeproject.com/Articles/36682/DCOM-Transport
(as I mentioned in this thread) is the right track. The same author has developed a commercial product that can be adapted to run COM/DCOM over RDP:

Here you can find ready implementation of full protocol - everything is supported (everything means everything, monstrous COM/DCOM project of any complexity can easily be railed on  arbitrary transport by it with adding only few lines of code to server and client):
But this is demo of commercial library. No source code.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows OS

From novice to tech pro — start learning today.