Done and done. https://issues.apache.org/jira/browse/DIRSERVER-831
Rich Emmanuel Lecharny wrote: > Richard Wallace a écrit : > > Richard, > > many thanks for the patch. We will look at it, for sure. > > Just one little thing : could you fill a JIRA and add your patch > within ? This is mandatory, as you will have to transfer your IP to > Apache Foundation in the process. (sorry about the burden, but > Apache Foundation is very picky when it comes to IP :) > > Emmanuel > >> 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? >> >> Rich >> >> >
