morgan/UxPlay
1
0
Fork 0
mirror of https://github.com/morgan9e/UxPlay synced 2026-04-15 00:34:05 +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