Connecting ham radio apps and devices together on a LAN is unnecessarily difficult. It has been too difficult even locally, on the same computer. Finding IP addresses and ports, and typing them in configurations, is something that is quite unnecessary in year 2024. We, the software developers, can do better, and enable Zeroconf / DNS-SD, and let users simply *pick* the services from a list.
Here's a list of ham zeroconf applications, and some implementation ideas:
https://github.com/hessu/aprs-specs/blob/master/hamradio-zeroconfig.md
@aprsfi interesting idea. however, I am not sure how it would work, for example, in case of Logging applications. Printers use IPP, email uses SMTP/IMAP. Unfortunately, there is no uniform protocol for exchanging QSOs. ADIF is only a exchange format, DNS-SD can provide an IP, port and a transmission protocol. However, how to pack ADIF in the transmission protocol can be defined differently by each software now.
@ok1mlg QSOs are often uploaded to log software using the format originally used by N1MM. Here's a screenshot from the wonderful RUMlogNG software, note the compatibility hints with MacLogger, N1MM & TR4W. It also listens for packets from WSJT-X on port 2258 (configurable!) but other apps than WSJT-X can also emit the same format.
A service announced with DNS-SD can also provide additional machine-readable details to clients in TXT records.
@ok1mlg So, for example, the logging app could announce _wsjt-x-data._udp saying it's listening for UDP data in WSJT-X format on port 2258, and with a TXT record saying "broadcasts=1" to indicate that it will also accept broadcasts, not just unicast packets to its IP.
WSJT-X and other compatible clients would then know that these packets could be sent to port 2258 and that they'd be received by the logging app, and the user could pick that app/port from a list of running logging apps shown.
@aprsfi @ok1mlg putting the ADIF rat-hole aside, I like how these kinds of broadcasts could facilitate self-assembly of small systems.
Strikes me some early attention to abuse cases could help, with a little RFC 2119 language so implementers know they SHOULD ask the user if they want to use that new component before doing so, MUST blocklist it for an hour or until the end of the session if they say no, and MAY provide a way to reset the blocklist manually.
@vk2tty Yeah, I'm not suggesting to implement fully automatic connection, but rather like it normally works:
When you go to the user interface view where you are going to to configure/connect to X, or use it, you get to select from a list of available services/devices instead of having to type in the IP and port. Requires user activity/intention to initiate the search.
When using it the next time it'll automatically connect to the same device even if it is has gotten a new, different IP.