j66st
asked on
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.
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
ASKER
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).
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).
>>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.
>>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.
ASKER
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.
(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.
ASKER
Hmm, maybe I should read this article: http://www.codeproject.com/Articles/15223/Understanding-Custom-Marshaling-Part-1
and the "Essential COM" book.
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)
ASKER
I found this article:
http://www.codeproject.com /Articles/ 36682/DCOM -Transport
and contacted the author. I think we might be able to work out a solution.
http://www.codeproject.com
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.
ASKER
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. 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.
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.
I've requested that this question be deleted for the following reason:
Not enough information to confirm an answer.
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
ASKER
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):
http://www.codeproject.com/KB/COM/ComBridge/combridge.zip
But this is demo of commercial library. No source code.
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):
http://www.codeproject.com/KB/COM/ComBridge/combridge.zip
But this is demo of commercial library. No source code.