On 08/03/2016 02:41, Buck Evan wrote:
> At this point I have a design issue. How do services become aware of each
> others' port numbers? I've considered using ftrig or envdirs or both to
> represent and notify this data. Still, I don't see how I can keep the
> overall state consistent in the case of a single service's restart; I don't
> believe in general I can assume that its old port number will still be
> available, which means that I will sometimes need to restart any other
> services in the "playground" (collection of supervised developer services)
> that know this port number. This implies dependency resolution, which is
> too complex for my taste.
With a distributed port number allocation mechanism (i.e. what the kernel
does) and no dependency resolution, you're going to have race conditions,
there's no way around it.
The only "correct" way to proceed is to have a centralized authority on
what port belongs to what service, with proper serialization: a daemon that
maintains a map of the associations, that updates it when it changes, and
that services go through to query an association (or request a new port
number), so it can do the operation in a guaranteed order that avoids
race conditions - but you'll always have the old race "A queries port of B,
gets it, and B dies at that moment, and port gets reused", which you may
mitigate by not using SO_REUSEADDR.
That's probably a bit more complex than what you want to handle. :)
--
Laurent
Received on Tue Mar 08 2016 - 09:07:43 UTC