Dave,
by "antiquated" UDP interface I assume you mean the deprecated N1MM
Logger+ feed of logged QSOs. If so then this change has nothing to do
with that.
73
Bill
G4WJS.
On 09/11/2020 03:29, Dave Slotter, W3DJS wrote:
Bill,
My logging adapter, wsjtx_to_n3fjp, uses the antiquated UDP interface.
After reading your message, I don't see anything needing adjustment in
my software, but it probably is a good a time as any to ask how much
longer the antiquated UDP interface will be in place.
wsjtx_to_n3fjp may be downloaded / inspected from GitHub at:
https://github.com/dslotter/wsjtx_to_n3fjp
<https://github.com/dslotter/wsjtx_to_n3fjp>
Please advise, and 73.
--
Dave Slotter, W3DJS <https://www.qrz.com/db/W3DJS>
On Sat, Nov 7, 2020 at 2:54 PM Bill Somerville <g4...@classdesign.com
<mailto:g4...@classdesign.com>> wrote:
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 <http://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
<http://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
