On Sat, Jun 07, 2003 at 12:32:42PM -0400, Kurt Starsinic wrote: > 1. It's not *actually* using the official registry, as > advertised; the port numbers are hard-coded.
Thanks for the taking the time to draw up your concerns. Actually, it *is* using the official registry, as advertised. There is an undocumented internal method named _create_db which takes the official registry at http://www.iana.org/assignments/port-numbers and converts it into the internal representation to which you're referring. I do this for several reasons, and the top reason is that it results in a distribution that *tremdously* smaller than if it would not have been translated to an internal representation. I discussed some of this on IRC with Dan Sugalski, and he mentioned that it would be best to get it as small as possible (although I did not discuss any possible implementations to accomplish this, with him). Since the port registry has much miscellanea in the file that is not necessary to the operation of N::I::P, I translated it to an internal representation that encodes only what is relevant. The internal representation also results in N::I::P being ever-so-slightly faster and less memory-intensive. If you still feel there should be an implementation change for this point, please feel free to suggest one that you feel would be better. :-) > Thus, if the registry is updated, I have no way of knowing that > the entries I'm using are outdated, and no way of > forcing an update. There is a method last_updated() that will return the date that the IANA port registry, that was translated, stated that it was last updated. Ostensibly, there is no current means by which one could force an update, but I had planned to keep a good eye on it and release new versions as necessary. If I do include a means by which to allow users of N::I::P to force an update how would you envision that working? > 2. You leave out some ports "with no associated protocols." > I'm not sure what the value of this is; as a naive user, I > would expect that the module maps as in IANA's registry, > not as in what protocols are actually known to be deployed > in the wild. Well, the problem with the sixteen services that you mention is simply that in the port registry they have no protocols associated with them, thus I have no idea as to how they should be "correctly represented". I figured it would be better to disclude them than to guess, being that all of the methods require either a port and protocol, or service and protocol. I regard these particular entries, in the port registry, as clerical mistakes, since the thousands of other services do indeed have associated protocols. If you have any ideas as to how this can best be dealt with, I am all ears. -- Adam J. Foxson
