Hi Dick,setting the SO_REUSADDR socket option will not work, that option is intended for load balancing. It will allow multiple applications to bind the same service port on a single host, but datagrams will be consumed by the first application chosen (by the operating system using some operating system defined algorithm) and not sent to any other servers.
73 Bill G4WJS. On 09/11/2020 15:10, W3OA wrote:
Thanks for you response.I will change the documentation and let the RBN node operators know they will not be able to use the broadcast address.The software does not specifically support multicast. But it does set the SocketOptionName.ReuseAddress to true. I did this thinking it would allow sharing that port with other applications. Is that true and does it answer your concern for not using multicast?Using a separate port for each WSJT-X instance is consistent with how Aggregator handles other spot sources. I think doing so can be advantageous when the node operator is checking that his node is operating correctly. Aggregator has a tab where he can see the dial frequency and time of last message for all WSJT-X instances in one place.73 - Dick, W3OA On 11/9/2020 8:36 AM, wsjt-devel-requ...@lists.sourceforge.net wrote:Message: 1 Date: Mon, 9 Nov 2020 11:52:15 +0000 From: Bill Somerville <g4...@classdesign.com> To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] Heads up for authors of applications using the WSJT-X, UDP Message Protocol (Bill Somerville) Message-ID: <324ab1f8-560c-2b64-3126-29d3848f4...@classdesign.com> Content-Type: text/plain; charset="utf-8"; Format="flowed" Hi Dick, a quick search did not find any sources for FT#StartUp but I do note some documentation that use of the IPv4 broadcast address (255.255.255.255) is recommended, that will no longer work with this version of WSJT-X. IPv4 broadcast is ugly and impacts local network performance we specifically disallow sending WSJT-X UDP Message Protocol traffic to the IPv4 broadcast address with this upcoming change. It looks to me that your software does not support IP multicast with WSJT-X, if that is the case then that's a shame as it constrains the choices of users to use other applications that interoperate with WSJT-X. If you do support multicast then this change will require you to make a small change. Let me know if you do support multicast IP and I can proceed depending upon that? Looking at the "Aggregator" documentation here:http://cms.reversebeacon.net/sites/cms.reversebeacon.net/files/2020/05/13/FT%23StartUpv1.pdfI am really confused. Why does it require using a different service port for each client WSJT-X instance being monitored? That is completely unnecessary! 73 Bill G4WJS. On 09/11/2020 10:40, W3OA wrote:Hi Bill - I would like a copy of the Windows pre release version. I am the author of FT#StartUp used at some Reverse Beacon Network (RBN) nodes to send FT4 and FT8 spots to the RBN.? I would like to see if any changes are needed. 73 - Dick, W3OA On 11/8/2020 8:26 AM, wsjt-devel-requ...@lists.sourceforge.net wrote:Message: 1 Date: Sat, 7 Nov 2020 19:50:13 +0000 From: Bill Somerville <g4...@classdesign.com> To: WSJT software development <wsjt-devel@lists.sourceforge.net> Subject: [wsjt-devel] WSJT-X: Heads up for authors of applications ????using the WSJT-X UDP Message Protocol Message-ID: <8ecc3df9-8102-bb90-9fa8-f58507658...@classdesign.com> Content-Type: text/plain; charset=utf-8; format=flowed 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 versionwill send to the loop-back interface by default. This change is intendedto limit the scope of multicast traffic to no further than necessary, and the vast majority of users will be running WSJT-X instances andother interoperating application servers like JTAlert and Gridtracker onthe 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 selectedmulticast group on the loop-back interface. For backwards compatibility it would seem wise to also optionally join the group on the local subnetnetwork 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 groupaddresses are in the 224.0.0.0/24 subnet (although these are officiallyreserved 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 serversjoin the chosen group address, although as I understand it ISPs ingeneral 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 casesmulticast datagrams may travel across the extended subnet if not blockedby 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 theauthors of JTAlert and Gridtracker, if any other software authors require a copy then let me know please. 73 BillG4WJS.
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
