On 8/22/2013 12:44 AM, Martin Sustrik wrote:
On 21/08/13 19:00, Joe Touch wrote:
So what would you use for muxing, if TCPMUX is not a good idea?
You need to roll your own. The requirements of systems vary widely, as
do the costs/benefits of different approaches.
I listed a few before, but here's a more comprehensive list:
- service per message
demux based on message ID
use IPC (interprocess comm) to handoff internal
to your system
- service per connection
demux based on the first message in an
association (TCP or UDP), and either continue to
forward messages to a different process or handoff
the connection
So, if I proceed with this option why not use RFC1078 to implement it?
Why write a new RFC if there's an old one that fits the bill?
There are two cases to consider:
- you're creating your own set of services, at which point
you'll need to roll your own dispatch mechanism
- you want to use TCPMUX, either for your own services or for
all services
you should already realize why that's a dead-end.
any sysadmin that blocks *any* ports will always
block TCPMUX
One final reason TCPMUX isn't deployed is that it changes the semantics
of many existing services, many of which are defined as "if the
connection opens, then the service is there".
If you roll your own version, you can define your services to accept
those semantics.
Joe