gmail (revisited?)

[Jolt]

Hello All,

I know this has been a topic (several times) before but does anyone know of a way to access (send) email through a service such as gmail from a non-windows machine (i.e. RT) assuming that the equipment is sitting on a network without an email server?

From previous discussions it seems almost hopeless and unfortunately I am definitely not nearly competent enough in the more detailed HTTP, TLS, etc. issues to even attempt to offer my own solution.

I apologize if this post is just beating a dead horse - I’m just not used to the idea that something like this does not have a (relatively easy) solution in LV...

Cheers,

Jolt

[Antoine Chalons]

Hi,

There is an example using .NET on NI Community, I can't give you the link right now but i think if you type 'site:ni.com gmail' in the google search bar you should fined it.

EDIT : here it is http://decibel.ni.com/content/docs/DOC-2401

Hope this helps

[Rolf Kalbermatter]

Hi,

There is an example using .NET on NI Community, I can't give you the link right now but i think if you type 'site:ni.com gmail' in the google search bar you should fined it.

EDIT : here it is http://decibel.ni.co...t/docs/DOC-2401

Hope this helps

There are different solutions but all have the disadvantage that making them work on non desktop systems might be a lot of hassle or simply impossible.

1) Use of stunnel or a similar SSL proxy. This sits in between your application and the actual SSL enabled service. You communicate to the stunnel process/service through unencrypted protocols (so your stunnel proxy should be installed on the internal network) such as HTTP or POP/SMTP and stunnel converts that protocol to its corresponding SSL enabled protocol and vice versa. If you have the ability to install stunnel on an internal desktop PC you do not even have to try to get stunnel to work on your RT system, which I assume would be a serious problem although being open source I'm sure it could be made to compile and run there (but it uses OpenSSL and that can be very tricky to port to unsupported platforms).

I've done tests with stunnel under Windows and got a simple LabVIEW HTTP VI to communicate properly to an HTTPS server by using the stunnel process as HTTP proxy with SSL encryption. I'm not sure if this is indicative to HTTPS support in general as I didn't test many HTTPS services with this.

2) Using the OpenG Pipe library you could call a tool like plink or putty and redirect its IO streams to LabVIEW, letting it perform the actual SSL encryption and handshaking. This pipe library works fairly well but has some quirks sometimes under some situation that I haven't found the time and interest to debug yet and unless I'm going to need this library in a commercial project where these quirks are an issue it's not likely that I will spend much more time on it. The current state is that it mostly works on Windows, has been prepared to work on Linux and Mac OSX but without being tested yet, and would be a challenge to port to RT systems.

3) I've been working on a Network nodes (TCP/UDP) replacement library that includes TLS/SSL support through use of the OpenSSL library. It is still Windows only and has a few problems that prevent me from making it available for broader consumption. Also it is fairly substantial work so I'm not sure about how to make it available at all. A free open source distribution sounds a bit to much like giving it away.

The idea of that library would be that it basically simply replaces the native LabVIEW network nodes as drop in replacement, providing an additional parameter to initialize the SSL operation if so desired. Additional goodies would be optional IPv6 support if available on the platform and some extra functionality such as optional synchronous write operation. The current state is that it mostly works but it hangs always when trying to shutdown LabVIEW after having done one or more SSL related communication because the OpenSSL library seems to somehow hook into system calls that make loading/unloading it dynamically a big challenge.

Porting this library to Linux and Mac OSX should be fairly straight forward, and porting it to RT targets albeit probably not as trivial, should be also possible.