morgan/UxPlay
1
0
Fork 0
mirror of https://github.com/morgan9e/UxPlay synced 2026-04-14 00:04:13 +09:00
Code Issues Packages Projects Releases Wiki Activity

Update README (beacon details)

Browse Source
This commit is contained in:
fduncanh
2025-10-07 18:38:32 +09:00
committed by F. Duncanh
parent 37becd9906
commit 243efdeca4
3 changed files with 52 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
README.html
View File

@@ -1466,7 +1466,7 @@ below</strong>.</p>
XX is an IPv4 internet address (and port YY YY) of the UxPlay host
translated into hexadecimal octets. For example,
“<code>XX XX XX XX YY YY</code>” = “<code>C0 A8 01 FD 1B 58</code>”
means 192.168.2.253 port 0x1b58 (decimal value 7000). UxPlay must be
means 192.168.1.253 port 0x1b58 (decimal value 7000). UxPlay must be
able to receive messages on this TCP port at this address. The uxplay
option “<code>-p</code>” sets up uxplay to listen on the default port
7000 for these messages, as used in the example above. Otherwise the
@@ -1589,17 +1589,26 @@ restore DNS-SD service):</li>
<pre><code>$ sudo systemctl mask avahi-daemon.socket
$ sudo systemctl stop avahi-daemon</code></pre>
<p>An automated procedure for creating the beacon would presumably want
to switch it on when uxplay starts, and off when it stops. The 22-byte
file created when uxplay starts (and deleted when it stops) contains the
RAOP port as a uint16_t unsigned short, in the first 2 bytes, followed
by the uxplay PID as a uint32_t unsigned integer in the next 4 bytes,
then followed by up to the first 11 characters of the process name
(usually “uxplay”) as a null-terminated string, padded with zeroes to 16
bytes. The port data identifies the port on the Host that uxplay listens
on, which should be included along with the Host IPv4 address in the
advertisement broadcast by the beacon. The remaining data can be used to
check whether uxplay is actually running, including cases where it has
segfaulted and not deleted the file.</p>
to switch it on when uxplay starts, and off when it stops. It has the
task of determing a host IPv4 address that the client can use to reach
uxplay. The 22-byte file created when uxplay starts (and deleted when it
stops) contains the RAOP port as a uint16_t unsigned short, in the first
2 bytes, followed by the uxplay PID as a uint32_t unsigned integer in
the next 4 bytes, then followed by up to the first 15 characters of the
process name (usually “uxplay”) as a null-terminated string, padded with
zeroes to 16 bytes. The port data identifies the port on the Host that
uxplay listens on, which should be included along with the Host IPv4
address in the advertisement broadcast by the beacon. The path to this
file is needed as the only input by the procedure when it is started.
The presence of the file should be checked at regular intervals (once
per second?). If it is absent, uxplay has stopped running, but if it
exists the process ID and process name of that PID should be checked to
handle cases where a new uxplay process has started, or if uxplay has
exited abnormally and failed to delete the file. (While it is probably
not an important use case, the possibility of concurrent uxplay
processes listening on different ports and writing different files could
be handled: the advertising protocol allows cycling between different
messages.)</p>
<p>This method above creates a beacon that identifies itself with a
“public Advertising Address” (the MAC hardware address of the Bluetooth
device). An Apple TV uses a private random address. If you wish to do

19
README.md
View File

@@ -1478,7 +1478,7 @@ is not used in the simple manual method for creating a beacon described below**
Bluetooth LE Service discovery uses a "beacon" broadcasting a simple 14-byte
advertisement "`0D FF 4C 00 09 08 13 30 XX XX XX XX YY YY`" where XX XX XX XX is an IPv4 internet
address (and port YY YY) of the UxPlay host translated into hexadecimal octets. For
example, "`XX XX XX XX YY YY`" = "``C0 A8 01 FD 1B 58``" means 192.168.2.253 port 0x1b58 (decimal value 7000). UxPlay
example, "`XX XX XX XX YY YY`" = "``C0 A8 01 FD 1B 58``" means 192.168.1.253 port 0x1b58 (decimal value 7000). UxPlay
must be able to receive messages on this TCP port at this
address. The uxplay option "`-p`" sets up uxplay to listen on the default port 7000 for these messages, as used in the
example above. Otherwise the port in the beacon message should
@@ -1595,19 +1595,20 @@ $ sudo systemctl mask avahi-daemon.socket
$ sudo systemctl stop avahi-daemon
```
An automated procedure for creating the beacon would presumably want to switch it on when uxplay starts, and off when it
stops. The 22-byte file created when uxplay starts (and deleted when it stops) contains the RAOP port as a uint16_t unsigned short,
stops. It has the task of determing a host IPv4 address that the client can use to reach uxplay.
The 22-byte file created when uxplay starts (and deleted when it stops) contains the RAOP port as a uint16_t unsigned short,
in the first 2 bytes, followed by
the uxplay PID as a uint32_t unsigned integer in the next 4 bytes, then
followed by up to the first
11 characters of the process name (usually "uxplay") as a null-terminated string, padded with zeroes to 16 bytes. The port data
15 characters of the process name (usually "uxplay") as a null-terminated string, padded with zeroes to 16 bytes. The port data
identifies the port on the Host that uxplay listens on, which should be included along with the Host IPv4 address
in the advertisement broadcast by the beacon. The remaining data can be used to check
whether uxplay is actually running, including cases where it has segfaulted and not deleted the file.
in the advertisement broadcast by the beacon. The path to this file is needed as the only input by the procedure when it is started.
The presence of the file should be checked at regular intervals (once per second?). If it is absent, uxplay has stopped running,
but if it exists the process ID and process name of that PID should be checked to handle cases where a new uxplay process has
started, or if uxplay has exited abnormally and failed to delete the file. (While it is probably not an important use case, the possibility of
concurrent uxplay processes listening on different ports and writing different files could be handled: the advertising protocol allows
cycling between different messages.)
This method above creates a beacon that identifies itself with a "public Advertising Address" (the MAC hardware address of
the Bluetooth device). An Apple TV uses a private random address. If you wish to do that, change the sixth octet (the one following `0x03`)

33
README.txt
View File

@@ -1507,7 +1507,7 @@ Bluetooth LE Service discovery uses a "beacon" broadcasting a simple
14-byte advertisement "`0D FF 4C 00 09 08 13 30 XX XX XX XX YY YY`"
where XX XX XX XX is an IPv4 internet address (and port YY YY) of the
UxPlay host translated into hexadecimal octets. For example,
"`XX XX XX XX YY YY`" = "`C0 A8 01 FD 1B 58`" means 192.168.2.253 port
"`XX XX XX XX YY YY`" = "`C0 A8 01 FD 1B 58`" means 192.168.1.253 port
0x1b58 (decimal value 7000). UxPlay must be able to receive messages on
this TCP port at this address. The uxplay option "`-p`" sets up uxplay
to listen on the default port 7000 for these messages, as used in the
@@ -1644,17 +1644,26 @@ the beacon, use this command to send the 1-byte message "`0x00`" =
$ sudo systemctl stop avahi-daemon
An automated procedure for creating the beacon would presumably want to
switch it on when uxplay starts, and off when it stops. The 22-byte file
created when uxplay starts (and deleted when it stops) contains the RAOP
port as a uint16_t unsigned short, in the first 2 bytes, followed by the
uxplay PID as a uint32_t unsigned integer in the next 4 bytes, then
followed by up to the first 11 characters of the process name (usually
"uxplay") as a null-terminated string, padded with zeroes to 16 bytes.
The port data identifies the port on the Host that uxplay listens on,
which should be included along with the Host IPv4 address in the
advertisement broadcast by the beacon. The remaining data can be used to
check whether uxplay is actually running, including cases where it has
segfaulted and not deleted the file.
switch it on when uxplay starts, and off when it stops. It has the task
of determing a host IPv4 address that the client can use to reach
uxplay. The 22-byte file created when uxplay starts (and deleted when it
stops) contains the RAOP port as a uint16_t unsigned short, in the first
2 bytes, followed by the uxplay PID as a uint32_t unsigned integer in
the next 4 bytes, then followed by up to the first 15 characters of the
process name (usually "uxplay") as a null-terminated string, padded with
zeroes to 16 bytes. The port data identifies the port on the Host that
uxplay listens on, which should be included along with the Host IPv4
address in the advertisement broadcast by the beacon. The path to this
file is needed as the only input by the procedure when it is started.
The presence of the file should be checked at regular intervals (once
per second?). If it is absent, uxplay has stopped running, but if it
exists the process ID and process name of that PID should be checked to
handle cases where a new uxplay process has started, or if uxplay has
exited abnormally and failed to delete the file. (While it is probably
not an important use case, the possibility of concurrent uxplay
processes listening on different ports and writing different files could
be handled: the advertising protocol allows cycling between different
messages.)
This method above creates a beacon that identifies itself with a "public
Advertising Address" (the MAC hardware address of the Bluetooth device).