One possible solution is a simple ack/nak packet.
RRRMike W9MDB
From: Bill Somerville <[email protected]>
To: [email protected]
Sent: Friday, June 10, 2016 6:17 AM
Subject: Re: [wsjt-devel] Request: WSJT-X UDP protocol extension to identify
decodes to will accept UDP reply command.
On 10/06/2016 05:10, Laurie, VK3AMA wrote:
I propose that the UDP protocol, specifically the decode packet, be extended to
include a Boolean flag that identifies if the decode will respond to a UDP
Reply command.
Not all CQ/QRZ decodes are supported by the UDP Reply command and it would be
beneficial if those decodes are easily identified (within the decode packet) as
not being acceptable by WSJT-X, rather than performing exception tests or
analysis of the decode string structure as is currently needed to identify
these unsuitable decodes.
Hi Laurie, that is not very easy, for example if the decodes are erased then
they are no longer capable of being replied. Bottom line is that the decision
to react to a decode on double click (or UDP reply message) is made at the time
it is done, not when the decode is received.
Yesterday I committed a change that will make the highlighting and the
response to UDP reply messages more consistent. Other than that you should just
send the reply packets and if WSJT-X does not respond then it should be safe to
assume that double clicking the same decode in WSJT-X would not do anything
either, with the exception that only general call *standard messages* will be
responded to via the UDP reply message. No one to my knowledge has complained
that double clicking some decodes in WSJT-X does not cause WSJT-X to react. If
JTAlert users are finding that a general call message is not being responded to
then they must put forward a case for making them standard messages. That is a
very difficult case to make because we cannot change the protocol without major
disruption. There are edge cases like the possible use of the E9 prefixes for
more flexible CQ calls, this is where change should be requested rather than
expecting WSJT-X guess the intent of various free text messages.
73
Bill
G4WJS.
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
