multiple LV instances, web server cannot start, port already in use

[Enrico_Segre]

Hi there,

I have a general question about webserving VIs in case either

a) multiple instances of the LV development environment are running (this is possible in windows XP for instance when "switch users" is allowed and each user launches LV)

b) multiple compiled LV executables are run by the same user

c) any mixture of the two above

I have an application case when either of the three above would be a very good solution, was not for the problem encountered. Say, b): the user is given two deployed executables, and can decide to run either or both concurrently. Moreover, I want these applications to be visible on the web, so they are compiled with the webserver turned on, default settings.

The problem I've seen (LV8.5.1, winXp for sure, but I think I've seen it as well in linux and other versions as well) is that each new instance of the LV engine tries to get hold of the tcp port (default 80), so that all instances beyond the first complain about "The Web Server cannot start. Is the Web Server port already in use?"

While I can understand the origin of the message, and found some posts on the forums somehow related to it, I don't like it too much. 

I could think only of two workarounds here: 1) set different web server ports for each LV instance, and instruct the remote users to direct their browsers to a webserver:port link to access each VI; 2) run all the applications from the same instance of the LV dev system. The latter is not so convenient for me, due to conflicts in global VIs between all instances of the applications [compiling executables IS a way to privatize memory spaces in this case, AND global variables are imho well justified for the fairly complex application I have in mind here].

Is there a third, more elegant solution perhaps, which I'm missing?

Thanks, Enrico

[NathanK]

I don't know what you could do about multiple dev environments that want to use the same port.

For the built executables you could leave the web server off by default and then turn it on in your main VI programmatically and if there is an error try a different port. Then the main VI could indicate to the user what port they should connect to.

"While I can understand the origin of the message, and found some posts on the forums somehow related to it, I don't like it too much."

I don't like it either. Putting up extra dialogs is generally discouraged. Unfortunately in the case of the web server we didn't have any other good place to show the error and we couldn't just let the web server fail to start without telling the user somehow

What is it in particular that you dislike about the message?

How would you like LabVIEW to behave in this case?

Nathan

[Enrico_Segre]

---

NathanK wrote:

What is it in particular that you dislike about the message?

How would you like LabVIEW to behave in this case?

No problem with the message, but I'd just be very happy if a single web server would serve all my instances of the executables on the same port. I.e., if 2.exe is open and wants to start another server on the same port used already by 1.exe, then 2.exe becomes served by the server already opened. Am I demanding too much? Am I missing some necessary logic?

At the moment, anyway, I'm stuck with the vi being served correctly, but not the compiled application, and I can't figure out why. It's LV8.5.1, and yes, I have in the .ini

WebServer.DirectoryIndex="index.htm"
WebServer.LogPath=C:\Program Files\National Instruments\LabVIEW 8.5\www.log
WebServer.MimeTypes="htm;text/html;gif;image/gif;jpg;image/jpeg;png;image/png;txt;text/plain;html;text/html;jpeg;image/jpeg;css;text/css;llb;application/x-labview-llb;vi;application/x-labview-vi;doc;application/msword;dot;application/msword;bin;application/octet-stream;exe;application/octet-stream;rtf;application/rtf;pdf;application/pdf;ai;application/postscript;eps;application/postscript;ps;application/postscript;csh;application/x-csh;gtar;application/x-gtar;gz;application/x-gz;sh;application/x-sh;tar;application/x-tar;zip;application/zip;hqx;application/mac-binhex40;ua;audio/basic;wav;audio/wav;tif;image/tiff;tiff;image/tiff;xbm;image/x-xbitmap;rtx;text/richtext;qt;video/quicktime;mov;video/quicktime;avi;video/x-msvideo;movie;video/x-sgi-movie;aif;audio/aif;aifc;audio/aif;aiff;audio/aif;aim;application/x-aim;dif;video/x-dv;div;video/x-dv;js;application/x-javascript;pntg;image/x-macpaint;xlb;application/vnd.ms-excel;xls;application/vnd.ms-excel;ppa;application/vnd.ms-powerpoint;ppt;application/vnd.ms-powerpoint;pps;application/vnd.ms-powerpoint;pot;application/vnd.ms-powerpoint;pwz;application/vnd.ms-powerpoint;mid;audio/mid;midi;audio/mid;enc;video/mpeg;m1v;video/mpeg;mp2;video/mpeg;mpa;video/mpeg;mpe;video/mpeg;mpeg;video/mpeg;mpg;video/mpeg;psd;image/x-photoshop;bmp;image/bmp;pic;image/pic;ra;audio/vnd.rn-realaudio;rf;image/vnd.rf-realflash;rm;application/vnd.rn-realmedia;rp;image/vnd.rn-realpix;ram;audio/x-pn-realaudio;rmm;audio/x-pn-realaudio;rnx;application/vnd.rn-realplayer;rt;text/vnd.rn-realtext;rv;video/vnd.rn-realvideo;smi;application/smil;ssm;application/streamingmedia;sithqx;application/mac-binhex40;sit;application/x-stuffit"
WebServer.Port=80  [### or 8000]
WebServer.Enabled=True
WebServer.RootPath=C:\Program Files\National Instruments\LabVIEW 8.5\www
WebServer.TcpAccess="c+*"
WebServer.ViAccess="+*"

 [hints welcome here]. That is, I'm at the moment unable to use even my workaround 1 above.

Enrico

[Enrico_Segre]

---

Enrico Segre wrote:

---

At the moment, anyway, I'm stuck with the vi being served correctly, but not the compiled application, and I can't figure out why

....

 [hints welcome here]. That is, I'm at the moment unable to use even my workaround 1 above.

Enrico

---

This one solved, I merely forgot to enable the ports in the windows firewall. One step forward, at least.

[NathanK]

Glad to hear that you solved the issue with changing the port.

---

I.e., if 2.exe is open and wants to start another server on the same port used already by 1.exe, then 2.exe becomes served by the server already opened. Am I demanding too much?

---

 Yes. Yes you are. 🙂

I can't think of a good way for LabVIEW to know that 1.exe and 2.exe are related to one another. It isn't enough that they are both LabVIEW web servers- 2.exe might be from some other company for example. We could put in some way to configure your exes so that 1.exe would proxy to 2.exe but this would certainly be more complicated than just changing the port for 2.exe.