The description in the WSJT-X source is using the terminology of WSJT-X as the server and anybody talking to it as clients.
There are simply messages from and to wsjt-x. You'll note that every message described shows Out/In capability.Out means from wsjt-x....In means to wsjt-x. The heartbeat is Out/In and expects one heartbeat message from a client as described in the message info. The response will be a heartbeat message too. de Mike W9MDB On Monday, October 14, 2019, 11:22:34 PM CDT, Michael Pittaro <mik...@lhrc.com> wrote: I've been playing around with the UDP server capability in wsjt-x, and I think I've got most of the lower level details figured out. However, I got blocked on the schema negotiation part, which raised a deeper question. I have been assuming wsjt-x is a server, and my code is a client. So I sent heartbeats like a client, and I was expecting some sort of response back, which never arrived. I definitely see traffic (heartbeats, decodes, status, etc.) from wsjt-x, using the WSJT-X client id. Digging deeper, it seems wsjt-x is acting more like a client. The docs also imply that. For example, The location message is described as in, allowing a 'server' to set the location. Logged ADIF is described as out, being sent to servers when a QSO is logged. The example message aggregator is also a server, listening to wsjt-x and other clients. I think I'm just missing something obvious here in terms of the frame of reference for client and server, and what the client/server model looks like. Should my code act like a client or a server? So far, I'm I'm using unicast, with just wsjt-x and my code running. mike, kj6vcp _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel