Hi,
This post is about ports and IP addresses used by the Assimilation code
- both for testing and production. If you aren't familiar with IP
addressing and port considerations, your eyes will likely glaze over,
and you'll be forgiven if you stop reading here -- unless you need
something to put you to sleep (or maybe make your head hurt) ;-)
For production, the default configuration for finding the CMA will be to
send a single packet a multicast packet to a reserved multicast address
*[224.0.2.5]*. So, the CMA needs to be listening to that address by
default - in addition to normal unicast IP addresses for follow-on
communication.
Most nanoprobes will not have any trouble with port conflicts, even if
they listen to the ANY address. However, machines which are part of the
collective management authority will have a problem, since the CMA will
use the same port as the clients.
But once it gets going, I need for a client and a server to be on the
same machine at the same time, with no IP:port bind conflicts. If we
only use one port, this is a slight complication - it means that the CMA
will need two IP addresses available to it - one for the CMA and one for
the nanoprobe. However, if you want to have an HA cluster setup, you'll
need that extra address so CMA functions can be moved around in the cluster.
I believe that this means that neither the CMA nor nanoprobes running on
a production CMA cannot listen on the ANY address - since only one can
bind to the ANY address on a particular port.
There is a strategy available, to have the nanoprobes bind individually
to */each/* IP address that it can bind to. If the CMA starts first and
only binds to a single IP address, then the remaining IP addresses are
available for the nanoprobes to bind to. Let's call this the "*each*"
strategy.
However, this kind of breaks the idea of an incredibly easy out of the
box experience, since you would require people playing with it to set up
a second IP address. Some places would find this a barrier to trying
out the software.
Another alternative would be for nanoprobes on the CMA to be invoked
with an option telling it bind to another free UDP port, and announce
their port binding in their signon message.
I have some ideas about how to solve this using ipv6, but that's
probably premature as an incredibly easy and universal setup alternative
at this time. The code supports ipv6, but it shouldn't be a default
zeroconf configuration.
In order to be able to do automated testing, it seems good to be able to
run this without interfering with any arbitrary local port assignments.
In this case, the only way to be able to run this in an environment
where tests might be running in parallel would be through the idea of
selecting any available port - for both the client and server. Since
the server can fork off the client, it can pass it an option telling it
what its address (probably 127.0.0.1) and port are when it starts up.
The client then finds a free port on that address and follows the
protocol described above.
So it seems clear that I need the idea of the client choosing an
available port no matter what. In addition, for proper testing, it
seems that I'll need a similar option at least for the test CMAs.
For a nanoprobe to start up properly, it is necessary for it to know
what address and port to use when initially contacting the CMA. If a
client can use the default multicast address with the port *1984*
(courtesy of Sean MacGuire), then even the normal server can use any
free UDP port.
HOWEVER, it's a a good idea to always use the same port for clients and
servers in a site, so random port assignments should be relegated to
special cases as much as possible.
The ultimate in flexibility would be to implement the free port
assignment code, and also an "each" listen strategy in the nanoprobes.
Then we could use the available (random) nanoprobe port assignment
strategy for a great out of the box experience, and the "*each*"
strategy with a virtual IP for a production site where the random ports
are frowned on, or it is running in an HA environment so that there's a
virtual IP anyway.
So, I think I've managed to make the most work possible out of this. :-D
What are your thoughts about these strategies, and problems?
[By the way, this is why my code is currently hard-wired to some
addresses in my house - I knew that doing this so that it can be
out-of-the-box simple, and also production-worthy wouldn't be simple].
--
Alan Robertson <[email protected]> - @OSSAlanR
"Openness is the foundation and preservative of friendship... Let me claim from you
at all times your undisguised opinions." - William Wilberforce
_______________________________________________
Assimilation mailing list - Discovery-Driven Monitoring
[email protected]
http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation
http://assimmon.org/
