Alan,
RFC 1519 refers to one representation as address + mask and the other as
prefix + prefix-length. Both are CIDR compatible representations, so I'll
adjust the docs.
RFC 1518, section 4 says that "[for] the purposes of this paper, an IP
prefix is an IP address and some indication of the leftmost contiguous
significant bits within this address." The format used in the RFC is
"expressed as tuples, such that a bitwise logical AND
operation on the IP-address and IP-mask components of a tuple yields the
sequence of leftmost contiguous significant bits that form the IP address
prefix. For example a tuple with the value <193.1.0.0 255.255.0.0> denotes
an IP address prefix with 16 leftmost contiguous significant bits."
InetNetwork uses a tuple format internally, and supports the prefix-length
format by conversion.
I don't understand what you meant by "InetNetwork appears incomplete and
geared to James v3.0." Although I just added the normalizeFromAsterisk
method to support James, InetNetwork was originally written for a web
application. More importantly, I'm not sure what you feel is missing, so
please elaborate. Is it just validation? Which specific validations do you
feel is necessary?
FWIW, I did some benchmarking of the JDK 1.3 vs JDK 1.4 compatible versions.
JDK 1.4 code ran ~5 times faster. I'm thinking that it might make sense to
use Ant to handle JDK 1.3 vs JDK 1.4 the same way that Serge set it up to
handle JDBC v2 vs JDBC v3. A binary from us would be JDK 1.3 compatible,
but if the user builds from source it will optimize for what they have
installed.
--- Noel
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 17, 2003 8:58
To: James Developers List
Subject: CIDR and InetNetwork Classes
Noel -
Basic functional differences between the InetNetwork and
CIDR classes can be simply summated as 'CIDR supports CIDR
notation' and 'InetNetwork supports IP/MASK', and each class
has their respective support/utility methods that offers the
desired functionality ...
The primary motivation behind CIDR was to offer James user's
the ability to define sub-networks with CIDR notation; a
standard practice among ISP's and other SMTP server
administrators, and since InetNetwork now supports CIDR and
'*' notation, CIDR has become superfluous.
The performance difference between the two is noticeable;
CIDR uses clumsy string mathematics for conversion to
BigIntger while InetNetwork uses simpler bit wise operations
on byte arrays. The result appears to be a much faster test
operation with InetNetwork - and speed is crucial when
validating mails in high volume flows.
When we get down to implementation, it seems CIDR is ready -
used in a commercial situation - while InetNetwork appears
incomplete and geared to James v3.0. It is also incompatible
with Java 1.3, the current platform that James is committed
to.
The bottom line is what's best for James and it's users we
should do the following -
[1]
replace the following code
return InetAddress.getByAddress(new byte[]
{
(byte) (mask[0] & ip[0]),
(byte) (mask[1] & ip[1]),
(byte) (mask[2] & ip[2]),
(byte) (mask[3] & ip[3])
});
with
return InetAddress.getByName (
Integer.toString((mask[0] & ip[0]) >> 0 & 0xFF, 10) + "."
+
Integer.toString((mask[1] & ip[1]) >> 8 & 0xFF, 10) + "."
+
Integer.toString((mask[2] & ip[2]) >> 16 & 0xFF, 10) + "."
+
Integer.toString((mask[3] & ip[3]) >> 24 & 0xFF, 10) );
to get InetNetwork compatible with our current environment.
Once we require 1.4, we can replace the code to use the 1.4
InetAddress.getByAddress(byte[]) method. Benchmarking with
this change does not appear to slow down InetNetwork's
performance enough to be a concern.
[2]
in normalizeFromCIDR, validation of the CIDR notation needs
to be performed
[3]
Set up the GenericNetworkMatcher and it's associated
matchers to use InetNetworks and get a version for review
[4]
Included this new InetNetwork class and associated matchers
in the next scheduled release of James; which I believe is
to be on a regular monthly schedule.
James now has the ability to receive network specifications
in the following formats -
explicit address - 127.0.0.1
address with a wildcard - 127.0.0*
explicit name - myHost.com
name with CIDR notation - myHost.com/24
name with IP/MASK notation - myHost.com/255.255.255.0
CIDR notation - 127.0.0.0/24
IP/MASK notation - 127.0.0.1/255.255.255.0
Collaboration, not competition, is the bond that strengthens
our determination to go on.
___
thanks,
alan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscrib
