9

I am working to build an application that uses Network Service Discovery. I have followed up this post http://developer.android.com/training/connect-devices-wirelessly/nsd-wifi-direct.html and the application is working but I have a couple of questions based on the code shown below.

WifiP2pDnsSdServiceInfo.newInstance("_test", "_presence._tcp", record);

It seems like the record cannot hold much of data. For instance if the record size is 20, the info is not dispatched. Can you tell me about the size limitation? How much of data can I send?

I am not clear about the available service types like _presence._tcp. Is it vendor specific? A list of the supported service types will be nice to know. Does the service type dictate the amount of info I can send? If so, which service types are preferable for sending a good sized map.

An update: I have checked this draft at http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt and please see section 6.2 DNS-SD TXT Record Size. It looks like the size limit is small as stated "The total size of a typical DNS-SD TXT record is intended to be small -- 200 bytes or less. In cases where more data is justified (e.g. LPR printing [BJP]), keeping the total size under 400 bytes should allow it to fit in a single 512-byte DNS message ". Any thoughts?

ZakiMak
  • 2,072
  • 2
  • 17
  • 26
  • 1
    Perhaps, my [answer on the related question](http://stackoverflow.com/a/19356052/1102014) may be helpful. – Stan Nov 11 '13 at 19:03

2 Answers2

4

I'm a newbie in Java/Android but I was able to conduct some experiments.

The DNS Service API expects a map of <String, String> for record. If we want to focus solely on data, we use only one pair and set the key to "". In this case, you can transfer 92 characters:

record.put("", "12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012");

This is the maximum you can send (or better said, receive) over the air. I was curious what happens if I want to send some binary data. Using a byte[] array instead of String is not a good idea (crash) so we have to stick with strings:

record.put("", "\u1234\u5678\u9012\u3456\u7890\u1234\u5678\u9012\u3456\u7890\u1234\u5678\u9012\u3456\u7890\u1234\u5678\u9012\u3456\u7890\u1234\u5678\u9012\u1234\u5678\u9012\u3456\u7890\u1234\u5678");

Interestingly, this is the maximum you can send (30 Unicode characters/60 bytes). The reason is that the Wi-Fi API seems to convert all strings to UTF-32, i.e. while the first example used ASCII values only (i.e. in UTF-32 one char = one byte), the second example used all values from range of 0x8000 - 0xffff (i.e. in UTF-32 one char = 3 bytes).

If you do the math, you see 30 x 3 bytes = 90 bytes, i.e. there ought to be 2 bytes (characters) left and indeeed:

record.put("", "\u1234\u5678\u9012\u3456\u7890\u1234\u5678\u9012\u3456\u7890\u1234\u5678\u9012\u3456\u7890\u1234\u5678\u9012\u3456\u7890\u1234\u5678\u9012\u1234\u5678\u9012\u3456\u7890\u1234\u5678\u0031\u0032");

still works, reaching the limit of 92 bytes. Please note you can't use the spare two bytes for generic data (i.e. something like 0x1234) because it gets encoded as 3-byte value and this wont work anymore.

Interesting question is whether the data is better encoded using the binary method or using something like base64. Wikipedia says base64 converts three octets into four encoded characters, i.e. for 92 ASCII characters we'd get 69 bytes of data, rendering base64 much more efficient for this small set of data.

Miro Kropacek
  • 2,742
  • 4
  • 26
  • 41
1

As far as I know, the Android NSD Api lacks proper support for txt records.

It is wat prompted me to switch to jmdns for a recent project in which I needed to use the txtrecords.

More information about using jmdns can be found here: http://home.heeere.com/tech-androidjmdns.html

Daniel Blake
  • 44
  • 4