Hi Bill -
I would like a copy of the Windows pre release version.
I am the author of FT#StartUp used at some Reverse Beacon Network (RBN)
nodes to send FT4 and FT8 spots to the RBN. I would like to see if any
changes are needed.
73 - Dick, W3OA
On 11/8/2020 8:26 AM, wsjt-devel-requ...@lists.sourceforge.net wrote:
Message: 1
Date: Sat, 7 Nov 2020 19:50:13 +0000
From: Bill Somerville <g4...@classdesign.com>
To: WSJT software development <wsjt-devel@lists.sourceforge.net>
Subject: [wsjt-devel] WSJT-X: Heads up for authors of applications
using the WSJT-X UDP Message Protocol
Message-ID: <8ecc3df9-8102-bb90-9fa8-f58507658...@classdesign.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi all,
the next release of WSJT-X (v.2.3.0 RC2) will change the way UDP
datagrams are sent by WSJT-X when being sent to a multicast group
address. Until now multicast datagram have been sent on the operating
system preferred network interface, which in most cases will be the
network with the default route, i.e. the local subnet. The new version
will send to the loop-back interface by default. This change is intended
to limit the scope of multicast traffic to no further than necessary,
and the vast majority of users will be running WSJT-X instances and
other interoperating application servers like JTAlert and Gridtracker on
the same host. For this the loop-back interface is available to all
applications and datagrams need not be sent any further afield.
I foresee that applications that join a multicast group to receive
WSJT-X UDP datagrams will need to be changed to join the selected
multicast group on the loop-back interface. For backwards compatibility
it would seem wise to also optionally join the group on the local subnet
network interface, as they do now, in addition to joining on the
loop-back interface. This will both allow interoperation with older
versions of WSJT-X (pre-v2.3.0 RC2), and with WSJT-X instances
configured to send datagrams on a different network interface than the
loop-back interface; so applications running on other hosts in the
network can interoperate. The latter allowing more complex
configurations to be set up when necessary.
This change has been prompted by some users apparently selecting
inappropriate multicast group addresses that in some circumstances may
be more widely routed than expected. Good choices of multicast group
addresses are in the 224.0.0.0/24 subnet (although these are officially
reserved for local network control these have the handy attribute that
they are never globally routed), in the 239.255.0.0/16 range, or IPv6
multicast addresses in the ffx1::/16, ffx2::/16, and ffx3::/16 ranges.
Other multicast addresses may be routed further afield if remote servers
join the chosen group address, although as I understand it ISPs in
general do not route *any* multicast datagrams *from* their subscribers.
Some ISP utilize a "flat" internetworking structure where many
subscribers (possibly thousands) are placed on the same subnet, I
believe? this more common amongst cable based ISPs. In those cases
multicast datagrams may travel across the extended subnet if not blocked
by subscriber firewalls.
Note that applications that are only able support unicast UDP are not
affected by this change.
I have sent pre-release versions of WSJT-X with this enhancement to the
authors of JTAlert and Gridtracker, if any other software authors
require a copy then let me know please.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
