[guardian-dev] Gilgamesh, FireChat etc

[Paul Gardner-Stephen]

Hello,

This sounds very usable, especially since we could advertise multiple
services.

It would be great if someone is able to make a proof-of-concept for this to
test the practical limits on Android.

Paul.

On Thu, Oct 9, 2014 at 6:38 PM, Michael Rogers <michael at briarproject.org>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 08/10/14 15:42, Nathan of Guardian wrote:
> > Great to hear... btw, I just realized we can use the WifiDirect
> > service discovery capability to send much longer data than the
> > current SSID/name method allows:
> >
> http://developer.android.com/training/connect-devices-wirelessly/nsd-wifi-direct.html
> >
> >
> >
> Not sure what the limits are, but it doesn't require you to
> > connect or join to be able to broadcast/listen for this info.
>
> Looks promising! I've found some scraps of information about limits:
>
> RFC 1035 section 3.2.1:
> The length of the RDATA in a DNS resource record is an unsigned 16-bit
> integer.
>
> Section 3.3:
> A character-string may be up to 256 bytes, including one byte to
> specify the length.
>
> Section 3.3.14:
> A TXT record's RDATA consists of one or more character-strings.
>
> RFC 4408 section 3.1.3:
> A single DNS TXT record can be comprised of more than one string. The
> maximum length of each string is 255 bytes (this is consistent with
> the above).
>
> Section 3.1.4:
> The total record size SHOULD be kept below 512 bytes to prevent
> clients from falling back to TCP. Records that don't fit within a
> single UDP packet MAY be ignored. (This applies to SPF, but we should
> bear in mind that similar limits may apply to Wi-Fi Direct for similar
> reasons.)
>
> I would speculate that each entry in the WifiP2pServiceInfo's string
> map is being translated into a character-string and RDATA consists of
> the concatenated character-strings. If we use single-character keys
> for the map, we can put up to 253 bytes of base64 (189 bytes of data)
> in each value.
>
> We may run into compatibility problems if we try to encode more than
> one max-length value in a single record... let's experiment with as
> many device combinations as possible.
>
> Cheers,
> Michael
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQEcBAEBCAAGBQJUNkJ6AAoJEBEET9GfxSfM+VkH/3QzoBPzDyLBm1T7Gwv2DGY5
> ifaN9g1+vVN2bFQHy4zIxeByfPPSJ9bipqBb+qGfrKyOarAoQK+wkZeYEESUiIxa
> kXK3Qv2u3lL5T8pA3iBhT5wNtY2QAHSM7TEm+gnagF/Mjm0GkCFSUJUxRGm2RJUq
> 1+UZAFqNU2LeUMPySU9CckAijLniTW5h4RibLmlRkn3xB+dcBaY3O3H0cjloXzIT
> r+PlnzwS4XGgcQWimt/Iul/UOv91dkcFwlFkVJjwIJSb4OZ1l3N/PM1FsZ8vNP3R
> uoq5joM2MOWlov+50cZmC9xUyRuS/9aC7Z0alvAIX0JFK1vNmvhJW6FC+EmmC8w=
> =QnJG
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20141009/c3560de6/attachment.html>