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.
@aprsfi unfortunately, the use of these transfer protocols significantly closes the possibility of developing it. In the case of WSJTX, the protocol is well described, it would also have to be defined how to distinguish whether it is a DNS-SD record for a WSJTX-like application, or a Logging app that receives the WSJTX log. In the case of N1MM and XML, the format is not well described. In general, developers will not try to extend the capability beyond their applications.
@aprsfi This should be solved by ADIF developer group how to pack the ADIF record.
@aprsfi But as I wrote above. It is very interesting idea and I would like to see it continue to develop
@ok1mlg Yep. But I think, for that to happen, some active developers of actual applications need to be active about it, demonstrate the need, provide proof-of-concept implementations.
It might also make sense to use HTTP for exchanging the message blobs, instead of sending UDP frames and hoping they actually get delivered and processed. It'd allow returning meaningful error codes too.
@aprsfi it's not about using UDP or HTTP. Each protocol has its advantages and disadvantages and it is up to the developer to evaluate the pros and cons. Let's go back to the adoption of DNS-SD, I see it as a very good idea to "simplify" applications.