Re: TCPMUX (RFC 1078) status

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]