On Sun, Nov 25, 2018 at 6:13 PM Matthew Flatt <[email protected]> wrote:
> At Sat, 24 Nov 2018 19:39:19 -0500, Philip McGrath wrote: > > On Fri, Nov 23, 2018 at 5:44 PM George Neuner <[email protected]> > wrote: > > > > > Multiple (identical) server instances running on the same machine can > > > listen for connections on the same network port - an incoming client > call > > > will be connected to only one of them. You only need to use different > > > ports when services are not interchangeable [i.e. it matters which one > you > > > are talking to]. > > > > > > [...] > > > > I didn't know this, and it sounds useful! Unfortunately, this > functionality > > doesn't currently seem to be exposed at the Racket level. [...] > > > > It looks like the `reuse?` argument to `tcp-listen` corresponds to > > `SO_REUSEADDR` rather than `SO_REUSEPORT`. [...] > > > > It seems like this might be a useful feature in Racket, but I'm not sure > of > > what would be needed to expose it in a good way. > > An alternative to exposing `SO_REUSEPORT` would be to allow TCP > listeners to be sent across place channels, so multiple places in same > Racket process could accept connections from the same listener. That > would only work for place-based parallelism, but it would be portable > and straightforward to implement --- and I'm happy to add it if anyone > would find that capability useful. > Allowing TCP listeners to be sent across place channels sounds much more promising than exposing the portability issues with `SO_REUSEPORT`—I, for one, am a big fan of the fact that Racket makes it easy to write portable code. It also seems like it would be a step toward adding built-in support for parallelism to the web server, which is something I'd be interested in working on eventually (i.e. definitely not this week). While looking into this I read the discussion <https://lwn.net/Articles/542718/> about adding `SO_REUSEPORT` to the Linux kernel, and one of the motivations discussed was performance, which did seem worth considering in advance. Specifically, apparently if you > accept on a single listener socket from multiple threads … the proportion > of connections accepted per thread tends to be uneven under high connection > load (assuming simple event loop: while (1) { accept(); process() }, wakeup > does not promote fairness among the sockets. We have seen the > disproportion to be as high as 3:1 ratio between thread accepting most > connections and the one accepting the fewest. With so_reusport the > distribution is uniform. > Am I right that this is essentially what Racket would be doing internally if multiple places were blocked on `tcp-accept` with the same TCP listener? (This is a bit low-level for me.) Even if so, I think being able to send TCP listeners across place channels would probably still be useful, especially since most of us will never see what Google would call "high connection load." -Philip -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
