Leaderboard

For anyone listening, here is how to send messages (or any other data type) via a TCP connection. Basically, one just puts a message length at front and reads that first. TCP handles making sure you never miss a byte, so there is no need to identify data boundaries.

Because it is far more pragmatic to remote into (and send data out of) devices in offshore oil rigs than it is to send a survival trained engineer via helicopter.

Even on a NI Linux RT cRIO device I would probably offload the VPN handling to an embedded router that sits between the outside network and the local cRIO network. And of course use a VPN server on the remote side of the customers network and not a cloud based one. With your example of an oil rig, I would suppose they already use VPN protected links between offshore and land side, if they have any network connection at all.

My english isn't good, but I'll try except the general tricks with Windows, firewalls etÑ: 1. Close all port for input connections. 2. Your remoted PC or cRio is the client. He only sends the requests to the server via HTTPs. 3. In my package I use the sign variable which is the package encoded with the AES encryption. There is static key and variable key. The variable key is the units ID. The not-encoded ID also presents in the package. for example: <package> <ID>123</ID> <data>anydata</data> <sign>asdjf;lkasjdf;lkas</sign> </package> sign = encrypt(package-sign) 4. So first of all the server check is there such unit ID in the database. If it is - we check the sign from the package. And only if everything is OK - parsing the package. 5. In one of my projects I also use my own SSL sertificates.

Not so fast, friend ... First, can you provide some representative examples of say, some of the more complex functions you intend to invoke from LabVIEW? Also, it would help to know some basic timing diagrams and synchronization requirements between lv and the shared lib; e.g., are function callbacks spray-and-pray, or does the library routine invoking them expect synchronous return values or manipulations of arguments passed as pointers? Ideally, provide a header file, or a good smattering of function declarations, anonymizing variable names into `a`, `b`, etc. if necessary. Also, any cross-platform requirements? Is the DLL C calling convention? a CLR assembly? (obviously not, but `.dll` alone does not constrain how to proceed here) You now have three people tuned into this thread who can potentially save you from less-obvious but even-more-insidious (because, they're not obvious) problems that potentially lie ahead beyond just function pointers.