Article:		jRendezvous: Java and Rendezvous Working Together
Subject:		server patch broke jrendezvous?
Date:		2003-10-21 20:50:29
From:		anonymous2
hi seth, I think your server patch broke jrendezvous when it is used to discover services which aren't already responded by another server (ie the apache mod). in ServiceInfo.java you have added a [String server] to hold the name of the server which is handy for vhosts I think, but you can't key on that value in the DNS cache. the problem is that Rendezvous.handleQuery() populates the TYPE_A dns record with q.name (the rendezvous style name) as a key, and in ServiceInfo.updateRecord() you've changed the comparison to check it against the server name. I managed to get your code to resolve non jrendezvous services (tested with iStorm, apache and subEthaEdit), but couldn't make it resolve the service I was supplying (ie using jrendezvous as the only responder). changing some of these comparisons back to only using the rendezvous name solved the problem. I roughly understand what you were trying to do by adding the server field, but it doesn't affect the project I'm working on so I'll leave it up to you to try to find the best overall solution. perhaps that's what the "text" field was for? you can always pack more info into props.... if you'd like a copy of my source files let me know..

Showing messages 1 through 3 of 3.

• server patch broke jrendezvous?
  2003-10-22 01:24:12  sethladd1 [View]
  
  
  Hi,
  
  It's quite possible that the "patch" I provide only does handle that one case. I'm glad you found a way around it. Honestly I haven't approached this topic in a long time. I hope one day someone is able to collect all these patches and knowledge and release a new version of the library. It looks like people find it useful!
  
  Thanks,
  Seth
• server patch broke jrendezvous?
  2003-10-22 15:14:37  anonymous2 [View]
  
  
  hi seth, after looking through your changes a bit more I don't think I entirely understand your motivation to make the changes you did. your changes make it so tomcat returns an address such as
  http://foo.example.com
  rather than
  http://seth-ladds-computer.local./index.html
  
  however I'm not sure this is a useful change for two reasons:
  (a) mod_apache_rendezvous does not exhibit this behaviour, so why
  should tomcat try to do something different?
  (b) and more importantly any browser capable of doing rendezvous
  service discovery should be quite able to handle a URL
  of the second type. you say on page one of the article:
  "While this server name resolves to a physical IP address,
  clients should never cache that address. Rendezvous works so
  well because services may move around on the network, even
  changing IP addresses. Clients should cache the Service
  Instance Name instead, allowing the service the flexibility
  of movement."
  from that I understand that the _correct url for this service
  is the latter type, as it will still be correct even if the
  service is no longer available on foo.example.com. I guess
  the argument could be made that seth-ladds-computer might
  not always be valid either, but one would think that if you've
  found the resource via rendezvous, you continue to locate it
  in that manner, and if you've found the resource via some other
  means then you should stick with that access type.
• server patch broke jrendezvous?
  2003-10-23 00:56:18  anonymous2 [View]
  
  
  ohh man, this is a mess. I don't know if I can fix this without spending some solid time with the zeroconf protocol spec (which I can't seem to find) and a lot of println()s. apparently you were on the right direction by adding the server field as that's what the TYPE_A records are keyed on. however this means that back in the Rendezvous class we need to register the TYPE_A dnsrecord using the server name rather than the service name. this causes some problems for later lookups in handleQuery() as services are queried by service name, not server name.