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
<[email protected]> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
