You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Enrique Rodriguez (JIRA)" <ji...@apache.org> on 2007/01/29 21:25:49 UTC
[jira] Closed: (DIRSERVER-831) Proposed protocol-dns changes
[ https://issues.apache.org/jira/browse/DIRSERVER-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Enrique Rodriguez closed DIRSERVER-831.
---------------------------------------
> Proposed protocol-dns changes
> -----------------------------
>
> Key: DIRSERVER-831
> URL: https://issues.apache.org/jira/browse/DIRSERVER-831
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: dns
> Reporter: Richard Wallace
> Assigned To: Enrique Rodriguez
> Attachments: MX-QUERY.pdu, MX-RESPONSE.pdu, MX-TRAFFIC.libpcap, patch.diff
>
>
> Hello,
> Here are the first set of changes I'd like to contribute to the
> protocol-dns subproject. Here's a list of things I've done.
> 1) Converted the enumeration types ServiceType, ProtocolType,
> RecordClass, OpCode, RecordType, MessageType and ResponseCode into
> actual Java 5 enums. Because we need to encode and decode the actual
> values we can't rely on the ordinals the compiler will assign to them,
> so I've used a technique I found on the Java Specialists site
> (http://www.javaspecialists.co.za/archive/newsletter.do?issue=113), to
> efficiently do a conversion between enums and values with minimal code
> duplication.
> 2) Removed QuestionRecords and ResourceRecords classes since they were
> really just type-safe wrappers around Lists and replaced their usage
> with generic Lists.
> 3) Moved any encoding and decoding code that was in the MINA
> ProtocolEncoder and ProtocolDecoder to classes in the
> o.a.d.s.dns.io.encoder and io.decoder packages called DnsMessageEncoder
> and DnsMessageDecoder, respectively.
> 4) Removed the dependency by the encoders and decoders in the
> o.a.d.s.dns.io packages on MINA. The only thing they really used were
> the ByteBuffers from MINA and it was a pretty simple task to just switch
> to java.nio.ByteBuffers instead. The only hurdle I had to overcome was
> in the allocation of temporary buffers for things like enecoding domain
> names, which leads me to...
> 5) Instead of creating (or having to pull them from the MINA ByteBuffer
> pool) several ByteBuffers during encoding, I simply wrote directly to
> the buffer that was passed in. From what I could tell, the main reason
> for allocating the temporary buffers was to do the actual encoding of
> the domain name, get the byte array that was written to the buffer,
> write the length of the data to the actual ByteBuffer, then write the
> byte array from the temporary ByteBuffer. Instead, what I did was to
> record the position of the ByteBuffer, increment it by one, write the
> data (the domain name for instance), find the difference between the
> starting position + 1 and the current position, then go back to the
> starting position and write the length of the data and finally jump back
> to the end of the data and go onto the next bit of encoding. This
> should be more efficient because we're not constantly having to get
> ByteBuffers from a pool or have new ones allocated, and we also don't
> have to then create byte arrays and have the data from those temporary
> ByteBuffers read into the byte arrays.
> 6) Moved all the (get|put)Unsigned(Byte|Short|Int) methods into a
> utility class called ByteBufferUtil.
> 7) Changed the DnsMessage.transactionId property to be an int because it
> actually needs to be an unsigned short.
> 8) Fixed a bug with decoding domain names when they are compressed. The
> new position to jump to wasn't being calculated right all the time.
> There also seemed to be an assumption that the first thing to do after
> jumping was to read a label, but it could be the case that the new
> position is another jump so we need to call recurseDomainName() right
> after doing the jump in position.
> 9) Updated existing tests to actually check that what is encoded and
> decoded are correct. For this I also had to add equals() and hashCode()
> methods to classes that didn't already have them, like DnsMessage,
> ResourceRecordImpl, and others. I simply used the commons-lang equals
> and hashCode builders for this because I've found them to be
> tremendously useful for this in the past.
> 10) Added additional test for MX query and response parsing. I used the
> MX records from apache.org.
> 11) Added decoders to make the tests added in (10) pass. these are the
> IPv6RecordDecoder, MailExchangeRecordDecoder, AddressRecordDecoder, and
> NameServerRecordDecoder.
> That should cover it all. I'd like to add a few more decoders for
> things like TXT and SOA records. That should cover about 90% of the
> records in use on most DNS servers.
> Then I'd like to get things separated a little bit more and create
> subprojects within protocol-dns. I'm thinking something like
> protocol-dns/
> core/
> mina-shared/
> server/
> shared/
> mina/
> store/
> client/
> core would contain all the DNS message and record types as well as the
> decoders and encoders in dns.io right now. mina-shared would contain
> the ProtocolCodec stuff in dns.protocol.
> server/shared would contain the DnsConfiguration and other stuff that
> would be shard among server implementations, whether they use MINA or
> some other IO framework and whether they use ApacheDS for the store or
> some other backend like Bind zone files.
> server/mina would contain the DnsProtocolHandler from dns.protocol as
> well as the DnsServer class itself.
> server/store would contain the the backend store type stuff. It would
> probably wind up being separate subprojects itself, one for LDAP, JDBC,
> or Bind zone files.
> client would obviously contain any code for developers to generate and
> send queries to dns servers, and maybe an implementation of the dig
> command line tool.
> I wouldn't mind actually seeing this becoming a separate project of it's
> own, like dns.apache.org. That would be really cool.
> What do you think of these changes?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Closed: (DIRSERVER-831) Proposed protocol-dns changes
Posted by Trustin Lee <tr...@gmail.com>.
On 1/30/07, Trustin Lee <tr...@gmail.com> wrote:
>
> I am not commenting about the issue itself, but about how to use an issue
> tracker, so I'm just replying to the notification message.
>
> It is an assignee who *resolved* an issue, and it is a reporter who
> *closes* an issue. 'Closing an issue' is a procedure that the reporter of
> the issue reviews whether the changes made by the assignee is correct. If
> correct, the issue is closed. Otherwise, reopened.
>
> Of course, some people doesn't get back to us to close his or her issue.
> We could close them by ourselves after moderate amount of time.
>
> It's not a big thing, but it is always good to know principles.
Oops, it seems like Richard didn't have permission to close the issue, so
Enrique closed it for him. It seems like we got a problem with permission
system. Very weird.
Apologies,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: [jira] Closed: (DIRSERVER-831) Proposed protocol-dns changes
Posted by Trustin Lee <tr...@gmail.com>.
I am not commenting about the issue itself, but about how to use an issue
tracker, so I'm just replying to the notification message.
It is an assignee who *resolved* an issue, and it is a reporter who *closes*
an issue. 'Closing an issue' is a procedure that the reporter of the issue
reviews whether the changes made by the assignee is correct. If correct,
the issue is closed. Otherwise, reopened.
Of course, some people doesn't get back to us to close his or her issue. We
could close them by ourselves after moderate amount of time.
It's not a big thing, but it is always good to know principles.
Trustin
On 1/30/07, Enrique Rodriguez (JIRA) <ji...@apache.org> wrote:
>
>
> [
> https://issues.apache.org/jira/browse/DIRSERVER-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Enrique Rodriguez closed DIRSERVER-831.
> ---------------------------------------
>
>
> > Proposed protocol-dns changes
> > -----------------------------
> >
> > Key: DIRSERVER-831
> > URL: https://issues.apache.org/jira/browse/DIRSERVER-831
> > Project: Directory ApacheDS
> > Issue Type: Improvement
> > Components: dns
> > Reporter: Richard Wallace
> > Assigned To: Enrique Rodriguez
> > Attachments: MX-QUERY.pdu, MX-RESPONSE.pdu, MX-TRAFFIC.libpcap,
> patch.diff
> >
> >
> > Hello,
> > Here are the first set of changes I'd like to contribute to the
> > protocol-dns subproject. Here's a list of things I've done.
> > 1) Converted the enumeration types ServiceType, ProtocolType,
> > RecordClass, OpCode, RecordType, MessageType and ResponseCode into
> > actual Java 5 enums. Because we need to encode and decode the actual
> > values we can't rely on the ordinals the compiler will assign to them,
> > so I've used a technique I found on the Java Specialists site
> > (http://www.javaspecialists.co.za/archive/newsletter.do?issue=113), to
> > efficiently do a conversion between enums and values with minimal code
> > duplication.
> > 2) Removed QuestionRecords and ResourceRecords classes since they were
> > really just type-safe wrappers around Lists and replaced their usage
> > with generic Lists.
> > 3) Moved any encoding and decoding code that was in the MINA
> > ProtocolEncoder and ProtocolDecoder to classes in the
> > o.a.d.s.dns.io.encoder and io.decoder packages called DnsMessageEncoder
> > and DnsMessageDecoder, respectively.
> > 4) Removed the dependency by the encoders and decoders in the
> > o.a.d.s.dns.io packages on MINA. The only thing they really used were
> > the ByteBuffers from MINA and it was a pretty simple task to just switch
> > to java.nio.ByteBuffers instead. The only hurdle I had to overcome was
> > in the allocation of temporary buffers for things like enecoding domain
> > names, which leads me to...
> > 5) Instead of creating (or having to pull them from the MINA ByteBuffer
> > pool) several ByteBuffers during encoding, I simply wrote directly to
> > the buffer that was passed in. From what I could tell, the main reason
> > for allocating the temporary buffers was to do the actual encoding of
> > the domain name, get the byte array that was written to the buffer,
> > write the length of the data to the actual ByteBuffer, then write the
> > byte array from the temporary ByteBuffer. Instead, what I did was to
> > record the position of the ByteBuffer, increment it by one, write the
> > data (the domain name for instance), find the difference between the
> > starting position + 1 and the current position, then go back to the
> > starting position and write the length of the data and finally jump back
> > to the end of the data and go onto the next bit of encoding. This
> > should be more efficient because we're not constantly having to get
> > ByteBuffers from a pool or have new ones allocated, and we also don't
> > have to then create byte arrays and have the data from those temporary
> > ByteBuffers read into the byte arrays.
> > 6) Moved all the (get|put)Unsigned(Byte|Short|Int) methods into a
> > utility class called ByteBufferUtil.
> > 7) Changed the DnsMessage.transactionId property to be an int because it
> > actually needs to be an unsigned short.
> > 8) Fixed a bug with decoding domain names when they are compressed. The
> > new position to jump to wasn't being calculated right all the time.
> > There also seemed to be an assumption that the first thing to do after
> > jumping was to read a label, but it could be the case that the new
> > position is another jump so we need to call recurseDomainName() right
> > after doing the jump in position.
> > 9) Updated existing tests to actually check that what is encoded and
> > decoded are correct. For this I also had to add equals() and hashCode()
> > methods to classes that didn't already have them, like DnsMessage,
> > ResourceRecordImpl, and others. I simply used the commons-lang equals
> > and hashCode builders for this because I've found them to be
> > tremendously useful for this in the past.
> > 10) Added additional test for MX query and response parsing. I used the
> > MX records from apache.org.
> > 11) Added decoders to make the tests added in (10) pass. these are the
> > IPv6RecordDecoder, MailExchangeRecordDecoder, AddressRecordDecoder, and
> > NameServerRecordDecoder.
> > That should cover it all. I'd like to add a few more decoders for
> > things like TXT and SOA records. That should cover about 90% of the
> > records in use on most DNS servers.
> > Then I'd like to get things separated a little bit more and create
> > subprojects within protocol-dns. I'm thinking something like
> > protocol-dns/
> > core/
> > mina-shared/
> > server/
> > shared/
> > mina/
> > store/
> > client/
> > core would contain all the DNS message and record types as well as the
> > decoders and encoders in dns.io right now. mina-shared would contain
> > the ProtocolCodec stuff in dns.protocol.
> > server/shared would contain the DnsConfiguration and other stuff that
> > would be shard among server implementations, whether they use MINA or
> > some other IO framework and whether they use ApacheDS for the store or
> > some other backend like Bind zone files.
> > server/mina would contain the DnsProtocolHandler from dns.protocol as
> > well as the DnsServer class itself.
> > server/store would contain the the backend store type stuff. It would
> > probably wind up being separate subprojects itself, one for LDAP, JDBC,
> > or Bind zone files.
> > client would obviously contain any code for developers to generate and
> > send queries to dns servers, and maybe an implementation of the dig
> > command line tool.
> > I wouldn't mind actually seeing this becoming a separate project of it's
> > own, like dns.apache.org. That would be really cool.
> > What do you think of these changes?
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6