Best choice for IPC between service and user application on Vista / XP / 7 RRS feed

  • Question

  • I hope this is the best choice of forum for this question-- I did a fair amount of searching a looking at forum names first.

    Our company has a client / server product running on XP which relies entirely on Windows messaging for IPC.  The app needs to send only short messages signifying state transistions and other info back and forth to multiple clients, one running in each user session.  The service is tied to hardware, and hence must run a single instance.

    We are now updating this app with Vista support, and I have just learned that session 0 isolation will break Windows messaging (different queues for session 0 and the user's).  My question for all of you in this forum is: which mode of IPC is the best way forward (RPC, named pipes, other), both for supporting Vista and future releases?

    Currently our client app is a VB6 legacy app, and the server app is C++. My hope is that we will still be able to get some mileage out of the client before porting to C#. The server is destined to stay C++ due to performance constraints.

    Thanks in advance for any wisdom offered.
    Friday, November 28, 2008 12:49 AM

All replies

  • I think you may want to look into the migration roadmap for your application.  What ever supported by VB6/XP is hard to make it work on Vista/7 and future server products.


    Here is what I would do...


    Build a .NET/C# wrapper layer that sits between VB6 and C++.  The interop story for .NET is very solid and has been working for years from the introduction of .NET.


    There is a proxy .NET dll (C# or VB.NET) that is installed along side of your client VB6 code.

    VB6 uses the proxy to call out.

    .NET proxy uses WCF (sockets are encapsulated in WCF) to send messages to server.

    There is a call in .NET dll (C# or VB.NET) that is installed alongside of your C++.

    .NET dll wrapper receives messages from clients and passes back to our C++ code.


    The above approach for one extends the life of your current application.

    Second you can slowly update the client code without touching your sever, one by one, until a time when the tipover occurs that .NET has more functionality then VB6 to retire VB6

    The performance by a .NET application is comparable to C++ if architected correctly (using parallel procession, highly scabale architecture, etc.,)


    Hope this helps.  If not, ask again.


    { Gaja; }


    Saturday, November 29, 2008 5:37 PM
  • Thanks Gaja.

    That is more or less what I've done (difference = C++ wrapper layer instead of C#), and it seems to work well.  Essentially, I selected named pipes to replace windows messaging.  Since the support for the win32 calls needed to make this work is shaky on vb, I wrapped the named pipe functionality in a C++ dll.  The migration path will probably have us replace both the VB and the named pipe dll with a C# app in the near future.

    As far as the question of what is the right IPC to use, the reading I did between the intial post and now all pointed to named pipes rather than RPC (probably due to not needing shared files defining the RPC calls at build time).  TCP/IP was ruled out because it would force firewall configuration in order to work, adding complexity to deployment.
    Tuesday, December 2, 2008 5:14 AM