remote procedure calls

Question

Does any one know a good way to do remote procedure calls in windows (non .net) environmental?

I cant find much information on how to do it and the msdn only has the .net version.

.

Edit:

Thanks for the answers so far. What i need it for is to communicate with a service on the same computer which will send progress reports back to the "client". The reason im intersted in rpc is because of vistas uac and how services cant talk to normal apps unless they use rpc or pipes. Looking into pipes, they seem to be entirely text based and i was under the impression that rpc can pass strongly typed values across.

I will look into DCOM as well.

Answer 1

DCOM is has a remote procedure call mechanism based on DCE RPC. If you build your system as a COM component or put a COM wrapper over the API you want to expose you could use this. Beyond that, you might want to expand on your question with some more insight into the specifics of the problem. I don't really have a handle on whether the problem has any aspects that might preclude the use of DCOM.

An alternative approach would be to place a web service wrapper around the application. Web services (certainly those based on SOAP or XML-RPC) are really just a RPC mechanism using HTTP as a transport protocol.

Answer 2

You can call code remotely on windows in a hundred different ways; sockets, DCom etc... Microsoft at one stage supported rpcgen (based on DCE RPC) which allowed you to define remote API calls and it's compiler would write the glue code. This was the underlying layer in DCOM.

It isn't compatible with the UNIX ONC-RPC which is easier to use and a wider standard. You might want to look at one of the ONC_RPC toolkits if somehting like DCOM is not for you.

Tony

Answer 3

If you are only interested in talking between processes on the same machine, boost::interprocess is a cool way of getting a channel for them to talk through.

More windows specific solutions is a shared memory mapped file and system global mutexes/signals or named pipes.

boost::serialize and google protocol buffers are ways of converting the data you send between the processes to binary strings that are less dependent on structure packing and other things that may differ between different executables.

boost::interprocess, boost::serialize and protocol buffers should be platform independent so technically it could work on Linux/Mac as well!

Answer 4

Here is something we've been using in 1996 at Cheyenne Software on Win NT for InocuLAN antivirus. This is pure RPC, none of the OO layer. I hope it's still available in newer Windows.

Answer 5

Well, sorted by complexity, overhead and reverse speed, these possibilities come to my mind:

• SOAP (which you excluded already)
• Corba
• DCOM (DCE)
• exchange of XML messages
• ONC-RPC (SunRPC)
• exchange of HTTP-like messages
• exchange of telnet-like messages (line oriented)

For all, you will get more or less ready to use (ready to be frustrated) libraries, packages etc. as open source.

Some of the above might sound strange, but actually, we do often use HTTP or Telnet for RPC. The reason is that you don't need fancy environments to test, any most alien software can easily adapt to it. These also make your program's services easily usable from either a WebBrowser, a telnet session or another program which simply opens a socket to it and sends the request. For example, most of my programs include a --scripting command line argument, which opens a telnet port via which you can send access the whole applications object model via a JavaScript like language. This can also be used to remote control any app very easily - without any effort. If you have written such a framework once, it can be reused for every new app (see how that looks here)

I have to admit, that all of my apps are written in an environment, where all of the above are already included and ready to use, both as clients and as servers.

Summary: use the simplest thing, that does the work. You dont need Corba or SOAP unless your app needs to be integrated into such an infrastructure.

Answer 6

There are more info here :
Get "Microsoft Platform SDK for Windows Server 2003 R2", after install view samples at folder ...\Samples\NetDS\RPC
sdk_NetDS_RPC.exe - source sample soapsdk.exe - MS samples
More Links :
Trace RPC Calls and Notify the COM+ Events to Your Program
FastRpc
secure rpc
A lightweight RPC library based on XML and HTTP.
old help, but useful RPC.HLP
[MS-RPCE]: Remote Procedure Call Protocol Extensions
[MS-RPCH]: Remote Procedure Call over HTTP Protocol Specification
[MS-COM]: Component Object Model Plus (COM+) Protocol Specification DCOM

Answer 7

Yeah I agree with Isalamon - just use the real RPC that's already built in with MIDL. You can get a O'Reilly book about DCE RPC. If you are on the same machine, just use a binding host of ncalrpc.