andriydruk / RxDNSSD

Android version of mDNSResponder
Apache License 2.0
298 stars 75 forks source link

RxDNSSD Issues. #73

Open swy0710 opened 5 years ago

swy0710 commented 5 years ago

I am using jmdns to find devices. However, there is a problem that the device is not found sometimes, so I am wondering whether to use RxDNSSD.

I have tested the RxDNSSD and found the following problem.

  1. Rx2DnssdEmbedded requires a long device search. It takes about 30 ~ 60 seconds long. It seems to be inconvenient to usability if it takes a long time, and it seems that I can not use it.
  2. Readme states that Rx2DnssdBindable does not work on some Samsung phones, but I have not been able to reproduce it yet and I have not been able to figure out which part is the problem. Could you tell me which part is the problem? I am considering whether to use Rx2DnssdEmbedded or jmdns with exception handling.
  3. I wonder if IPv6 is supported. (As a result of my testing, I did not search for devices in IPv6 only network.)

Thanks in advance for your advice.

andriydruk commented 5 years ago

Hi

  1. 30-60 sec it's not ok. Do you use a sample from this repo or build own? Could you also check this app Service Browser? Delay could be a 1-2 sec, but not 30. Please write on what device do you test?

  2. Rx2DnssdBindable relay on non-public API - mDNSResponder daemon, there is no CTS test for the device maker to check this. Samsung in 4.3 just break it, in 5.0 it fixed again. You can use it on your own risk.

  3. This probably should work just because of mDNSResponder support it. There is could be an issue if your device doesn't support ipv6. Please write on what device do you test?

PS: did you consider to use NSDManager from Android instead of jmdns?

swy0710 commented 5 years ago

@andriydruk Thank you for quick response.

First of all, I am testing with Pixel2 and it is the same phenomenon in all my phones. (Samsung Galaxy note 8, LG V50, Pixel1, etc.)

  1. The first search is fast, but whenever I stop/start repeatedly, the search takes longer.
  2. Is this happening only in Samsung in 4.3? If it can not be reproduced on other phones, it would be wise to use Rx2DnssdBindable.
  3. I search very intermittently, but I think it is almost not.

PS: Using NSDManager causes a TXT Record issue. So I can not use NSDManager.

andriydruk commented 5 years ago
  1. Could you write a test that reproduces this issue?
  2. I don't know, potentially every device maker can break it. Every new update of Android OS can break it. You can use it on your own risk.
  3. Ok, I will check IPv6 networks
  4. NSDManager support [TXT Record from API 21](https://developer.android.com/reference/android/net/nsd/NsdServiceInfo.html#getAttributes())
swy0710 commented 5 years ago

@andriydruk

  1. I tested it here with a sample app in this repository by repeatedly clicking startBrowsing and stopBrowsing. I click startBrowsing first, and when the device is found, I click stopBrowsing and then click startBrowsing again. Repeatedly as above, the device will be found periodically late.

  2. Could I possibly handle the error with a try catch?

  3. Thanks for your check.

  4. I know that NSDManager supports TXT Record. However, as a result of my testing, I can not get the data because of failing to resolve periodically.

swy0710 commented 5 years ago

@andriydruk

I didn't change any code except for a regType for my device. I can get a response in 1 ~ 2 sec with Rx2DnssdBindable but 20 ~ 60 sec with Rx2DnssdEmbedded if it is late.

The log for Rx2DnssdEmbedded is like below. Browsing start time : 10:53:10 Device found time : 10:53:29

06-21 10:53:10.887 I 24417 DNSSDEmbedded already started 06-21 10:53:10.888 E 24417 DNSSD browse() in DNSSD 06-21 10:53:29.000 E 24417 DNSSD serviceFound() in DNSSD 06-21 10:53:29.002 I 24417 DNSSDEmbedded already started 06-21 10:53:29.002 E 24417 DNSSD resolve() in DNSSD 06-21 10:53:29.060 E 24417 DNSSD serviceResolved() in DNSSD 06-21 10:53:29.062 I 24417 DNSSDEmbedded already started 06-21 10:53:29.062 E 24417 DNSSD queryRecord() in DNSSD 06-21 10:53:29.063 I 24417 DNSSDEmbedded already started 06-21 10:53:29.063 E 24417 DNSSD queryRecord() in DNSSD 06-21 10:53:29.082 E 24417 DNSSD queryAnswered() in DNSSD

Xerusial commented 5 years ago

I can confirm the extension of loading time when repeatedly calling start/stop. Also a similar issue is with hosting a service. If one repeatedly starts and stops DNSSDEmbedded, the serviceRegistered callback is not called anymore. Scanning tested on Android 6 & 9, service registration on 8.

Xerusial commented 5 years ago

So the registration seems to be not working, if the last service is still running (but to be closed). A listener on socket.stop() would be great here to check, if the old service terminated already.

Xerusial commented 5 years ago

Service browsing shows a very strange behavior. Sometimes it is really fast and sometimes it just takes ages.

Xerusial commented 5 years ago

Holy shots the bindable version is fast :+1: No problems on this one...

swy0710 commented 5 years ago

@PSGXerus Bindable version is really fast! But there could be a browsing problem with some samsung phones.

Xerusial commented 5 years ago

But the bindable version never delivers a callback on a service registration. And now I got old services opened somewhere and I cant unregister them any more

Xerusial commented 5 years ago

@PSGXerus Bindable version is really fast! But there could be a browsing problem with some samsung phones.

yea. So @andriydruk if you could fix the embedded version by any chance, this would be great. If we can help somehow, let us know. I also noticed your app on the play store has got the same issue.

Xerusial commented 5 years ago

Also happens sometimes with multiple restarts:

I/DNSSDEmbedded: init I/DNSSDEmbedded: start A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x28 in tid 10201 (DNS-SDEmbedded)

Xerusial commented 5 years ago

I considered completely switching to the bindable version till the embedded is fixed, but it can't register services.

Xerusial commented 5 years ago

I considered completely switching to the bindable version till the embedded is fixed, but it can't register services.

Ok, the registration with the bindable version works. Somehow the buggy DNSSDEmbedded cloaked my phone or router. After restart of both and clean install of my app, registration with the bindable version works flawless.

swy0710 commented 5 years ago

@andriydruk How long will it take to resolve the issue? I'm looking forward to using this library.

abdur999 commented 3 years ago

com.github.druk.dnssd.AppleDNSSDException: DNS-SD Error -65540: BAD_PARAM

This is my cod. any issue? public void discover() { clear(); mRxDnssd = new Rx2DnssdEmbedded(this.mContext);

    Log.d("TAG", "Service Discover called from NsdHelper");
    mDisposable = mRxDnssd.browse("_services._dns-sd._udp", "local.")
        .compose(mRxDnssd.resolve())
        .compose(mRxDnssd.queryIPRecords())
        .subscribeOn(Schedulers.io())
        .observeOn(AndroidSchedulers.mainThread())
        .subscribe(bonjourService -> {
            Log.d("TAG", bonjourService.toString());
            if (bonjourService.isLost()) {
                Log.d(TAG, "Service discovery failed");
            } else {
                Log.d(TAG, "Service discovery found");
                serviceArr.add(bonjourService);
                handler.networkDiscover(serviceArr);
            }
        }, throwable -> Log.e("TAG", " discover error is", throwable));

}

public void clear()
{
    if (mDisposable != null) {
        mDisposable.dispose();
    }

    mDisposable = null;
}

Screenshot 2021-07-09 at 6 14 36 PM

andriydruk commented 3 years ago

@abdur999 Please try Rx2DnssdBindable