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
