Does EESDR poll all the IP in the subnet in order to discover the SunSDR2 or is there a more efficient method?

Somewhat related to this, does EESDR2 have a "Broadcast data" function such as found in EESDR3? Can someone describe what exactly is being broadcast? Thanks.

Not sure why is does matters ... from networking perspective it is milliseconds anyway (unless any blocking config on network).

From a memory (some tests years ago), ESDR2 first looks at configured device IP and then does broadcast discovery once. For more details run Wireshark from ESDR2 PC.

To be precise - what I want to do is find instances of EESDR2 or EESDR3 running on the network so that I can automatically establish a TCI connection with it. On EESDR3 there a "Broadcast" option that allows you to set ports. I'm not sure if this means that that EESDR3 instance will respond to a UDP discovery packet on those ports? Why two ports? Does EESDR2 have anything similar?

As for ESDR3 - I would not rely on what it is in current alpha. There are discussions in the background about TCI functionality; there are multiple 3rd parties involved (i.e SDC, JTDX, loggers, others) and the interests are different, sometimes conflicting. Hence, we do not know at this stage, what TCI implementation (including connectivity options and broadcast) will be final.

As for ESDR instances auto-discovering - you completely lost me. When technically possible, it is ... a bit dis-aligned with common client-server architecture. Excluding DHCP (because of specific purpose and nature) in 99.99% of cases client would know the server destination, and there are common reasons behind. BTW, you can use extended DHCP options to set auto-discovery, however there is always a risk that client device will find "wrong" server, assuming two ESDR instances are running simultaneously; hence, workaround would be to use TCI version signature (means you have to update it in code every time with new revision is out) - that all above looks very and unnecessary over-complicated.

Assuming your purposes are around ESP32 (as per another thread), note, that ESP32 will not support dual TCI connectivity. (Purely theoretically it can, but you have to split the functionality in each CPU core, which automatically means 2 connections as max; and, even successful - you will have conflicts on flow definition level then).

In my testing, it does not appear that EESDR2 broadcasts any UDP discovery messages. The only way you will find an instance of EESDR2 running is by scanning the subnet on which the instance is running (and you'll have to be on the same subnet of course). EESDR3 is different in this regards. Quite separately from the "Broadcast" setting, which I think is for a slightly different purpose, it sends out broadcast UDP packets regularly. In fact, it does so as soon as the launcher stub is running and even before the main application is started. What it does is that it sends out packets on UDP port 40001 to 40004(or 40005?) along with it's own IP and the primary port of interest for me is port 40001. Any device on the same subnet can receive the packet and know that there is an EESDR3 client on that machine IP. You can then test to see if the TCI port is available to connect on that IP. Usually this happens only when the application is started up. In this way, I do not need to scan the entire subnet, which can be quite time consuming because of the timeout that needs to be included to account for slow latency connections (such when a machine is using Wi-Fi). I cannot do this with the EESDR2 and have to resort to slow scanning.

For EESDR2, one strategy might be to snoop on the UDP packet exchange between it and the radio. This happens on port 50001 or 50002 I believe but this does present some unique challenges in that it won't work unless you're on the same subnet as the radio itself.

Hmm ... Have no idea why are you expecting WS to be sending UDP and broadcast anything. Perhaps, this will help.

Also it would be really helpful if you make up your mind - you want broadcast or you want discovery, because those two are not equal. Perhaps it was me confusing you, saying earlier "ESDR2 first looks at configured device IP and then does broadcast discovery once" - in this I meant "broadcasts device settings to all established connections". This is, I believe, not kind of broadcast you mean.

No, it is not. I'm talking about EESDR2 identifying itself to other clients on the network that might want to establish a TCI connection to it. For example, SDC might be sitting there repeatedly trying to connect to a non-existent EESDR2 client or a client that has not fired up yet. It is better for SDC to wait for a broadcast from EESDR2 to inform everyone (via UDP broadcast protocol) that it is now ready to accept connections. Discovery is similar except now, SDC does not even know which IP the EESDR2 is running from. It could be running remotely or off different PC's and you do not want an instance of SDC checking every possible EESDR2 instance on the network. Ideally, what you want is for any and all EESDR2 instances on the network to advertise its availability as a TCI server, and waiting clients can then choose which of these it wants to connect to - without necessarily knowing the IP before hand. Without this, the only way to achieve this functionality is to have the client scan the entire network for open TCI ports and this is both slow and inefficient, not to mention the possibility of triggering the anti-DDOS protection on some firewalls.

I was looking at how EESDR2 talks to the radio - in this case the roles are reversed and EESDR2 is the client. The radio broadcasts UDP packets to announce its availability on the network and this is how "Discover" on EESDR2 finds it. I was wondering if EESDR2 did this same thing in its capacity as a TCI server. Apparently it does not but EESDR3 does.

OK... Because RFC seems to be "not working", let me make it very simple:
1. TCI is using Websockets (aka WS) on transport layer.
2. WS does not support UDP it works over TCP and SSL/TLS (SecureWS).
3. WS does not support broadcast for network discovery purposes. It only supports "message to all already established connections".
4. TCI over WS currently employs common server-client architecture on Application layer.

Hence, there is no simple and feasible way to perform network discovery of TCI server via utilising TCI and WS in-build capabilities.