Multiple Web Services on same host (and port)

[Neil Pate]

Just tried out something that I would have expected should work, but doesn't.

 

As a Web Service is identified by a name I would have expected I could run several of them on the same system with the same port. This does not work, whichever service is started first works, the other does not. Moving the second Web Service to a different port works properly.

 

Am I being unreasonable with my expectations here? I know enough about ports to be dangerous but that is about all, is there some underlying restriction of the OS (Windows in this instance) that only allows one application to bind onto a port?

 

The reason I am doing this is to try and create a test environment so that I do not affect my production Web Service application.

 

 

[Neil Pate]

This NI document confirms my suspicions.

[Rolf Kalbermatter]

This NI document confirms my suspicions.

Think about it. How should the OS socket driver decide to whom to send incoming data if more than one process was allowed to bind to the same port? Another related issue would be that anyone could then bind to any port and eavesdrop the communication of another application without the need for a promiscuous capture driver involved, which needs administrator privileges to get installed and started, so if an attacker has those privileges you have much bigger problems than listening on a network communication.

[Neil Pate]

Think about it. How should the OS socket driver decide to whom to send incoming data if more than one process was allowed to bind to the same port? Another related issue would be that anyone could then bind to any port and eavesdrop the communication of another application without the need for a promiscuous capture driver involved, which needs administrator privileges to get installed and started, so if an attacker has those privileges you have much bigger problems than listening on a network communication.

 

Sure, your comments pretty much echo my internal dialogue. I can't figure out what the point is then of naming the web service? If all traffic to the IP address and port gets directed to the single instance of the web service why bother identifying it by name?

[Rolf Kalbermatter]

Sure, your comments pretty much echo my internal dialogue. I can't figure out what the point is then of naming the web service? If all traffic to the IP address and port gets directed to the single instance of the web service why bother identifying it by name?

 

LabVIEW allows in its TCP/IP functions to specify a service name instead of a port number. This also works for the server side. So when you start up a server (with Create Listener) and specify a service name instead of a port number, the function will open an arbitrary port that is not yet used and register this port number together with the service name in the local NI service name registry (a little network service running on the local computer). Any client does not have to know the port number of the service (which can change between invocations) but only its service name. Not sure if webservices also make use of this feature, but it is clear that a meaningful service name is much easier to remember than an arbitrary port number.

[Neil Pate]

In LabVIEW (and perhaps all Web Services, I am not sure here) the connection string is in the form:

 

host_address:port/WebServiceName/QueryString

 

so it just seems to me that something is redundant here.

 

You can infact have multiple Web Services on the same port when running in the IDE, but then I suppose there is only a single application (LabVIEW.exe) that is bound to the port. However as soon as you have built applications this paradigm breaks.

[ShaunR]

You can infact have multiple Web Services on the same port when running in the IDE, but then I suppose there is only a single application (LabVIEW.exe) that is bound to the port. However as soon as you have built applications this paradigm breaks.

 

Yes. you can have multiple services. but you can only have one listener. You need a connection handler to offload the endpoints and I guess the NI webserver doesn't do that (never used it, so don't know for sure). It is, however, trivial to write your own.

[Neil Pate]

Yes. you can have multiple services. but you can only have one listener. You need a connection handler to offload the endpoints and I guess the NI webserver doesn't do that (never used it, so don't know for sure). It is, however, trivial to write your own.

I think this is actually possible in the IDE, but not in built applications.

[ShaunR]

I think this is actually possible in the IDE, but not in built applications.

Then how does this work in multiple browser windows?

You can run it yourself (as a built application) by downloading from the link in my signature.

 

Or even play with Dispatcher in th Code repository and buld an exe out of it.

Edited April 14, 2014 by ShaunR

[JackDunaway]

It's helpful to think of a "LabVIEW Web Service" as not a monolith -- but rather, a single web server capable of routing requests to handlers using URL routing rules. There's always just that one web server in your deployment environment, and this server can even bind to multiple ports simultaneously for incoming requests (nominally, 80 for HTTP and/or 443 for HTTPS), which then routes those requests to discrete handlers. The routing rules provide the level of indirection you desire between the web server endpoint and the backend handlers.

[dremas]

Along these lines, has anyone been able to set the port through command line arguments? I want to run multiple instances of the same application on a pc. If the port must be part of the build spec, then I'll have to create separate executables for each port I want to enable :-(

[dremas]

It turns out that the port is in niwebserver.conf, which can be loaded programmatically in the code. You just need two config files, and you can change the port from a Property Node: http://zone.ni.com/reference/en-XX/help/371361G-01/lvprop/app_web_server_configure/