Jump to content

Multiple Web Services on same host (and port)


Recommended Posts

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.

 

 

Link to comment
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.

Link to comment
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?

Link to comment
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.

Link to comment

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.

Link to comment
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.

Link to comment
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.

Link to comment

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.

Link to comment
  • 2 months later...

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 :-(

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.