On 6 August 2014 13:57, Gustavo Niemeyer <gust...@niemeyer.net> wrote: > Why would any application well designed open thousands of ports individually > rather than a range? Sounds like an unreasonable use case.
I don't know. But if it's easy to make it work well in this case too (and I believe it is), then why not make it work well for all use cases? > I also don't get your point about concurrency. You don't seem to have > addressed the point I brought up that opening or closing ports concurrently > today already presents undefined behavior. The result is undefined for a unit (a port open can fail if another one already has the port open) but the invariant is well defined - only one unit may have a port open at any one time. We want to make sure the invariant is always satisfied even if units are racing for the port. Defining the simple rule (you must always close exactly what you've opened) makes it easy to do that without imposing much burden on the charm authors AFAICS. rog. > gustavo @ http://niemeyer.net > > On Aug 6, 2014 2:53 PM, "roger peppe" <roger.pe...@canonical.com> wrote: >> >> On 6 August 2014 10:32, Gustavo Niemeyer <gust...@niemeyer.net> wrote: >> > How many port ranges are typically made available? One.. Two? Sounds >> > like a >> > trivial problem. >> >> Some applications might open thousands of individual ports. >> It would be nice if it worked well in that case too. >> >> > In terms of concurrency, there are issues either way. Someone can open a >> > port while it is being closed, and whether that works or not depends >> > purely >> > on timing. >> >> When we've got several units sharing a port space, we'll want to >> keep a unique owner for each port range. That's trivial if the >> reference can be keyed by the port range, but not >> as straightforward if the lookup is two-phase. >> >> What we don't want is two units in the same machine to be >> able to have the same port open at the same time. I suppose >> we could rely on the fact that hooks do not execute simultaneously, >> but it would be preferable in my view to keep those >> concerns separate. >> >> In my view, "always close the range you've opened" is an easy >> to explain rule, and makes quite a few things simpler, >> without being overly restrictive. >> >> > gustavo @ http://niemeyer.net >> > >> > On Aug 6, 2014 9:41 AM, "roger peppe" <roger.pe...@canonical.com> wrote: >> >> >> >> On 5 August 2014 19:34, Gustavo Niemeyer <gust...@niemeyer.net> wrote: >> >> > On Tue, Aug 5, 2014 at 4:18 PM, roger peppe <rogpe...@gmail.com> >> >> > wrote: >> >> >> close ports 80-110 -> error (mismatched port range?) >> >> > >> >> > I'd expect ports to be closed here, and also on 0-65536. >> >> >> >> I'm not sure. An advantage of requiring that exactly the >> >> same ports must be closed as were opened, you can use the port range >> >> as a key, which makes for a very simple (and trivially concurrent-safe) >> >> implementation in a mongo collection. >> >> >> >> I'd suggest that this compromise is worth it. We could always make an >> >> initial >> >> special case for 0-65535 too, if desired. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
