webapi: listen on multiple interfaces/ports #770

New Issue

tahoe-lafs · 2009-07-22T22:21:22Z

swillden commented

2009-07-22 22:21:22 +00:00

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.

tahoe-lafs added the

labels 2009-07-22 22:21:22 +00:00

tahoe-lafs added this to the undecided milestone 2009-07-22 22:21:22 +00:00

warner commented

2009-07-28 22:01:16 +00:00

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.

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.

warner added

code-nodeadmin

and removed

code-network

labels 2009-07-28 22:01:16 +00:00

swillden commented

2009-07-28 22:51:20 +00:00

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.

swillden commented

2009-07-29 06:14:14 +00:00

Attachment multi-listen.dpatch (35022 bytes) added

Very simple multi-listener patch

**Attachment** multi-listen.dpatch (35022 bytes) added Very simple multi-listener patch

multi-listen.dpatch

34 KiB

warner commented

2009-08-07 05:43:50 +00:00

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).

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).

warner added

code-frontend-web

and removed

code-nodeadmin

labels 2009-12-23 05:37:09 +00:00

warner changed title from ~~Tahoe should allow a node to listen on multiple interfaces/ports~~ to webapi: listen on multiple interfaces/ports

2009-12-23 05:37:09 +00:00

tahoe-lafs added

major

and removed

minor

labels 2010-06-13 01:04:56 +00:00