Bill,

I would also like a pre-release version of WSJT-X v.2.3.0 RC2 (Win10 or
Ubuntu)

I am the author of an Android app, WSJT-X Monitor (by Feotec), which uses
the UDP interface.

Multicast is not supported in the Android kernel but many manufacturers
build it in so we offer a special version for users who are able to utilize
it.

Thank you,
Thomas Reynolds

On Sat, Nov 7, 2020 at 11:54 AM Bill Somerville <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 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
>
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Reply via email to