[Twisted-Python] Twisted and Rendezvous
A few weeks ago, someone on the list mentioned Rendezvous support for Twisted. Curious, I picked up the Rendezvous specification documents, and got to hacking. What I've got so far is almost half a multicast DNS responder. The multicast DNS specification covers two main areas - asking other hosts for DNS records and serving out DNS records yourself. My code at the moment sends out queries and caches the responses in more or less the proper fashion, but does not respond to requests. The upshot of all this is that you can look things up over multicast DNS, but you can't advertise your own services. The code was written on Linux and tested against Mac OS X 10.2.6 (it'll never run on OS X or any other operating system that includes a Rendezvous service), and seems to Do The Right Thing. You can find a nice tarball here: http://members.optusnet.com.au/thristian/mDNS-0.5.tar.gz It contains the main module (mDNS.py) and a simple API demonstration (mDNS-test.py). There's lots of comments and docstrings, so it shouldn't be too hard to figure things out. If you're interested in Rendezvous support for Python, download it and have a play, then tell me what you think. -- ___________ ___________________________________ | Screwtape | http://livejournal.com/~thristian |______ _____ ___ __ _ _ _ _ | | "At 640x480 the world is peaceful 'cos noone can see well enough to aim" |
screwtape@froup.com writes:
A few weeks ago, someone on the list mentioned Rendezvous support for Twisted. Curious, I picked up the Rendezvous specification documents, and got to hacking.
That's cool. I'm not sure this falls into the same scope, but it occurred to me that it would be handy to have a DNS server that provided SRV records based upon registrations arriving from other server programs. If the application (say, an HTTP server) launched, started listening on an arbitrary port, then told the DNS/SRV server its service name and port number, the DNS server could start feeding appropriate SRV records for the application. I'd have the application keep a TCP connection open to the DNS server, and if that connection went down, the SRV record would be removed. It would work a lot like dynamic DNS, except per-application instead of per-host. just looking to plant some idea seeds.. -Brian
On Wed, Jul 30, 2003 at 02:56:47PM -0700, Brian Warner wrote:
screwtape@froup.com writes:
A few weeks ago, someone on the list mentioned Rendezvous support for Twisted. Curious, I picked up the Rendezvous specification documents, and got to hacking.
That's cool. I'm not sure this falls into the same scope, but it occurred to me that it would be handy to have a DNS server that provided SRV records based upon registrations arriving from other server programs. If the application (say, an HTTP server) launched, started listening on an arbitrary port, then told the DNS/SRV server its service name and port number, the DNS server could start feeding appropriate SRV records for the application.
Having a nice standard structure for SRV records is the purposes of the DNS-SD specification: http://tinyurl.com/ipj7 It turns out that a service like what you describe is going to be quite important for anyone who wants to write software that uses Rendezvous and doesn't require Mac OS X - as far as I can tell, only one application at a time per host can bind to a particular port on a multicast address, so if the OS doesn't supply an mDNS responder (or your language doesn't have bindings for the OS's mDNS responder) then applications will try and supply their own, and if two or more such applications try and run simultaneously, problems will occur. Thus some kind of server that sits on the network and offers mDNS services to applications who otherwise can't offer them, possibly working as a regular DNS server as well (configure it as the DNS server for the '.local' domain to make legacy apps magically look up multicast-DNS based host-names) would be an absolute boon. Note that you only need a multicast DNS proxy to serve DNS records - if another process on your host has already bound to the mDNS address and port, you can look up multicast DNS records by sending ordinary DNS packets to the mDNS port. In Twisted, it looks like this: from twisted.names import client resl = client.Resolver(servers=[('224.0.0.251', 5353)]) resl.lookupAddress('grundoon.local').addCallback(processAddress)
I'd have the application keep a TCP connection open to the DNS server, and if that connection went down, the SRV record would be removed. It would work a lot like dynamic DNS, except per-application instead of per-host.
The DNS-SD documentation mentions (in passing) various other ways of updating DNS rather than multicast DNS - manual update, scripts that use protocol-specific browsing to create a standard DNS zone file, or (as you mention) RFC 2136, Dynamic DNS Update. I had a brief, 20-second glance at the dynamic DNS RFC, and I can't see any reason you shouldn't be able to send per-application records to a dynamic DNS server. You'd still have hassles with cooperatively maintaining DNS records and so forth, of course... I like the idea of having a TCP connection alive (with keepalive packets, I assume) to maintain one's DNS records. You should be able to supply more than one record, of course (DNS-SD requires that you serve up a PTR record and a TXT record along with your SRV record), so the wire protocol might be a bit more complex. Hmm.. how stable and extensible and reliable is twisted.names?
just looking to plant some idea seeds.. -Brian
Always welcome. :) -- ___________ ___________________________________ | Screwtape | http://livejournal.com/~thristian |______ _____ ___ __ _ _ _ _ | | "We've got a lot in common" "I've always thought so, too." -- M*A*S*H |
participants (2)
-
Brian Warner -
screwtape＠froup.com