On 8/21/2013 12:50 AM, Martin Sustrik wrote:
On 20/08/13 17:01, Joe Touch wrote:
However, see my other message - it's hard to recommend an approach when
we don't understand the problem you're trying to solve.
The scenario is simple.
You want admin to open one port in the firewall when the project is
started. Going through the corporate process at this point is bearable
and makes sense.
Afterwards, you want to be able to expose arbitrary services through
that port without having to go through port-opening process over and
over again.
There's nothing new about multiplexing services over a single port; it's
a known problem with a few common solutions:
- dispatch the connections inside your system based on
in-band info
- initiate connections inside a handler, and transfer them
to spawned subprocesses
- use initial connections to exchange inband info for other
connections on dynamic ports (as done in FTP)
They each have their challenges.
The services are actually different aspects of the same distributed
application, say, data distribution service, management service,
heartbeating service etc. so not requiring additional process for adding
them makes sense.
Each distinct, independently-useable service may warrant a new port or
could all be muxed together. Which of these you seek is up to you.
That's a design decision.
The real problem here IMO is how to distinguish between "adding a
completely new application" -- which should require approval process --
and "adding a new component within an existing distributed application"
-- which should be managed by devs themselves.
IMO it's easy - any group of services you want others to be able to use
independently could justify a new port, but you can always mux them all
together if you want to avoid additional firewall configuration issues.
I.e., this is your call. But it doesn't appear to have anything to do
with the notion of a single port to access any *existing* service, which
is what TCPMUX and its descendants does.
Joe