Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
NetworkAddressInUse
09-05-2012, 12:08 PM
Post: #1
NetworkAddressInUse
With a recent build of ohNet, I'm getting a NetworkAddressInUse exception when trying to start two instances of the device stack in different processes on the same Linux machine. This didn't happen on an older (January) build.

I've looked through the older and newer code to try to find what's causing the difference, but I haven't found anything yet. Any pointers would be much appreciated.
Find all posts by this user
09-05-2012, 01:04 PM
Post: #2
RE: NetworkAddressInUse
(09-05-2012 12:08 PM)simoncn Wrote:  With a recent build of ohNet, I'm getting a NetworkAddressInUse exception when trying to start two instances of the device stack in different processes on the same Linux machine. This didn't happen on an older (January) build.

I've looked through the older and newer code to try to find what's causing the difference, but I haven't found anything yet. Any pointers would be much appreciated.

The device stack changed to set its web server to run on port 55178 by default. If you run two instances, the second will find its device server fails to start because this port is in use by the first ohNet instance.

You can override this by using InitParams.setDvServerPort to select a different port. If you set this to 0 as standard, the OS will select a free port for you.
Find all posts by this user
09-05-2012, 08:40 PM
Post: #3
RE: NetworkAddressInUse
Thanks for the quick response. I looked for this in InitParams.java and I found the following comment:

The default value is 0 (meaning that the OS will assign a port). You should question your design if you need to use this.

It looks like the first part of the comment should be changed, as the default value is now 55178 rather than 0. I'm not sure how to interpret the second part of the comment in the light of the new choice of default value. Sad
Find all posts by this user
10-05-2012, 07:49 AM
Post: #4
RE: NetworkAddressInUse
(09-05-2012 08:40 PM)simoncn Wrote:  It looks like the first part of the comment should be changed, as the default value is now 55178 rather than 0. I'm not sure how to interpret the second part of the comment in the light of the new choice of default value. Sad

I've tidied this plus some related comments to simply state the default port now. (The questionable design comments may have been valid when we had the OS select all ports but should have been removed when we gave in to requests from folks who're used to hard-coding all ports for server applications.)
Find all posts by this user
10-05-2012, 09:49 AM
Post: #5
RE: NetworkAddressInUse
I can see why people would prefer a hard-coded port number, but I think it will cause problems if this number is assigned by the ohNet device stack. This is because different ohNet applications would share the same hard-coded port number, and wouldn't be able to coexist with each other on the same Linux machine.

The usual solution is for each application to choose and document the hard-coded port number that it uses, and provide a configuration option for changing this. This would require the application to pass this port number to ohNet using the InitParams API. I'd expect this to be the normal case for a well-designed application.

MinimServer doesn't do this. Instead, it has its own internal web server because the web server in ohNet didn't support HTTP GET with byte ranges for partial content. MinimServer uses the ohNet web server for the icon URLs in device.xml, and a variable port number is OK for that.
Find all posts by this user
10-05-2012, 10:04 AM
Post: #6
RE: NetworkAddressInUse
(10-05-2012 09:49 AM)simoncn Wrote:  MinimServer doesn't do this. Instead, it has its own internal web server because the web server in ohNet didn't support HTTP GET with byte ranges for partial content. MinimServer uses the ohNet web server for the icon URLs in device.xml, and a variable port number is OK for that.

I take it you also use the ohNet server for action invocations and subscriptions? It'd require a fair bit of code if you're needing to duplicate these...
Find all posts by this user
10-05-2012, 10:10 AM
Post: #7
RE: NetworkAddressInUse
(10-05-2012 10:04 AM)simonc Wrote:  I take it you also use the ohNet server for action invocations and subscriptions? It'd require a fair bit of code if you're needing to duplicate these...

Yes, although I hadn't thought of that as being a web server. Smile There's no problem (I presume) with having a variable port number for these.
Find all posts by this user
10-05-2012, 10:12 AM
Post: #8
RE: NetworkAddressInUse
(10-05-2012 10:10 AM)simoncn Wrote:  
(10-05-2012 10:04 AM)simonc Wrote:  I take it you also use the ohNet server for action invocations and subscriptions? It'd require a fair bit of code if you're needing to duplicate these...
Yes, although I hadn't thought of that as being a web server. Smile There's no problem (I presume) with having a variable port number for these.

No problem at all. The wording of your earlier post just had me wondering whether you'd needed to re-create all handling of POST, SUBSCRIBE etc methods. I'm glad to find you haven't!
Find all posts by this user
30-05-2012, 03:59 PM
Post: #9
RE: NetworkAddressInUse
(10-05-2012 09:49 AM)simoncn Wrote:  I can see why people would prefer a hard-coded port number, but I think it will cause problems if this number is assigned by the ohNet device stack. This is because different ohNet applications would share the same hard-coded port number, and wouldn't be able to coexist with each other on the same Linux machine.

The usual solution is for each application to choose and document the hard-coded port number that it uses, and provide a configuration option for changing this. This would require the application to pass this port number to ohNet using the InitParams API. I'd expect this to be the normal case for a well-designed application.

Having been bitten by the type of problem you predicted, we've now reverted to using port 0 (i.e. having the host OS select an arbitrary free port for us) by default. Client programs can still select their own hard-coded port using InitParams.
Find all posts by this user
30-05-2012, 08:35 PM
Post: #10
RE: NetworkAddressInUse
(30-05-2012 03:59 PM)simonc Wrote:  Having been bitten by the type of problem you predicted, we've now reverted to using port 0 (i.e. having the host OS select an arbitrary free port for us) by default. Client programs can still select their own hard-coded port using InitParams.

Thanks for this information. The new scheme is a sensible compromise that provides a "safe" default and also allows applications to control their port allocation if needed. Smile
Find all posts by this user


Forum Jump: