A little about you
by AcaBen
You might also want to include a brief bio and a little bit about the progress for mod_rendezvous since we called for questions.
I'm a senior at Lawrence University, a small (~1,400) liberal arts school in Appleton, Wisconsin. I'm a mathematics major, mostly for the reason that I feel my school has a stronger math program than computer science. I've applied to 8 graduate schools (MIT, Berkeley, Stanford, CMU, UT Austin, UW Madison, UIUC and GA Tech) for next year, looking to earn my PhD in computer science with eventual career goals doing computer science research. If you count HyperCard, I began programming almost 12 years ago, moved on to c++ in high school, and have written a large variety of things in c, java, objective-c, php, python and other languages since. My most popular project of recent years was the AudioGalaxy client OpenAG which I wrote last year.
My interest in Rendezvous started at the last Apple's World Wide Developer's Conference (WWDC), but lay dormant until something as big as Safari finally used rendezvous. I learned the Apache API this summer when working for The Secure Trusted Operating System for which I prototyped several technologies, including implementing mod_ssl using Apple's SecureTransport. Lots more info is available for the curious at my website.
mod_rendezvous has not received much attention in the last couple weeks (due to school work), however a bug-fix release 0.5 is due out this weekend, and we'll just have to see what happens after that.
The Future
by seven5
Where do you see Rendezvous in the next 2 years?
Easy answer: Everywhere. It is my (perhaps naive) belief that it's only a matter of time before an mDNS responder ships in just about everything with an ethernet port. There is already a Java mDNS responder (jRendezvous) which works well, efforts are being made to finish Apple's mDNSResponder for POSIX, and I've heard of a group who is trying to add Rendezvous to the Linux kernel. I expect most printers will ship with a built in mDNS responder within 2 years. Basically, there *needs* to be a quick way to do device discovery on a network, and until now there has not been a well supported, multi-platform way. Unless Micro$oft comes up with some standard-breaking Rendezvous alternative (which isn't out of the question) I see Multicast DNS, and thus "Rendezvous" taking off substantially in the near future, and I plan to do everything I can do support that. I expect that in 2 years, you will plug a printer into the network and it will be at least immediately visible on every computer, if not automatically configured on every computer. The same goes for any other network device.
Rendezvous' local link limitation
by Anonymous Coward
As I understand Rendezvous, it uses multicast DNS for service discovery. Multicast DNS is only useful for the local link, that is, it is not routed. So mod_rendezvous is useful only to users on the same subnet as the web server. Is this accurate? Do you see this limitation changing?
Yes, that is mostly accurate. It actually used DNS-SD (DNS-ServiceDiscovery) on top of mDNS to do service discovery. Let me quote Apple's own website on this one:
Q: Does Rendezvous work across routers (between multiple subnets)?
A: No. The first release of DNS Service Discovery (DNS-SD) for Mac OS X concentrates on Multicast DNS (mDNS) for single-link networks because this is the environment worst served by current IP software. Future versions will add Dynamic Update and unicast query support.
Multicast DNS is intended for use on small networks with no infrastructure support, and intentionally uses link-local multicast. If a network has two links then it needs a bridge or router to connect those links, so by definition you now have a box that is (or should be) capable of providing some level of infrastructure support.
It is important to understand that DNS-SD is orthogonal to mDNS. You can use one without the other. In the example given above, the router that is connecting the two links should also include a DHCP server to assign addresses, and a little mini-DNS server which handles both standard DNS queries and Dynamic DNS Updates [ RFC 3007 ]. The devices offering services on that network then advertise their services by using Dynamic Update to register their service records with the mini-DNS server in the router, and clients looking for services use normal unicast DNS queries addressed to that server to retrieve those service records.
As the above FAQ suggests, this limit is changing. While mDNS is limited to Local-Link (since it's multi-cast), DNS-Service Discovery (DNS-SD) (where you resolve the DNS name _http._tcp.local., and get a full list of all http servers in the "local." domain) was designed to function off of the normal DNS protocol and conventional DNS Server. Thus eventually you should be able to resolve "_http._tcp.apple.com" and get a full list of all http servers in the apple.com domain when Rendezvous supports such queries and your DNS server is properly configured.
As Apple notes, the real need for mDNS is in ad hoc networking and subnet only functionality. Real server-arbitrated networks are designed for the rest of it, and DNS will continue to do its job of handing the "bigger picture," while mDNS will offer DNS to subnets and ad hoc networks. With DNS-SD, both of them are able to do service discovery.
For a better understanding of ZeroConf/Rendezvous I would refer you to:
Best Advice From Someone Else Since Release?
by Anonymous Coward
What is the best idea for mod_rendezvous from someone else you've heard since releasing it? The best tools are the ones that do something the author didn't intend and this has *HIGH* potential for that.
The best ideas I've received have come from Dirk-Willem van Gulik, a fellow programmer, who has helped me sort out a variety of issues with mod_rendezvous. Including some better configuration directives (better than those in 0.4), some design issues etc.
The best "non-intentional" use I've heard of is a man who emailed me to tell me that he is picking up consulting customers by sitting in cybercafes. He just leaves his TiBook open and running a mod_rendezvous enabled Apache, and waits for the potential customers to read his webpage and come find him ;-) I thought that was cool. Other customers have used it to distribute bookmarks to their subnet, or to advertise "group" pages for their workgroup, etc. I have several friends on campus here who find it useful for getting those on campus to finally see the sites they have running.
Other OS support?
by softkid
What would be needed to have this mod work on say linux and the BSDs? (because most apaches do run on such oses)
In short: not much. To do it "wrong" as a hack, would just take including the POSIX mDNSResponder code in mod_rendezvous itself. Unfortunately, that ends up very quickly with several mDNSResponders running on the same server (if other apps use the same hack). The "right" way to do it is to finish Apple's work and make a real, stand-alone, Inter-Process-Communication-capable POSIX mDNSResponder. Unfortunately, my time is limited, so the likelihood of you seeing me doing a *nix port alone is small. You'll notice I haven't kept up with my initially proposed timeline, midterms and other classwork saw to that.
That which remains between current mod_rendezvous and a linux implementation is the following:
1. Take Apple's POSIX mDNSResponder C code and add some form of IPC (i.e. sockets). (~8 hours)
2. Take Apple's libinfo, aka the DNSDiscovery API, (also opensource) and move it from machport dependance to using whatever IPC was used for the mDNSResponder code. (~8 hours)
3. Move mod_rendezvous down from the CFNetwork API to the lower DNSDiscovery API (~2 hours).
That's it. If anyone would be willing to help, just drop me a line, but without community support, it's not likely to happen soon. I've also heard of others already attempting independently, but have not made contact with them yet.
Other Rendezvous/ZeroConf Projects:
http://www.strangeberry.com/
http://zeroconf.sourceforge.net/
http://www.kernel.org/pub/software/network/zcip/
What's Next...?
by Cannonball
Now that Rendezvous and ZeroConf are taking off, what other uses do you see for a Rendezvous-enabled Apache? More importantly: what's next for you?
First of all, we need a more generic Rendezvous service registration built in to OS X and offered for other platforms -- for FTP, DNS, telnet, ssh, etc (a potential future project of mine). For Rendezvous-enabled Apache, I see TONS of uses, including on campuses like mine, in schools, in work places, for thing such as: local websites, distributing bookmarks, mobile websites (i.e. on the teacher's laptop), presentations (how cool would it be to be able to have your coworkers launch safari and follow along with your presentation on their laptop, use your pre-designed java applets, etc?) The possibilities are endless.
What's next for me?
I've at least temporarily moved on... to another programming interest of mine: music. I wrote a little Bitzi (www.bitzi.com) client (multimedia file identification) a week ago in about 3 hours. It's not released, but it due out soon. This Monday I sat down and added Rendezvous support to LimeWire -- enabling LimeWire clients to quickly discover all other LimeWire clients on their local subnet. I think this has HUGE implications for the Gnutella network... we'll have to wait and see. Hopefully my patch will be included in the next LimeWire release. I have other projects on the back burner which are due eventually as well. Most importantly, I am still trying to hold a 4.0 for this term, get into CS PhD programs for next year, and complete my honors project... in all my spare time ;-)
Apple's feedback
Have you received any feedback or other contact from Apple?
Yes, and no. I've had very limited contact with a couple Apple people regarding mod_rendezvous. No feedback per-say. I am much less convinced now that they are just waiting in the wings to release their own mod_rendezvous in 10.2.4, but since I haven't heard anything definite from Apple, I am not sure. I had the pleasure of hearing from Wilfredo Sanchez directly, which was kind of exciting, since he's done *a lot* of impressive work on Darwin over the years -- work I highly respect. I've also unfortunately received little feedback from Apple regarding my internship search ;-)
| 
