Topics

locked WSJT-X UDP -- piggyback messages to WSJT-X


Erik Icket
 

Hi Laurie,

I understand that the JTAlert development environment does not support UDP multicasting and you had to implement the rebroadcasting functionality as a workaround.
 
Would it be however be possible for JTAlert to piggyback the UDP traffic from "the application to which the rebroadcasting is done" back to WSJT-X ?

I have developed an application which listens to the rebroadcasted UDP traffic, and does some specific highlighting in the Band Activity window.
The way I implemented this, is by doing a Windows "netstat -ab -p UDP" and retrieve the sending port for the WSJT-X to JTAlert flow.
I then re-use that port to issue "Highlight Callsign" messages from my app to WSJT-X. As you observe, it looks more like a "menage a trois", and is not very healthy ...

A possible implementation could be that JTAlert listens for incoming UDP traffic on its sending re-broadcasting socket, verify the "magic number" and forwards the traffic back to WSJT-X ....

What do you think ?

73's and greetings from Belgium,
ON4PB


g4wjs
 

On 29/01/2020 14:52, Erik Icket wrote:
Hi Laurie,

I understand that the JTAlert development environment does not support UDP multicasting and you had to implement the rebroadcasting functionality as a workaround.

Would it be however be possible for JTAlert to piggyback the UDP traffic from "the application to which the rebroadcasting is done" back to WSJT-X ?

I have developed an application which listens to the rebroadcasted UDP traffic, and does some specific highlighting in the Band Activity window.
The way I implemented this, is by doing a Windows "netstat -ab -p UDP" and retrieve the sending port for the WSJT-X to JTAlert flow.
I then re-use that port to issue "Highlight Callsign" messages from my app to WSJT-X. As you observe, it looks more like a "menage a trois", and is not very healthy ...

A possible implementation could be that JTAlert listens for incoming UDP traffic on its sending re-broadcasting socket, verify the "magic number" and forwards the traffic back to WSJT-X ....

What do you think ?

73's and greetings from Belgium,
ON4PB
Hi Erik,

what you are requesting is not as easy as you state. The reply datagrams would need to be correctly addressed to the instance of WSJT-X they are intended for, that would require JTAlert to keep a table of WSJT-X clients along with their service port numbers to reply to. That table probably already exists within JTAlert so that it can itself send reply datagrams, but it is hard to see how reply datagrams from your application can be allocated to the correct WSJT-X instance when routing them through, since JTAlert does not know to which original outgoing message the reply is to. More specifically, JTAlert has no knowledge of which sender service port of incoming reply datagrams belongs to which application.

All of this is elegantly handled if each application interoperating with WSJT-X is capable of listening on a UDP multicast group address, and each application need do no more than that, over and above what they would do using unicast addressing. It is unfortunate that the support libraries provided with AutoIT (the original implementation language of JTAlert) do not directly support listening for UDP traffic on a multicast group addresses. Someone with moderate AutoIT programming skills and some systems programming knowledge on MS Windows could write the necessary add-on for AutoIT to do what is required. Until that happens, or until Laurie is in a position to roll out the next generation of JTAlert, it is not practical to try and spoof multicast UDP handling in any way that meets your requirement.



--
73
Bill
G4WJS.


Erik Icket
 

Thank you Bill, once more, for your thorough insights.

For the moment, I have something working for a single WSJTX instance along the limitations which you described earlier.

Let's see how JTalert or AutoIT evolves with respect to multicasting.

Thanks again and 73's,
Erik
ON4PB