On 30/08/11 09:42, Andrew Beekhof wrote:
On Mon, Aug 29, 2011 at 7:57 PM, Zane
Bitter<zbitter(a)redhat.com> wrote:
> Questions for the list...
>
> On 27/08/11 00:56, Pearl Liang via RT wrote:
>> Thank you. Please see below comment and questions:
>>
>> ------
>>
>>> A couple of clarifications may help here:
>>> 1) The purpose of matahari is not to configure QMF/Qpid, but to
>>> configure the entire system. For example, starting and stopping
>>> network
>>> interfaces, services, virtual machines or entire boxes.
>>> 2) QMF does not run atop matahari. Matahari runs atop QMF, which
>>> itself
>>> runs atop Apache Qpid (which is the AMQP implementation).
>>>
>>> The reason for a separate port is that end users may want to run a
>>> vanilla AMQP service on their hosts which is logically separate from
>>> the
>>> matahari AMQP bus. We cannot force generic users of AMQP to have their
>>> services coexist with ours (for instance, they may require a different
>>> implementation of AMQP), so we request a separate port so that our
>>> specific usage of AMQP can remain logically separate.
>>
>> Thanks for the clarification. My question; how often should IANA expect
>> such requests? Is a discovery mechanism in order in the baseline AMQP
>> protocol? If someone else comes out with some other function that runs
>> atop AMQP but needs a different implementation, are we going to see
>> another request?
<delurk>
IANA are trying to limit port assignment to "one assigned port number
per service or application", see:
http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports-10#section-7.2
If there's a discovery mechanism built into AMQP, which would allow
multiplexing different variants over different ports (hypothetical
example: "ping" generic AMQP, ask it for whatever dynamic port matahari
happens to be running on on that system, then reconnect to that), then I
imagine IANA will strongly encourage the use of such a mechanism, as
opposed to the assignment of a new port for a service that may appear to
them as the same as (or very similar to, or a minor variant on) an
existing service.
IMO the key may be to point out major differentiators, inadequacies,
etc. between matahari and any generic AMQP, or other generic thingy.
(Bearing in mind that I have no particular knowledge of the inner
workings of any of these bits and pieces :))
</delurk>
Tim
--
Tim Serong
Senior Clustering Engineer
SUSE
tserong(a)suse.com