Got it, thanks, Bill. You're probably correct. Just like to test, all the same.
Thomas Reynolds On Sun, Nov 8, 2020 at 3:39 PM Bill Somerville <g4...@classdesign.com> wrote: > Hi Thomas, > > I suspect you will not have to make any changes as the devices WSJT-X > Monitor is running on will be on the users subnet. WSJT-X instances in this > case will need to be configured to send multicast datagrams on the subnet > interface which is equivalent to the current way WSJT-X 2.2.2 and earlier > versions worked. > > I will send you a copy of the pre-release installer to your gmail address. > > 73 > Bill > G4WJS. > > On 08/11/2020 23:05, Thomas Reynolds wrote: > > 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
