Bill, Yes, the deprecated interface.
Thanks for following up. 73, -- Dave Slotter, W3DJS <https://www.qrz.com/db/W3DJS> On Mon, Nov 9, 2020 at 6:44 AM Bill Somerville <g4...@classdesign.com> wrote: > 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 > > 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> > 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
