#770 new enhancement

webapi: listen on multiple interfaces/ports

Reported by: swillden Owned by:
Priority: major Milestone: eventually
Component: code-frontend-web Version: 1.4.1
Keywords: http port Cc:
Launchpad Bug:

Description

The primary use case is to allow a node to be accessed via either HTTP or HTTPS. Other uses might be for a multihomed host to listen on different ports on each interface, or to listen on a subset of the available interfaces (but more than one), etc.

Attachments (1)

multi-listen.dpatch (34.2 KB) - added by swillden at 2009-07-29T06:14:14Z.
Very simple multi-listener patch

Download all attachments as: .zip

Change History (6)

comment:1 Changed at 2009-07-28T22:01:16Z by warner

  • Component changed from code-network to code-nodeadmin

As discussed in email, let's use a comma-separated list of strports specifications in web.port=, since I think commas are not normally a part of strports strings.

Shawn pointed out that it's not clear what to do with the BASEDIR/node.url file that is written out at node startup when there are multiple web ports. I'd suggest only writing out the URL for the first web.port specification, and documenting the config value to encourage folks to put the cheapest locally-reachable port (e.g. non-encrypted localhost HTTP) as the first value.

comment:2 Changed at 2009-07-28T22:51:20Z by swillden

I've attached a very simple patch that implements multi-port listening. It still needs unit tests, but as I indicated on the mailing list I'm not sure where to implement those. If someone who knows the test infrastructure could give me some guidance, I'd be glad to write some tests.

Changed at 2009-07-29T06:14:14Z by swillden

Very simple multi-listener patch

comment:3 Changed at 2009-08-07T05:43:50Z by warner

the patch looks good. testing it is a challenge.. the most obvious approach would be to start a client listening on two separate ports, then make sure that you can hit the welcome page over both of them. But we don't want to use statically-assigned port numbers, because that may collide with some other service running on the same host as the unit tests, or with another instance of the unit tests being run at the same time (out of a different source tree).

I guess what I'd suggest is to have the unit test use web.port=tcp:0,tcp:0. That will cause the client to start listening on two (separate) kernel-allocated ports. The first will get written into node.url, where the unit test can read it and verify that it can hit the welcome page. Then, use the following code to reach into the WebishServer and locate the listeners, so we can get both their port numbers, and check that the welcome page is reachable from both (for a total of three separate GETs):

 c = client
 ws = c.getServiceNamed("webish")
 for s in ws:
   # this iterates over all Service children of the WebishServer
   if isinstance(s, twisted.application.internet.TCPServer):
     yield s._port.getHost().port

I'd put the test in test_web.Grid, and take advantage of the client_config_hooks argument to set_up_grid to change the web.port= argument on the first client (see test/no_network.py around line 191).

comment:4 Changed at 2009-12-23T05:37:09Z by warner

  • Component changed from code-nodeadmin to code-frontend-web
  • Summary changed from Tahoe should allow a node to listen on multiple interfaces/ports to webapi: listen on multiple interfaces/ports

comment:5 Changed at 2010-06-13T01:04:56Z by davidsarah

  • Keywords http port added
  • Milestone changed from undecided to eventually
  • Priority changed from minor to major
Note: See TracTickets for help on using tickets.