On 10/03/2021 16:50, KT7AZ wrote:
I can speak about how JTAlert and WSJT-X exchange information.
WSJT-X instances are configured to send information packets (UDP datagrams) to a specified server application (an IP address or host name along with a service port number), that server listens on the host and service port and can be JTAlert. The data packets include each decode as it happens, changes in key status values like mode, and other dynamic status information like frequency etc.. The server may also reply to these messages with other messages that can "drive" WSJT-X in a few specific ways, like initiating a QSO with a station previously decode calling CQ. The protocol optionally allows for multiple servers to interoperate with WSJT-X instances sharing the same server service port number by using a technique called multicast group addressing.
I am not an expert on how JTAlert interoperates with HRD, but I believe the HRD logbook is a TCP/IP server that other applications, like JTAlert, can feed logged QSO information. I also believe HRD does not provide a logbook lookup facility via that channel, so JTAlert may also open the HRD logbook database directly for read-only access to query worked before status etc..
Rather confusingly HRD is also able to take network traffic sent from WSJT-X, although that feed was never intended for that purpose. That feed has only the basic ADIF information of logged QSOs accepted in WSJT-X. This channel is via UDP sent to a different host and service port pair specified in WSJT-X, currently named as the "Secondary UDP Server (deprecated)" in "Settings->Reporting", deprecated because the N1MM Logger+ application, for which it was originally intended, now use the preferred UDP feed I mention above.