Commit Graph

11 Commits

Author SHA1 Message Date
Trustin Lee
c27c487dc9 Revamp DNS codec
Motivation:

There are various known issues in netty-codec-dns:

- Message types are not interfaces, which can make it difficult for a
  user to implement his/her own message implementation.
- Some class names and field names do not match with the terms in the
  RFC.
- The support for decoding a DNS record was limited. A user had to
  encode and decode by him/herself.
- The separation of DnsHeader from DnsMessage was unnecessary, although
  it is fine conceptually.
- Buffer leak caused by DnsMessage was difficult to analyze, because the
  leak detector tracks down the underlying ByteBuf rather than the
  DnsMessage itself.
- DnsMessage assumes DNS-over-UDP.
- To send an EDNS message, a user have to create a new DNS record class
  instance unnecessarily.

Modifications:

- Make all message types interfaces and add default implementations
- Rename some classes, properties, and constants to match the RFCs
  - DnsResource -> DnsRecord
  - DnsType -> DnsRecordType
  - and many more
- Remove DnsClass and use an integer to support EDNS better
- Add DnsRecordEncoder/DnsRecordDecoder and their default
  implementations
  - DnsRecord does not require RDATA to be ByteBuf anymore.
  - Add DnsRawRecord as the catch-all record type
- Merge DnsHeader into DnsMessage
- Make ResourceLeakDetector track AbstractDnsMessage
- Remove DnsMessage.sender/recipient properties
  - Wrap DnsMessage with AddressedEnvelope
  - Add DatagramDnsQuest and DatagramDnsResponse for ease of use
  - Rename DnsQueryEncoder to DatagramDnsQueryEncoder
  - Rename DnsResponseDecoder to DatagramDnsResponseDecoder
- Miscellaneous changes
  - Add StringUtil.TAB

Result:

- Cleaner APi
- Can support DNS-over-TCP more easily in the future
- Reduced memory footprint in the default DnsQuery/Response
  implementations
- Better leak tracking for DnsMessages
- Possibility to introduce new DnsRecord types in the future and provide
  full record encoder/decoder implementation.
- No unnecessary instantiation for an EDNS pseudo resource record
2015-05-01 11:34:52 +09:00
Norman Maurer
a0ca605425 [maven-release-plugin] prepare for next development iteration 2015-03-03 08:30:59 -05:00
Norman Maurer
51a90ee2f5 [maven-release-plugin] prepare release netty-5.0.0.Alpha2 2015-03-03 08:27:16 -05:00
Trustin Lee
7aa9480cc6 Remove thepiratebay.se from the test domain list
.. due to its instability
2014-12-22 22:35:58 +09:00
Trustin Lee
216cbd9e31 Fix Java 6 compatibility issue in DnsNameResolver
Related: #3173

Motivation:

DnsNameResolver was using InetSocketAddress.getHostString() which is
only available since Java 7.

Modifications:

Use InetSocketAddress.getHostName() in lieu of getHostString() when the
current Java version is less than 7.

Result:

DnsNameResolver runs fine on Java 6.
2014-12-06 22:33:45 +09:00
Jay
7b39968f57 Check the bindFuture before writing a DNS query
Related: #3149

Motivation:

DnsQueryContext, using the DatagramChannel bound in DnsNameResolver,
blindly writes to the channel without checking the bind future for
success.

Modifications:

Check the bindFuture before writing a DNS query to a DatagramChannel

Result:

Bug fixed
2014-12-01 19:44:25 +09:00
Trustin Lee
e30839a1be Improve DnsNameResolverTest.testResolveA()
Motivation:

DnsNameResolver.testResolveA() tests if the cache works as well as the usual DNS protocol test.  To ensure the result from the cache is identical to the result without cache, it compares the two Maps which contain the result of cached/uncached resolution.  The comparison of two Maps yields an expected behavior, but the output of the comparison on failure is often unreadable due to its long length.

Modifications:

Compare entry-by-entry for more comprehensible test failure output

Result:

When failure occurs, it's easier to see which domain was the cause of the problem.
2014-10-25 17:29:59 +09:00
Trustin Lee
29a847587f Fix another resource leak in DnsNameResolver
- Fix a bug in cache expiration task; wrong object was being released
- Added more sanity checks when caching an entry
2014-10-17 11:38:43 +09:00
Trustin Lee
5904c47316 Fix the deprecation warning in DnsNameResolver 2014-10-16 17:57:10 +09:00
Trustin Lee
c5bbd3c318 Fix resource leak in DnsNameResolver 2014-10-16 17:56:12 +09:00
Trustin Lee
fa248cecb5 Name resolver API and DNS-based name resolver
Motivation:

So far, we relied on the domain name resolution mechanism provided by
JDK.  It served its purpose very well, but had the following
shortcomings:

- Domain name resolution is performed in a blocking manner.
  This becomes a problem when a user has to connect to thousands of
  different hosts. e.g. web crawlers
- It is impossible to employ an alternative cache/retry policy.
  e.g. lower/upper bound in TTL, round-robin
- It is impossible to employ an alternative name resolution mechanism.
  e.g. Zookeeper-based name resolver

Modification:

- Add the resolver API in the new module: netty-resolver
- Implement the DNS-based resolver: netty-resolver-dns
  .. which uses netty-codec-dns
- Make ChannelFactory reusable because it's now used by
  io.netty.bootstrap, io.netty.resolver.dns, and potentially by other
  modules in the future
  - Move ChannelFactory from io.netty.bootstrap to io.netty.channel
  - Deprecate the old ChannelFactory
  - Add ReflectiveChannelFactory

Result:

It is trivial to resolve a large number of domain names asynchronously.
2014-10-16 17:10:36 +09:00