ShaunR

You have obviously never done Agile Development proper then since it is an iterative process which starts with the design step just after requirements acquisition. It's not a fear of failure, it is a fast-track route to failure which usually ends up with the software growing like a furry mold. But anyway. It's your baby. You know best. Good luck :)

Uhuh. Seat-of-your pants design; the fastest way to project failure.

This is the standard way to do service discovery. My "Dispatcher" implementation had a "broker" that ran on the local machine to act as a gateway to services that registered with it on that machine. External (or local) clients would then contact it to discover services and it would hand off comms to the service for direct communication. It behaved as a router rather than the usual broker and meant it didn't become a bottleneck for high speed transfers. Your framework would be a good match for the above implementation since it already has all the publish, subscribe and routing feature

That's fine. I just don't like to distribute modified software that I produce where the licencing isn't explicit - which is why I asked you for one (thinking you had produced it as the original author).

OK. I've deleted the backport since the licence is indeterminate. I thought it was a library you had created.

Backported to LV2009. what's the licencing for this? Edit. Removed software due to indeterminate licencing.

The major use case for UDP I would have is for COAPS (which, incidentally, has service discovery rather than node discovery). Most node discovery methods require a known entry point (gateway, router, default port etc) and it's hard to get away from that that in a reliable way across numerous network architectures.

Very hard to do but can be done-non trivial. You will obviously have to talk to your client and find out exactly what they mean - get one of the USB sticks they use . Maybe you'll be lucky and they just mean using the LabVIEW application as the windows shell, which I do on production-line machines.

It's a compromise between convenience and security and partially solves the "trust" issue by having really, really trustworthy organisations There have been other alternatives proposed but the "trust" issue has never really been solved adequately, to date. I trust me so my certificates are great (for me). The problem with that is then distribution. SSH. which is arguably the progenitor of modern TLS, got a lot of things very right. We haven't really moved on from that model except to make a whole new business sector for the key management.

I don't think there is anything off-the-shelf, to my knowledge - Bluetooth has it's own encryption scheme. I think you are looking at using some existing TLS client/server implementation and replacing the underlying Socket connection with a Bluetooth connection. Edit: Thinking a little more. there may be another way. the caveat would be it would only work for RSA certs in this scenario, There is an example of RSA Encrytion/Decryption. You could load an x509 cert, extract the keys and use the encryption functions to encrypt the bluetooth data. This wouldn't hand

You can't outsource security If you understand that all TLS communications are interceptable by governments because of CA's, then you might also be reticent when dealing with some governments.

Congratulations. It will go great and it's a fantastic area to grow into. You won't regret it but i very much doubt you will be back at NI - it'd be a step backwards.

I wouldn't. HTTPS is just one protocol. I personally use secure websockets which is much better suited to this sort of thing IMO, Most of these use TLS though and more recently I've been playing with DTLS. If I don't use those sorts of protocols then I use SSH but that's nothing to do with what the OP is asking as it doesn't use X.509 certs (which is,as you know, just a standardised certificate format). I think that's just middle-management phrasing. I wouldn't be surprised if the device already supports this method of updating and they were told it uses X.509 certificates "for securi

This is quite a common requirement nowadays, especially within the IoT sphere. Many embedded devices come with libraries for what is called OTA (Over The Air). A multitude of devices are then monitored and configured (including software/firmware updates) via a web server. I wouldn't be surprised if the NI Systemlink uses something similar (via either HTTPS or MQTT). TLS is quite burdensome for constrained devices, specially if you have to put a webserver on the device to upload rather than using OTA libraries. To be honest. This isn't something I would use LabVIEW for. There are mu

You will have to re-architect that if you want to.... By the way. The TCPIP I described earlier is a layer to break cohesion - meaning that the VI's can be controlled by anything, in any language, including Test Stand. So if you want the "on demand" aspect, then that is probably the easiest way forward.