Re: [wsjt-devel] Request: WSJT-X UDP protocol extension to identify decodes to will accept UDP reply command.

[Black M. <mdb...@ya...>]

One possible solution is a simple ack/nak packet.
RRRMike W9MDB

      From: Bill Somerville <g4...@cl...>
 To: wsj...@li... 
 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
wsj...@li...
https://lists.sourceforge.net/lists/listinfo/wsjt-devel