Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

JmDNS serviceListener update?

Help
helene
2011-09-26
2013-01-24
  • helene
    helene
    2011-09-26

    I have a question please.
    I'm running JmDNS implementation (3.4.1) in 2 machines: in machine1 I advertise a service, in machine2 I discover the services. I succeded to see any advertised service. Also, when I stop my osgi bundle running in machine1 (using the key word "close" and thus running the stop method in which I close the created jmdns instances), the jmdns instances are removed and the therefore the services of machine1. (which is the expected behavior)
    However, if the bundle of machine1 is not properly closed, like shutting down machine2 (therefore the stop method is not executed) the service of machine1 is persistent and I see it in machine2, although no more paquets are sent over the port 5353.
    This is ennoying for my application because I want the machine2 to be able to see that the services are removed if the source doen't send jmdns paquets anymore.
    Can you help me please?

    Best Regards,
    Helene

     
  • Pierre Frisch
    Pierre Frisch
    2011-09-28

    Hi Helene,

    I think you are bumping against the standard. mDNS implementation cache the result of queries like any DNS with a TTL (Time To Live). The default TTL is set to 1 hour by the standard, so a record is going to stay in the cache of any listening machine for an hour without need to ping the server again. The way the close works is that before closing we send an announcement with a TTL of 0 that essentially has the effect of purging the cache of listening machine. If the announcing machine crash or does not close properly there is no way to purge the cache before the TTL expires.

    Cheers

    Pierre

     
  • helene
    helene
    2011-09-28

    Thanks for your reply.. But if I change the constant TTL = 60 *60 to 5 *60 for example. I've tested it, it seems that it works fine.

     
  • Pierre Frisch
    Pierre Frisch
    2011-09-28

    You must think twice about doing this. The reason for this TTL is to reduce the chatter on the network.

    Pierre

     
  • helene
    helene
    2011-09-29

    Oh yeah, you are right. I'll have to compromise and choose the best TTL.
    Thanks