morgan/UxPlay
1
0
Fork 0
mirror of https://github.com/morgan9e/UxPlay synced 2026-04-14 16:24:29 +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.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).