Julien Vermillard ha scritto: > Hi, > I'm interested in a lightweight DNS server, I don't know much the DNS > byte level protocol, but I can help for the MINA part :)
Hi Julien, my first doubt is how to approach the dns resolution in MINA. DNS is a bit different from other protocols because most times it is not used directly as a communication protocol, but only as an helper to other protocols. I would start from use cases and here is a list of use cases for the dns library I can think now: 1) clients trying to identify a target for the connection (most protocols will only need the "IN A" lookup to resolve an host, smtp for example needs first an IN MX and then IN A lookup). 2) servers trying to check reverse resolvability of connecting hosts (IN PTR lookups) 3) a recursive dns server implementation trying to resolve some dns request on third party dns host. In every case we already have an ongoing connection (often mina based) on a different protocol that will require the asynchronous dns lookup. The dns resolution could happen on these transport layers: 1) a single tcp connection to the preferred server (or round robin on multiple servers) for each lookup 2) a shared tcp connection to the preferred server 3) a shared udp channel to the preferred server dnsjava already has a Message object used both for queries and for responses. A lookup in dns at an high level have this layers: LOOKUP: a lookup object managing caches for success and failures, recursion for CNAMEs, search paths, temporary/permanent error management: users of a dns library will often make a single call to this service and work with the result (even if it is a temporary error). This service requires a RESOLVER that will handle the real queries. RESOLVER: a resolver is the real client of the dns protocol. The arguments are the hostname (the dnsserver) and the transport to be used (UDP/TCP). You send a Message and you receive back either a response Message or an IOException (mostly a TimeoutException). EXTENDEDRESOLVER: this is a better resolver handling multiple hosts. It may use different strategies to use multiple servers and multiple resolvers to handle the queries. It may use round robin, it may use the server in a sequence or run the same query concurrently against multiple servers and take the fastest answer. This service depends on 1..N asynchronous resolvers. Currently in dnsjnio+dnsjava solution every of this layers has its own processing thread. One thread for each resolver, ohe thread for the extended resolver to manage the queues for resolvers, One thread for the lookup "executor". Moving to MINA I would like to also reduce the minimum threads, if possible. I think that for the Message part we can use dnsjava code directly (but here we'll have to deal with dnsjava bugs, so maybe it is better to clone the whole Message structure into a new package). For the "LOOKUP" service I already have ported the synchronous dnsjava lookup helper to an asynchronous service and it is mostly based on dnsjava BSD code and custom work from me. For the Resolvers instead I currently use the dnsjnio stuff that is MPL, so we should better write our own mina handler/filters/codecs from scratch. It seems the most basic part to start with is the simple resolver working on UDP. The simple resolver has a simple interface because you send messages and receive messages over a single connection. How to build the extended resolver on top of this? the extended resolver does not have a "connection" but instead rely on a collection of resolvers. Otherwise it expose the same service of the simple resolver. What is the best way to manage this with MINA? Should we start sandboxing some code? What is more appropriate? (JIRA attachment / a sandbox inside james or mina repositories / an apache lab project) Stefano
