Re: TCPMUX (RFC 1078) status

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

 



On 16/08/13 03:23, Wesley Eddy wrote:

There are semantics issues to; see draft-touch-tcp-portnames-00 for
information (this is being revised for resubmission shortly, FWIW).

I totally agree.  In fact, in the update to the TCP roadmap [1], we
added TCPMUX to the section on "Historic and Undeployed Extensions",
though it definitely bears further discussion than is currently in
the roadmap.  I think we should add a reference to your portnames doc
to explain why this should be Historic plus check a bit more to see if
the code that's out there is really being used or whether it's just
hanging out like a vestigal limb in the various inetd packages.

If it's fair to ask Martin ... I'm kind of curious why you might want
to be using it or think it sounds useful?  I think a lot of admins
would be concerned that it could be used to get around port-based
firewall rules, etc.

Ok, let me explain.

I am coming from enterprise messaging world (think of IBM MQ series, JMS, ActiveMQ, RabbitMQ et c.)

Once I was participating on AMQP protocol development (now at OASIS). So, what AMQP and other enterprise messaging products do is exposing a "message broker" on a single TCP port, which then forwards messages to any connected services. As can be seen, single open firewall port can be used to access any internal service.

That being obviously the *wrong* way to do things, I've written ZeroMQ later which takes the strict approach: If you want to expose a new service, you have to use a separate TCP port number.

Since then it turned out that this as a limitation that people are most complaining about.

Now, the reason seems to be that ZeroMQ requires you to use different TCP connections for doing different kinds of stuff to avoid head-of-line blocking et c. (think of SCTP channels simulated via TCP)

What that means is that you have a lot of fine-grained services and as the development of your application proceeds you add more of them, remove them and so on.

That in turn requires admins (and the corporate approval process!) to get into the deployment cycle and open the TCP ports as appropriate. The result is that the development basically grinds to halt.

The solution IMO is to preserve the port-based services functionality for those that truly care about security and -- optionally -- support some kind of multiplexer such as TCPMUX for those that care more about short deployment cycle.

That being said, IIRC, there's such functionality in WebSockets as well. Open a connection to fixed pot (80) and particular URL (string), then after the initial negotiation, switch to raw TCP mode and hand the connection to whatever application is suppose to handle it. The reason I don't like that solution is that you have to have web server installed to work as a multiplexer, which is kind of strange.

Martin





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