Rolf Kalbermatter

Yes since LabVIEW 2020 or 2021 one would need an .ipk to be able to install software on an RT system. I haven't yet come to create such a beast but am working on a general update to the library currently. It's just that there are so many other things to tackle too. 😎

It depends what you consider a lot harder. The basic function gets you a pointer sized slot to store whatever you want. If you manage allocation/deallocation of that data structure yourself you can get away with NULL callback parameters and only need the set and get functions to store the pointer and get it out back.

If you absolutely want to store information on a session level, you could use the CRYPTO_get_ex_new_index(CRYPTO_EX_INDEX_SSL/SSL_CTX, 0, "Name", NULL, NULL, NULL); Then store the information on the ssl or ctx with SSL_set_ex_data() or SSL_CTX_set_ex_data(). Retrieve it with the according SSL_get_ex_data()/SSL_CTX_get_ex_data().

The way I saw it done in some example code was to generate an application global random secret on first use and use that as key for a HMAC over the actual connection peer address (binary address + port number). BIO_dgram_get_peer(SSL_get_rbio(ssl), &peer); Then use the HMAC result as cookie. Yes it is not super safe as an attacker could learn the key eventually if he tries to attack the server long enough (and knows that that key for the cookie generation is actually constant) but if you don't use an abnormally bad HMAC hash code (SHA256 should be enough), it should be pretty safe.

Which version of OpenSSL is that in? TLS 1.0. and 1.1 are/were scheduled to be depreciated for quite some time already. And it seems by default to be disabled in OpenSSL 1.1(.1). https://github.com/SoftEtherVPN/SoftEtherVPN/issues/1358

One of Emerson's critique point about the NI strategy was its above market average spending in R&D. While LabVIEW development is only a small part of that spending, it does not bode well for the future of LabVIEW.

Quite a bit late to the party but that information is only partly correct! 😀 LabVIEW 2.x and I believe even 3.x used actually an unsigned 32-bit integer for timestamps. Yes it had no fractional seconds and that was a legacy from the Macintosh API.

I think the cookies callbacks are not the problem. It's simply a "magic" value being generated and included in the encrypted hello response and the client then copies that back in its subsequent messages to verify that it is itself and not some intermediate adversary that intercepted the messages. So the generation and verification is done on the same side and there is no interoperability issue as the cookie is treated as an opaque binary blob by all intermediate channels. Why they even require callbacks to be installed rather than providing a default mechanism itself (that could be overridden by a callback if so desired) is a bit beyond me however.

Welcome in LabVIEW scripting. I'm pretty sure it is doable, and I'm even more sure that it is a lot of work to do right. But the tools are there for you to do it. 😀

I can clearly see what you are talking about. DTLS is a second class citizen as you have to indeed do BIO trickery. For TLS OpenSSL has convenient wrapper functions. However I appreciate the OpenSSL developers troubles in trying to shove an intermediate layer into the socket interface, and to make matters worse try to get it to work on multiple platforms While both Linux sockets and WinSock are in principle based on the BSD sockets and this works surprisingly smooth on all these platforms with the same source code for basic TCP and even UDP sockets, things start to get nasty soon when trying to do advanced things such as what OpenSSL needs to do. Under Windows this should be really solved with a socket filter driver that can be installed into WinSock but that is considerably different to how things would be done on BSD and pretty much impossible on Linux without integrating it in the kernel or trying to hack it into pcap. OpenSSL is clearly a compromise. The alternative would be OS specific protocol filter drivers and there are very few of them and none that supports multiple OSes.

I love number 7). 😀 Serves you right if you used DAQmx Express VIs! The recompiling of VIs is not enough punishment for such a crime! 😎

Technically very much so. But it is an effort to support multiple platforms. If you intend to commit some backing to Shaun/LVS-Tools I’m fairly convinced he can come up with some proposal. And if he wants to I can even offer some support. But I’m very sure he can do it also alone if there is some incentive. 😀

Well. It's more likely a very resounding "I have no idea if I'm ever going to need that. For now I just refrain from commenting on the matter!" 😎

Ok, this is not gonna work like this. The sample code you show uses gobjects to start its own loop and do event handling all through it. gobjects is basically a glib task handling system. It's in fact its own execution system and is for instance used as base of gtk and in extension GNOME. But these are build on top of gobjects. LabVIEW has its own execution system and marrying two of them together is a major exercise in coding. In fact it is almost never done since it is so difficult to do right. You will need to try to find the lower level interface of this aravis library. It will require you to call lots of functions with the arv_ prefix and similar, but you must avoid anything that starts with g_. Basically you would need to start writing something like IMAQdx with many of its functions but instead of calling into IMAQdx you call into the arvis library. It's doable but not for the faint of heart. Basically trying to interface to image acquisition hardware and libraries is very difficult. Always! And there is a reason these libraries cost money and there are very few freebies here. The Arvis library itself seems to be free. Its LGPL licensing can be problematic for anyone wanting to use it for a commercial program. And while it states to be LGPL there are actually files in there that state to be GPL. So licensing is not completely clear cut there. Incorporating GPL software in anything other than GPL software is basically impossible.

I'm not sure you did a service here. Trying to do callback functions through Windows messages is both not straight forward and in fact the master class of interfacing to a shared library. Considering that his shared libraries are .so files, he also obviously is not on Windows but Linux,

Show your code! It's not the meaning that you simply export that main function and call it! you need to take it apart and export separate functions for at least Open, Grab and Close.

I would agree that it doesn't quite look "monsterly" but there seems to be some cross contamination between simple configuration stuff and actual test specs or data results or whatever it is. If you talk class it would only be an improvement if you start about taking these apart into more fine grained classes. Some manager class that then can contain the individual test classes. Otherwise you simply replace a somewhat unwieldy cluster through a similar unwieldy class. And that is no real improvement at all. A class simply is a cluster on some steroids anyhow. (Yes I know it is a sloppy statement but for many purposes it is quite accurate).

The best approach would be to take that code and make your own shared library from it. Export functions to Open the device, Grab Images and Close the device. Basically you do not want an executable with a main function but instead you want a shared library that seperates those indvidual functions out. Why not call the underlying library directly through the Call Library Node you may ask. Because you have a callback function in there! It may be possible otherwise but that callback really is a no go for direct LabVIEW interfacing.

Most likely because of its use of DTLS. 😁 OpenSSL's support of this was fairly "flaky" back when I did my Network library. Many problems were surrounding it, some of them were actually kind of unfixable with the DTLS standard at that time. Now this was around OpenSSL 0.9.6 or so, so I would assume that a lot has changed since. And yes I got it to work, but only had done minimum testing with it. It was clear that more extended use of it would sooner or later bring out troubles with it. Some for sure in my interpretation of the OpenSSL API at that time, but some also unfixable for me without changing OpenSSL itself.

It's just the label of the control inside the array shell. Usually invisible but certainly can have a label. And label oddness with VIMs is not that strange. They seem to have some trouble to track all the label things properly across multiple types and compared to the actual datatype it's really just cosmetics. 😁

Not yet 😁

But LabVIEW for Linux (and Mac and any other non-Windows version) has no .Net functionality, no matter if you try to use Mono, or .Net Core.

I haven't looked at MQTT but this kind of ID is usually only really used to match responses to the request and/or verify that you got the right response. It should not contain any crypto relevant value, so I would not expect it to matter. More important would be that you can reasonably guarantee that your random generator never will result in the same ID being returned within a small time window, as that makes the whole purpose of being able to match the response to the request pretty difficult. In that sense a monotonically increasing ID that eventually wraps around is actually more useful than a true random ID. Usually the client generates the ID and sends it with the request. The server simply copies it into the response without doing anything else. The client can then verify that the received response is actually for the sent out request and not some other stray request. In a connection based protocol using TCP/IP, this is usually kind of superfluous but for UDP or serial port communication it can be useful.

A LabVIEW handle is however: typedef struct { int32_t status; double value[]; } DataRecord, *DataPtr, **DataHdl; ...... ...... DataHdl handle = NULL; The important part is the double pointer in front of the handle datatype. The array declaration of the value element is more a cosmetical thing and may not work like this with your compiler. You may have to add a 0 or even 1 in the brackets to let your compiler accept it. It has no real influence on the code unless you try to use sizeof(DataRecord) somewhere, which is not recommended.

Unfortunately that is true. LabVIEW wants to link to object methods by MethodID (a 32-bit number that has to be changed when the method signature changes). If LabVIEW would instead use the MethodName (which it also stores in the Method Node, it could adapt to changes in methods as long as those changes only affect optional parameters). With access to the LabVIEW source code this would have been a change of a few hours, but with ActiveX being anyhow legacy now, even that effort is of course to much to spend.