[Xen-bugs] [Bug 21] New: Service detection through mDNS does not work

[bugzilla-daemon@xxxxxxxxxxxxxxxxxxx]

http://bugzilla.xensource.com/cgi-bin/bugzilla/show_bug.cgi?id=21

           Summary: Service detection through mDNS does not work
           Product: Xen
           Version: 2.0
          Platform: x86
        OS/Version: Linux
            Status: NEW
          Severity: critical
          Priority: P1
         Component: Hypervisor
        AssignedTo: xen-bugs@xxxxxxxxxxxxxxxxxxx
        ReportedBy: niraj@xxxxxxxxxxxxx
                CC: niraj@xxxxxxxxxxxxx


Problem Statement:
----------------
"hashi", a server running DOM-0 has a mDNSResponder daemon to advertise the
services available on the server. From a client m/c, either through xenman
GUI Java Code or by using jmdns.jar (mDNS Service Browser in Java),
the detection of services advertised on hashi are not detected reiliably.
When mDNSResponder is started on hashi, the detection of services works
initially. After about 4-5 mintues, mDNSResponder stops responding to clients.
A local mDNS client running on hashi detects the services in a reliable fashion,
the problem arises only for the clients  running on a different m/c on
the network.

Analysis:
--------
Experimented with mDNSResponder (comes bundled with RedHat) and also with
mDNSResponderPosix (downloaded from Apple site). Found some differences
related to the nature of responses between the two. But the stated problem
exists on both.

1) Analysis with mDNSResponderPosix (downloaded from Apple site):
  --------------------------------------------------------------
(Instructions to download and build the source code are given towards the end.)
Used verbose flag to get information about a stream of actions taken by the
daemon. When the daemon is started it behaves alright. Within 2-3 minutes,
the timeout value for "select" call w.r.t. read file descriptors starts
increasing exponentially.
FIRST MAJOR PROBLEM -  The interesing thing is that even
if there are input events (see 'HOW DO WE KNOW THERE ARE EVENTS' section below),
the "select" call does not get awakened before the timout is over. The timeout
is taking precedence over the presence of read events.

SECOND MAJOR PROBLEM - When a new mDNS-Client is started initially it gets
responses from mDNSResponderPosix, but after some time (5-6 minutes)
mDNSResponderPosix does not receive any events from this client. If you kill
the client and restart it, mDNSResponderPosix will receive the events from the
newly created client for a limited duration but it will process them only after
the timeout in the "select" call expires. This timeout will be a large number
by the time you go through this cycle. That is why the newly created client
will not see the services immediately. You need to wait for some time to see the
detected services.

Repeated the same experiment by running mDNSResponderPosix and client on
standard Linux machines. The whole system worked alright. The "select" call
worked fine. mDNSResponderPosix was getting the events from the client reliably
and it processed them in a timely manner.

2) Analysis with mDNSResponder (bundled with RedHat):
-----------------------------------------------------
In this case also the observations were same. Only difference is that if you
restart the client, it does not detect the service. In the case above, 
restarting
a client detects the services.


CONCLUSION:
----------

This analysis leads us to believe that the undesirable characterstics of
mDNSResponderPosix are due to the fact that it is running under DOM-0.
HOW DO WE KNOW THERE ARE EVENTS PENDING FOR mDNSResponderPosix:
---------------------------------------------------------------
Kill a client and restart it on a remote Linux machine. Wait for some time,
you will see the advertised services. It proves that events were generated
but we do not know if they were delivered to mDNSResponderPosix immediately
or they were left unprocessed in some buffer.

How to download, compile, and use mDNSResponderPosix (downloaded from Apple 
Site):
----------------------------------------------------------------------------------

Downloaded source code from Apple site using the instructions described on the
following URL:

 http://the.taoofmac.com/space/HOWTO/Enable%20Rendezvous%20on%20Fedora%20Linux

Go to the mDNSPosix Directory and compile using 'make os=linux'. The binaries
will be in the 'build' directory. Copy build/mDNSResponderPosix and
build/mDNSClientPosix to hashi:/tmp.

Under hashi:/tmp create a service description file "Services.txt" with the
following contents:

Tweedlebug
_afpovertcp._tcp.
name=val1
548

Tweedlebug2
_afpovertcp._tcp. local.
name=val2name2=anotherattribute
548

tatami
_xenmon._tcp.
name=xenmon
1666

>From hashi:/tmp directory, run the following command to start the mDNS daemon:

./mDNSResponderPosix -v 2 -f Services.txt

"-v 2" makes it run in a verbose mode giving information about the actions taken
by the
daemon.

>From client linux machine on the network, use the following command to start
mDNS Browser

java -jar jmdns.jar -i 10.100.1.103      where ip address is of client linux m/c



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

_______________________________________________
Xen-bugs mailing list
Xen-bugs@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-bugs