Named pipes Windows (OpenG implementation)

[habsilva]

I'm currently working on Named Pipes implementation and that package has nothing to do with it.

I have a demo working based solely on .NET and although it works, there are some strange performance issues that I'm trying to fix.

I believe that these issues are all related to how .NET calls are implemented in LV.

[rolfk]

Saying that it has nothing to do with named pipes is a very inaccurate statement. It uses Windows kernel objects that implement the equivalent of pipes under Unix and these objects can be named or anonymous. Even your .Net solution uses under the hood these same pipes, at least under Windows.

The Windows pipe implementation has some particular semantics that make it have a different behavior than what you would expect coming from Unix. There are also timing issues that can make it seem to behave unreliable, especially initially right after the creation. I would have expected the .Net wrapper to have improved on those semantics but it may not. Or it could be indeed related to the threading behavior in how LabVIEW invokes .Net classes.

Doing this through .Net may seem easier initially as you don’t have to deal with crashing C code in DLLs during development, but in reality adds an entire .Net intermediate layer with LabVIEW specific interface restrictions only to ultimately call the Windows API anyhow.

And there is virtually no option to control the .Net instantiation in LabVIEW. It is what it is and if the specific threading model doesn’t suit your needs you have at best an option to change an application global manifest setting that can easily conflict with other .Net assemblies that a user of your library may also want to use.

[habsilva]

I was talking about this package: JKI .NET System Exec Toolkit for LabVIEW - Download - VIPM by JKI

Which was referred to by the previous commenter and after reading the description I don't see how it is related to the use of Named Pipes for inter-process communication, especially not as it is described: "a .NET API for it that JKI has conveniently already wrapped for use in LabVIEW".

Regarding the performance issues that I see, there are several on my system:

1. overhead is not insignificant: connecting to a named pipe, sending a request, getting an answer in a new named pipe, closing all connections again, takes 0.3 ms at best and up to 0.8 ms if concurrent requests are coming through

2. UI events like dragging LV windows or scrolling delays immensely the execution time (several milliseconds)

3. If LV is not running in the foreground, the delay can become quite significant (roughly additional >5 milliseconds per request, but not always??)

So, it would be great if the performance could be more predictable and not so dependent on what is going on in the UI thread or if the app is in the foreground or not.

Regards,

Habil

[rolfk]

---

@habsilva wrote:

So, it would be great if the performance could be more predictable and not so dependent on what is going on in the UI thread or if the app is in the foreground or not.

---

Have you tried the OpenG library? I haven't really made any benchmarks with it but that is as close to the Windows API as you possibly can get. Faster than what is possible there is not an option unless you write a kernel driver and communicate directly with the kernel object space.

[habsilva]

I can't find the library.

I've checked here: OpenG Toolkit - Browse /lib_lvpipe/1.x at SourceForge.net but it's empty. Any other place I can find it? (I've also installed latest OpenG Toolkit from VIPM)

From your reply I take it that you've compiled the code that manages the pipes into a DLL, and this is what gets called from the LV VI's, correct?

My implementation uses .NET nodes which from your experience is thus less performant.

Other divergence between implementation is that I'm using NamedPipeClientStream and NamedPipeServerStream classes instead of the lower-level Pipes class: How to: Use Named Pipes for Network Interprocess Communication - .NET | Microsoft Learn

Habil

[rolfk]

Yes my code uses directly the Win32 API, which your .Net interface ultimately does too. It just adds an entire intermediate .Net dinosaur, with its own runtime footprint, threading requirements and LabVIEW .Net interface limitations to the picture.

The CVS tree on Sourceforge is the original source code from the initial OpenG initiative. CVS was better than no source code control, but pretty painful in comparison with SubVersion or Mercurial. So when Sourceforge started to support SubVersion, the OpenG project soon moved to use that instead of CVS.

The OpenG Pipe library was a side project of mine and didn't make it into the original CVS version on Sourceforge. Instead you can find it under https://sourceforge.net/p/opengtoolkit/svn/HEAD/tree/trunk/lvpipe/