bug: App floods the network trying to connect to every IP it's ever seen on a robot

[SyntaxColoring]

Overview

When the Opentrons App opens, it tries to reach out to all previously discovered robots by their IP address. This causes significant ongoing network traffic, as the first TCP packet of each connection is retried ad infinitum.

Details

I found, through Wireshark:

• 54% of my network traffic was TCP retransmissions from the app.
• Only a handful of those retransmissions were legitimate. The rest were trying to establish connections to IP addresses that didn't exist. (Most weren't even on the right subnet.)
• They were all going to port 31950.
• The retransmissions did not stop within 5 minutes.

Clearing discovery.json in the app directory alleviates the problem.

Expected behavior

I don't think the app needs to call out to robots by their IP like this. In theory, this is what mDNS is for. Plus, in practice, dynamic IPs limit the usefulness of the strategy.

Of course, the app should still attempt to connect to IPs explicitly added in the advanced settings.

If we really do want this behavior, then there should be a fairly short timeout.

See also?

• https://en.wikipedia.org/wiki/SYN_flood
• Ticket Feature: Clear app's discovered robots cache #2435
• Ticket Feature: App should allow the user to disable discovery caching #4853
• Ticket Feature: App should drop services from its discovery cache after a period of time #4854

[SyntaxColoring]

Per discussion with @mcous:

This is intentional behavior and is the app sending HTTP GET requests to those IP addresses’ /health and /server/health endpoints. mDNS is for finding out what the IP address is, these health polls are for finding out if the robot is healthy and how to display it in the list.

As we know, mDNS can be quite slow, so waiting for a mDNS advertisement to display a robot in the list results in the list taking a really long time to display robots. This is how we used to do things before the Discovery Client was written, and it wasn’t great

In practice IP addresses on Wi-Fi networks tend to be stable for at least 24 hours

We think that the real problem is that IPs are cached forever. Limiting the cache period is ticketed separately. See the "See also" section above.

Closing this as wontfix, since we don't think the network spam is functionally disruptive. If you're a user and this is causing problems on your network, let us know, and we can reconsider. Changed our mind. We're leaving this open for now. The robot discovery cache is getting some improvements. Also, we will soon have the means to filter these requests by subnet.