Hi Burkhard, << Is my assumption "I need a seperate process for the C++ library to inhibit a potential crash of my .NET client" correct? >>
Yes. << If yes: I'm not sure wether mail slots are the right decision regarding stability and performance. >> Mailslots are not a good option to consider; most folks use Named Pipes for this king of thing. (Analogy: Named Pipes are to Mailslots as TCP is to UDP.) Like UDP, Mailslots are almost completely insecure -- listening on a Mailslot is like opening a backdoor to anyone who cares to go looking for it. But the default security descriptor on a Named Pipe is also way too loose for casual IPC... as this is all on the same machine, communication via shared-memory sections (a.k.a. "memory mapped files") would be much faster, and a *lot* more secure. But it's a pretty raw approach: you'd need to write some grungy memory-management code, and probably employ some Win32 events and/or mutexes to properly synchronize access to the shared-memory resource. Some .NET wrappers for shared-memory exist; I've not used any of them enough to give an endorsement, but Rich Blewett's work is certainly worth a look: http://staff.develop.com/richardb/weblog/permalink.aspx/32c3abfb-bac9-4e19-b bc5-39ca338d906d << Constructing a DOM tree with a lot of small objects is *very* slow. >> Avoid DOM like the plague, for this kind of thing -- both on the reading- and writing-side of things. If you care about perf at all, at some point you're going to have to write a few lines of custom code to stream the XML in/out via XmlTextReader/Writer (and some sort of SAX implementation, in C++). IMHO, 50MB is getting into the "ridiculously large" range for IPC, over any medium. That's, like, and entire audio cd encoded at 96kbps! I'd look for a way to break this up into smaller XML messages (if that makes sense) or else abandon XML altogether and go to a binary format. I'm not sure how you might easily concoct a binary format for both the managed and unmanaged sides, but 50MB is an awful lot of angle-brackets to parse through... HTH, -S -----Original Message----- From: Burkhard Perkens-Golomb [mailto:[EMAIL PROTECTED] Sent: Sunday, November 16, 2003 04:36 Subject: How to comunicate from .NET with an older C++ library? Hi, I'm writing a .NET smart client that should communicate with an older C++ library ("older" means: written with something prior .NET, perhaps VS 6.0). If the C++ library crashes my .NET client mustn't crash too. So the idea is to run .NET client and C++ library in different processes. These processes have to communicate. Some constraints: The people who have to deploy the whole application don't like COM because deployment with COM is much more difficult than without (so they say). Porting the older C++ library to managed code is currently not an option. Now we have the following working solution via mail slots as middleware (easy to deploy: they're already there) and with XML as protocol (easy to use with .NET resp. MSXML): - The .NET Client and the C++ library (library wrapped in a thin C++ application by ourself) are running in two different processes. - If the .NET client wants to sent a message to the C++ application the client serializes its data into XML. - The data is sent via a mail slot to the C++ application. - The C++ application deserializes the XML. - The C++ library is called. - With the result of the call the C++ application constructs a DOM tree. - The DOM is serialized to XML. - The XML is sent back via mail slot to the .NET client. - The .NET client deserializes the XML. Some questions and problems: Is my assumption "I need a seperate process for the C++ library to inhibit a potential crash of my .NET client" correct? If yes: I'm not sure wether mail slots are the right decision regarding stability and performance. Regarding XML: The result of a C++ library call can consist of a lot of small objects and can result in up to 50MB XML text. Constructing a DOM tree with a lot of small objects is *very* slow. Of course I can define my own communication protocol but in .NET handling of XML and (de-)serialization is very easy. Can I make the DOM construction faster? Any other option to serialize the C++ data to XML (besides writing XML "by hand")? Any hints and/or tips? Thanks in advance, Burkhard -- Burkhard Perkens-Golomb mailto: [EMAIL PROTECTED] sd&m AG http://www.sdm.de software design & management AG Carl-Wery-Str. 42, 81739 Muenchen, Germany Tel +49 89 63812-398, Fax -410 Tel Home +49 89 66 00 09 61 =================================== This list is hosted by DevelopMentor. http://www.develop.com Some .NET courses you may be interested in: Guerrilla ASP.NET, 10 Nov 2003 in London and 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnet Guerrilla .NET, 8 Dec 2003, in Los Angeles http://www.develop.com/courses/gdotnet View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in: Guerrilla ASP.NET, 10 Nov 2003 in London and 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnet Guerrilla .NET, 8 Dec 2003, in Los Angeles http://www.develop.com/courses/gdotnet View archives and manage your subscription(s) at http://discuss.develop.com
