On Fri, 2008-10-10 at 15:33 +0000, Scott Lawrence wrote: > The kernel won't let two services open the same port, and I think this > is the only interlock we should use (other than perhaps a static check > in sipXconfig). > > Failure to open a configured port would be an excellent candidate for an > alarm, which will quickly bring the configuration problem to the > attention of the administrator.
Yeah, I think it's important that sipXconfig keep track of all the ports that it has configured components to use on all the servers. This allows sipXconfig to reject incorrect configurations when the administrator attempts to make them. I see this as avoiding the largest source of port-allocation problems. There are also some semi-standard rules regarding how ports are to be assigned dynamically. The port allocation component can be aware of these, which will make it less likely that configurations that sipXconfig has approved will run into problems at run-time. At run-time, each component should check that attempts to open ports have succeeded (I don't think the code does that now, ugh), and raise a proper alarm (since the system is unlikely to work). Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
