Mailing List Archive

Go here:
http://www.isi.edu/cgi-bin/iana/port-number.pl

This is where you can "register" the information .

It needs information like the type of packet, protocol description.


Matt Soffen
Applications Developer
http://www.iso-ne.com/
==============================================
Boss - "My boss says we need some eunuch programmers."
Dilbert - "I think he means UNIX and I already know UNIX."
Boss - "Well, if the company nurse comes by, tell her I said
never mind."
- Dilbert -
==============================================


> -----Original Message-----
> From: Alan Robertson [SMTP:alanr@bell-labs.com]
> Sent: Wednesday, November 24, 1999 10:04 AM
> To: linux-ha-dev@lists.tummy.com
> Subject: [Linux-ha-dev] Getting an "Official" port number
>
> Thomas Hepper wrote:
> >
> > Hi,
> > On Tue, Nov 23, 1999 at 03:03:30AM -0700, Alan Robertson wrote:
> > > Hi,
> > >
> > > I've put out an official version of heartbeat 0.4.6, and a new beta
> version
> > > called 0.4.6a.
> > >
> > > 0.4.6 is a minor improvement over 0.4.5e. For those that haven't been
> paying
> > > attention, this means it is mainly a bunch of simple bug fixes over
> 0.4.5.
> > >
> > > 0.4.6a is the first beta in the 0.4.7 series.
> > >
> > > It turns off /proc/ha support, and has what I think is the complete
> error
> > > correction protocol (famous last words :-)). I'll add some specific
> test stubs
> > > in a later beta so it can be more easily proven out.
> > >
> > > As always, let me know if you have problems.
> > >
> > No problems :-), only a wish. In the ha.cf example file is the udp port
> set to
> > 1001, but now on debian this port is used by pmake :
> > customs 1001/tcp # pmake customs server
> > customs 1001/udp # pmake customs server
> >
> > Any chance to get an 'official' port number, or can you place a big
> comment
> > in the example file to check the services file .....
> >
>
> I think it actually checks the services file itself, and assumes you don't
> want
> to conflict with this.
>
> I don't know how to get a reserved port number. Could someone do this for
> us?
>
> Thanks!
>
> -- Alan Robertson
> alanr@bell-labs.com
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev@lists.tummy.com
> http://lists.tummy.com/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/

"Soffen, Matthew" wrote:
>
> Go here:
> http://www.isi.edu/cgi-bin/iana/port-number.pl
>
> This is where you can "register" the information .
>
> It needs information like the type of packet, protocol description.

OK. I filled in the form -- the protocol description was a little vague. The
results are below... Expect 2-3 week turnaround.

-- Alan Robertson
alanr@bell-labs.com

-------- Original Message --------
Subject: IANA Automatic Response Message Re: Application for port-number
Date: Wed, 24 Nov 1999 08:43:26 -0800
From: Internet Assigned Numbers Authority <iana@ISI.EDU>
Reply-To: iana@iana.org
To: alanr@bell-labs.com

Hi.

This is an automatic reply to acknowledge that your message has been
received by iana@iana.org

Because of the number of requests, some of the processing must be done
automatically.

If you are looking for the current information about any of the kinds
of assigned numbers, names, or other parameters we maintain, you can
find the online files via FTP at:

ftp://ftp.isi.edu/in-notes/iana/assignments/

or via the web at:

http://www.iana.org

While we will review your message and reply as soon as possible, it
could take up to 15 working days to process your request.

Regards,

The Internet Assigned Numbers Authority

Alan Robertson wrote:
>
> "Soffen, Matthew" wrote:
> >
> > Go here:
> > http://www.isi.edu/cgi-bin/iana/port-number.pl
> >
> > This is where you can "register" the information .
> >
> > It needs information like the type of packet, protocol description.
>
> OK. I filled in the form -- the protocol description was a little vague. The
> results are below... Expect 2-3 week turnaround.
>
> -- Alan Robertson
> alanr@bell-labs.com

FYI:

Here's what I filled into the form...

Name :
Alan Robertson

E-mail :
alanr@bell-labs.com

Protocol Number :
UDP

Message Formats :
The protocol consists of a sequence of fields in "name=value" form.
The order of fields in a message is irrelevant. This level of flexibility
is necessary for supporting different versions of the software across
the same network, since this is a high-availability application which
should not ever require a complete restart.

Message Types :
data frame {can be any opcode below}
retransmit request
retransmit nak

Message opcodes :
heartbeat
resource-request
resource-request-reply
initiate-transaction
advance-transaction-state
abort-transaction
complete-transaction

Message Sequences :
Heartbeats are sent continuously.
Resource requests await either a reply or a timeout.
Other messages are structured on an n-phase commit transaction protocol similar
to IBM's Phoenix cluster services. See "In Search of Clusters" approximately
page 428.

Protocol functions :
This is the high-availability Linux protocol
This protocol is used to perform cluster management for the High-Availability
Linux project (http://linux-ha.org).

Cluster management consists of things like heartbeat, cluster membership,
and service migration and negotiation operations. In addition, the transaction
protocol API will be available to cluster-aware applications for them to
coordinate and manage themselves across the cluster.

Broadcast or Multicast used ?
yes

How and what for Broadcast or Multicast is used (if used):
99.9% of the packets are simply heartbeat packets. For efficiency,
every element of the cluster sends one packet, and it is received by all the
members of the cluster. That way, all members of the cluster know what's going
on.

Range for port number :
system port

Description :
We need a port number so we can make the application easy to install and to use.
Each machine in the cluster must use the same port number. Clusters can involve
potentially hundreds of machines. This makes it much simpler to install and
configure.

It should be a system port number because of the security implications involved
in allowing a user process to be able to easily masquerade as a cluster member.
A cluster member can tell another cluster member to release a resource and they
will do it. This is analagous to root permissions in an OS.
We have optional strong authentication methods, but the additional security of
making
it hard for normal user apps to open the port would be appreciated.

Name of the port :
ha-cluster

On Wed, 24 Nov 1999, Alan Robertson wrote:

>
> Range for port number :
> system port
>
> Description :
> We need a port number so we can make the application easy to install and to use.
> Each machine in the cluster must use the same port number. Clusters can involve
> potentially hundreds of machines. This makes it much simpler to install and
> configure.
>
> It should be a system port number because of the security implications involved
> in allowing a user process to be able to easily masquerade as a cluster member.
> A cluster member can tell another cluster member to release a resource and they
> will do it. This is analagous to root permissions in an OS.
> We have optional strong authentication methods, but the additional security of
> making
> it hard for normal user apps to open the port would be appreciated.
>
Just a question, don't we need a range of port numbers? Otherwise we have
the limit of one cluster per subnet. Or how does heartbeat react when one
cluster receives the heartbeat from another?

Regards,
Holger

On Thu, 25 Nov 1999, Holger Kiehl wrote:

>
>
> On Wed, 24 Nov 1999, Alan Robertson wrote:
>
> >
> > Range for port number :
> > system port
> >
> > Description :
> > We need a port number so we can make the application easy to install and to use.
> > Each machine in the cluster must use the same port number. Clusters can involve
> > potentially hundreds of machines. This makes it much simpler to install and
> > configure.
> >
> Just a question, don't we need a range of port numbers? Otherwise we have
> the limit of one cluster per subnet. Or how does heartbeat react when one
> cluster receives the heartbeat from another?
>
No, we don't need a port range. It would restrict the number of clusters
to the number of ports in the range. Call it misbehaved. The solution is
to assign a name and/or number to each cluster and to include this field
in the message.

Alan: PLEASE, PLEASE, change your application to include TCP as well as
UDP !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

We *need* to be able to have stream connections in addition to datagrams.

> Regards,
> Holger
>
Volker

--
Volker Wiegand Phone: +49 (0) 6196 / 50951-24
SuSE Rhein/Main AG Fax: +49 (0) 6196 / 40 96 07
Mergenthalerallee 45-47 Mobile: +49 (0) 179 / 292 66 76
D-65760 Eschborn E-Mail: Volker.Wiegand@suse.de
++ Only users lose drugs. Or was it the other way round? ++

Volker Wiegand wrote:
>
> Alan: PLEASE, PLEASE, change your application to include TCP as well as
> UDP !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
> We *need* to be able to have stream connections in addition to datagrams.

Volker,

Since you haven't told me what you're doing, it's no surprise I didn't include
it. I'll see what I can do to get it added.

On the other hand, please stop what you're doing for 20 minutes and write us a
summary of your current status. If you're writing another protocol and haven't
told me about it, then I can hardly plan on it, can I? You can surely afford 20
minutes every week or two.

When we last talked about it, you had expressed a desire to go forward
together. I'd love to do that. However, it is impossible to go forward *with*
you if you don't communicate.

I am about to run out of things to do in the base heartbeat code. Within a few
days, I will go forward into other things. I will chooose what I do
next on the basis of what I believe needs doing most. Without any information
beyond an initial email from you, I'll probably head straight into implementing
areas that you might already be doing.


-- Alan Robertson
alanr@bell-labs.com

Volker Wiegand wrote:
>
> On Thu, 25 Nov 1999, Holger Kiehl wrote:
>
> > On Wed, 24 Nov 1999, Alan Robertson wrote:
> >
> > >
> > > Range for port number :
> > > system port
> > >
> > > Description :
> > > We need a port number so we can make the application easy to install and to use.
> > > Each machine in the cluster must use the same port number. Clusters can involve
> > > potentially hundreds of machines. This makes it much simpler to install and
> > > configure.
> > >
> > Just a question, don't we need a range of port numbers? Otherwise we have
> > the limit of one cluster per subnet. Or how does heartbeat react when one
> > cluster receives the heartbeat from another?

It whines. Kind of loudly. Once a second for each foreign cluster on the
subnet. It's decidely grating.

The *right* answer is multicast groups. Shouldn't be too difficult.

> No, we don't need a port range. It would restrict the number of clusters
> to the number of ports in the range. Call it misbehaved. The solution is
> to assign a name and/or number to each cluster and to include this field
> in the message.

That's not as good an answer as multicast, since the packet comes up into the
driver and up to the application where it is checked for authenticity before it
gets thrown away. Lots of wasted resources here. You effectively have the
capability you talked about already by giving each cluster it's own
authentication key. Packets from other clusters will be automatically dropped
[with the grating whining noise noted above].

You can always use an unofficial port number if you wish. I'm not going to take
away the ability to configure port numbers of your own choosing.

Lots of ways to handle this.

Applications for implmenting multicast are now being accepted :-)

-- Alan Robertson
alanr@bell-labs.com

Volker Wiegand wrote:
>
> > On Wed, 24 Nov 1999, Alan Robertson wrote:
> > >
> > > Range for port number :
> > > system port
> > >
> > > Description :
> > > We need a port number so we can make the application easy to install and to use.
> > > Each machine in the cluster must use the same port number. Clusters can involve
> > > potentially hundreds of machines. This makes it much simpler to install and
> > > configure.

> Alan: PLEASE, PLEASE, change your application to include TCP as well as
> UDP !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
> We *need* to be able to have stream connections in addition to datagrams.

Volker,

I started to revise the application and resubmit it as a correction, but
realized that I don't know anything about the protocol you intend on running on
this port.

When filling out the application, all kinds of questions are asked about the
protocol which I don't think I know how to answer.

As I mentioned before, I would be happy to fill out the form and resubmit it.
Unfortunately, I do need additional information which I don't have in order to
do this.

From what I could see, they may also want different applications for each
diffeent protocol. Does anyone know for sure? Also, how different is what
you're planning from what is currently being done? Are you just talking about
running the current protocol across a different transport?

-- Alan Robertson
alanr@bell-labs.com

Hi,

I've been in one of those unfortunate circumstances I hate to find myself in --
my conscience has been bothering me. And the reason that it has been bothering
me is that I didn't treat Volker in the way I'd like to be treated on the list.
That is, I believe I used unnecessarily harsh language and failed to set a good
example for the project in a recent email to the list.

I believe my request was reasonable, but the langauge I used to express it put
him down for no valid reason.

So, I feel compelled to stop and apologize to everyone on the list, and
especially to Volker for the way I phrased my request.

With apologies,

-- Alan Robertson
alanr@bell-labs.com

On Thu, 25 Nov 1999, Alan Robertson wrote:

> Volker Wiegand wrote:
> >
> > Alan: PLEASE, PLEASE, change your application to include TCP as well as
> > UDP !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> >
> > We *need* to be able to have stream connections in addition to datagrams.
>
> Volker,
>
> Since you haven't told me what you're doing, it's no surprise I didn't include
> it. I'll see what I can do to get it added.
>
Maybe we can revise the application form together. I don't do anything
different from your current way, but would prefer to be more general on
some of the questions. I do not use TCP nor plan to do it in near future,
but would like to have the same port number if we decide to use it later.

> On the other hand, please stop what you're doing for 20 minutes and write us a
> summary of your current status. If you're writing another protocol and haven't
> told me about it, then I can hardly plan on it, can I? You can surely afford 20
> minutes every week or two.
>
Yes, Sir, you are absolutely right. I was not playing by the rules. Please
take my apologies.

My current work concentrates on design and initial coding for the
following modules:

(1) Framework for process startup and IPC, based upon pluggable interfaces
for heartbeat, service+system monitoring, configuration
reading+updating, cluster topology+strategy, alerting and application
interfacing

(2) Definition of a flexible, hierarchical config file format

(3) Layout and standardized interface for a central shared memory

(4) Heartbeat modules based upon Alan's current implementation

(5) System monitoring, learning from UCD-SNMP

(6) Application monitoring, learning from Mon and PIKT

(7) Configuration reading module, filling the ShMem

(8) Configuration version control, based upon CVS

(9) Alerting module (mail, pager, syslog, traps)

(10) SNMP Interface, based upon the AgentX protocol
(only for diagnosing the cluster, no manipulation)

(11) BMC Patrol knowledge module for cluster diagnostics

(12) Cluster communication on resources and services

(13) (Initial, primitive) Cluster strategy module to synchronize the
most effective resource distribution, and execute it

(14) Application interfaces:
- Wrappers for start/stop/status of non-aware applications
- Requirements collection for "Cluster aware API"


Status: requirements and design roughly done, coding started on all
modules, so that the interfaces are done first, and after inclusion into
Alan's CVS they can be filled with life from different persons.

> When we last talked about it, you had expressed a desire to go forward
> together. I'd love to do that. However, it is impossible to go forward *with*
> you if you don't communicate.
>
I was able to do a lot of requirement and design docs in the previous two
weeks, and have started coding beginning of this week. This week was a bit
harder due to many requests in the office and from my family. I know this
is no excuse, so please again let me apologize for not communicating
sufficiently.

My plan was (and if you can accept it still is) to setup a common
"infrastructure" that can easily be worked upon by several people
*simultaneously*.

> I am about to run out of things to do in the base heartbeat code. Within a few
> days, I will go forward into other things. I will chooose what I do
> next on the basis of what I believe needs doing most. Without any information
> beyond an initial email from you, I'll probably head straight into implementing
> areas that you might already be doing.
>
As you know, I have been heavily thinking about using existing protocols,
like SNMP or ACE/TAO/CORBA for the underlying message exchange. Looking
closer at Ensemble I found also beauty in it. But as you asked (and also
convinced) me, I have not changed the way things are currently run, at
least not for the protocol or your message exchange mechanisms. I merely
build upon your work.

>
> -- Alan Robertson
> alanr@bell-labs.com
>
Volker

--
Volker Wiegand Phone: +49 (0) 6196 / 50951-24
SuSE Rhein/Main AG Fax: +49 (0) 6196 / 40 96 07
Mergenthalerallee 45-47 Mobile: +49 (0) 179 / 292 66 76
D-65760 Eschborn E-Mail: Volker.Wiegand@suse.de
++ Only users lose drugs. Or was it the other way round? ++

Volker Wiegand wrote:
>
> On Thu, 25 Nov 1999, Alan Robertson wrote:
>
> > Volker Wiegand wrote:
> > >
> > > Alan: PLEASE, PLEASE, change your application to include TCP as well as
> > > UDP !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> > >
> > > We *need* to be able to have stream connections in addition to datagrams.
> >
> > Volker,
> >
> > Since you haven't told me what you're doing, it's no surprise I didn't include
> > it. I'll see what I can do to get it added.
> >
> Maybe we can revise the application form together.

Feel free to improve on what I sent in, and send it back - probably by private
email.

> I don't do anything
> different from your current way, but would prefer to be more general on
> some of the questions. I do not use TCP nor plan to do it in near future,
> but would like to have the same port number if we decide to use it later.

OK. It was hard to tell that from tone of your note (all caps and lots of
"!"). It sure sounded like I had run afoul of something specific you had
planned.

> > On the other hand, please stop what you're doing for 20 minutes and write us a
> > summary of your current status. If you're writing another protocol and haven't
> > told me about it, then I can hardly plan on it, can I? You can surely afford 20
> > minutes every week or two.
> >
> Yes, Sir, you are absolutely right. I was not playing by the rules. Please
> take my apologies.

Rules? What Rules? :-)

> My current work concentrates on design and initial coding for the
> following modules:
>
> (1) Framework for process startup and IPC, based upon pluggable interfaces
> for heartbeat, service+system monitoring, configuration
> reading+updating, cluster topology+strategy, alerting and application
> interfacing
>
> (2) Definition of a flexible, hierarchical config file format
>
> (3) Layout and standardized interface for a central shared memory
>
> (4) Heartbeat modules based upon Alan's current implementation
>
> (5) System monitoring, learning from UCD-SNMP
>
> (6) Application monitoring, learning from Mon and PIKT
>
> (7) Configuration reading module, filling the ShMem
>
> (8) Configuration version control, based upon CVS
>
> (9) Alerting module (mail, pager, syslog, traps)
>
> (10) SNMP Interface, based upon the AgentX protocol
> (only for diagnosing the cluster, no manipulation)
>
> (11) BMC Patrol knowledge module for cluster diagnostics

BMC Patrol is a commercial product. My sense is that being compatible with a
commercial product which isn't cluster oriented is a low priority. What did you
have in mind here?

> (12) Cluster communication on resources and services
>
> (13) (Initial, primitive) Cluster strategy module to synchronize the
> most effective resource distribution, and execute it
>
> (14) Application interfaces:
> - Wrappers for start/stop/status of non-aware applications
> - Requirements collection for "Cluster aware API"
>
> Status: requirements and design roughly done, coding started on all
> modules, so that the interfaces are done first, and after inclusion into
> Alan's CVS they can be filled with life from different persons.
>
> > When we last talked about it, you had expressed a desire to go forward
> > together. I'd love to do that. However, it is impossible to go forward *with*
> > you if you don't communicate.
> >
> I was able to do a lot of requirement and design docs in the previous two
> weeks, and have started coding beginning of this week. This week was a bit
> harder due to many requests in the office and from my family. I know this
> is no excuse, so please again let me apologize for not communicating
> sufficiently.

Apologies accepted. It is hard for me to know how to plan around what you're
doing when I don't know what it is, and especially when it's so amazingly broad
in scope as you indicated below.

> My plan was (and if you can accept it still is) to setup a common
> "infrastructure" that can easily be worked upon by several people
> *simultaneously*.

Yes, I suspect we can manage a moderate number of simultaneous developers (maybe
up to a dozen or so). I know where 3 or 4 part time people might come from. Do
you have any other candidates in mind? I just got some inquiries from SGI
hinting that they might be interested in helping out...

> > I am about to run out of things to do in the base heartbeat code. Within a few
> > days, I will go forward into other things. I will chooose what I do
> > next on the basis of what I believe needs doing most. Without any information
> > beyond an initial email from you, I'll probably head straight into implementing
> > areas that you might already be doing.
> >
> As you know, I have been heavily thinking about using existing protocols,
> like SNMP or ACE/TAO/CORBA for the underlying message exchange. Looking
> closer at Ensemble I found also beauty in it. But as you asked (and also
> convinced) me, I have not changed the way things are currently run, at
> least not for the protocol or your message exchange mechanisms. I merely
> build upon your work.

Changing things is OK. It's good to know why and what the results are expected
to be.

A general comment:
My sense of this is that you've bitten off a huge amount to start with. You
have outlined at least 5-10 staff years of work. I am a little concerned that
too much has to be done before we get much in the way of results...

What is your implementation strategy here? My bias is to choose a strategy
which gives us results quickly, and allows us to evolve. I think this is very
consistent with the strengths and weaknesses of the open source development
model.

On the other hand, it is good to lay out the interfaces very early on, so I
applaud this.

If you're going to have so many different pluggable modules, and interfaces, I
am concerned about managing a relatively monolithic development of such size in
the open source model.

Regarding CORBA:
The talk I heard on our local experience with CORBA was quite positive. It
might be worth considering.

-- Alan Robertson
alanr@bell-labs.com