Many redundant ParcelInfoRequest messages are sent when viewing or updating the Picks list

[maestrolinden]

Environment

Second Life Release 7.1.11.12363455226 (64bit)
Release Notes

You are at 7.7, 10.1, 40.6 in Ahern located at simhost-00e6c85685e547a2a.aditi
SLURL: secondlife://Aditi/secondlife/Ahern/8/10/41
(global coordinates 255240.0, 256522.0, 40.6)
Second Life Server 2024-12-17.12379604629
Release Notes

CPU: Apple M1 Pro (2400 MHz)
Memory: 16384 MB
OS Version: macOS 15.3.0 Darwin 24.3.0 Darwin Kernel Version 24.3.0: Thu Jan 2 20:24:16 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T6000 x86_64
Graphics Card Vendor: Apple
Graphics Card: Apple M1 Pro

OpenGL Version: 4.1 Metal - 89.3

Window size: 1173x751
Font Size Adjustment: 96pt
UI Scaling: 1
Draw distance: 96m
Bandwidth: 10000kbit/s
LOD factor: 1.125
Render quality: 1
Texture memory: 10922MB
Disk cache: Max size 1638.4 MB (13.0% used)
HiDPI display mode:

J2C Decoder Version: KDU v7.10.4
Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.23.1 / OpenAL Community / OpenAL Soft: OpenAL Soft
Dullahan: 1.14.0.202408091638
CEF: 118.4.1+g3dd6078+chromium-118.0.5993.54
Chromium: 118.0.5993.54
LibVLC Version: 3.0.21
Voice Server Version: Vivox 4.10.0000.32327.5fc3fe7c.5942f08

Packets Lost: 1/15772 (0.0%)
February 12 2025 17:20:48

Description

When a user viewers the Picks list in their own profile, the viewer makes a series of ParcelInfoRequest messages for each of the parcels referenced in the picks list. Rather than performing 1 ParcelInfoRequest per parcelID, with n requests for n picks, the viewer performs multiple requests per parcel, which scales O(n^2) with the number of picks. If the agent has about 10 picks (which is the current maximum), the viewer sends a burst of about 200 ParcelInfoRequest messages - which is enough for the simulator to start throttling its requests.

Reproduction steps

1. Set up Hippolyzer and configure the viewer to use it
   • Or alternatively, set up some sort of DEBUG logging of ParcelInfoRequest messages
2. Set the display filter to (ParcelInfo*|| Pick* ) - this shows the necessary messages
3. Login with an agent with 0 picks
4. Create pick 1
5. Close and reopen Picks - note PickInfoReply and ParcelInfoRequest messages
6. Go to a different parcel, and create pick 2
7. Close and reopen Picks - note new PickInfoReply and ParcelInfoRequest messages
8. Go to a different parcel, and create pick 3
9. Close and reopen Picks - note new PickInfoReply and ParcelInfoRequest messagesExpected results:

• Each time the user opens Picks, there should be at most 1 ParcelInfoRequest message from the viewer per parcel referenced in the Picks list. Possibly 0 such messages if cached by the viewer.

Actual results:

• In (5), the simulator sends 1 PickInfoReply message about pick-1, but the viewer sends 2 ParcelInfoRequest for the pick1-parcel
• In (7), the simulator sends 2 PickInfoReply messages about pick-1 and pic-2, but then the viewer sends
  • 3 ParcelInfoRequest for the pick1-parcel
  • 2 ParcelInfoRequest for the pick2-parcel
• In (9), the simulator sends 3 PickInfoReply messages about the 3 picks, but then the viewer sends
  • 4 ParcelInfoRequest for the pick1-parcel
  • 3 ParcelInfoRequest for the pick2-parcel
  • 2 ParcelInfoRequest for the pick3-parcel
• The simulator sends ParcelInfoReply for each ParcelInfoRequest message from the viewer, even when redundant.
• This pattern continues as the user adds their 4th pick and so forth.

[maestrolinden]

@akleshchev wasn't immediately seeing this bug as I was, so I performed another test on Second Life Release 7.1.11.12363455226 (64bit).

First, I opened my picks floater and created a new/4th pick. I've annotated it. I don't see the same pattern as before, but there are 2 consecutive ParcelInfoRequest requests for each parcel ID in the picks:

After closing and reopening the picks view, I see this - again 2 ParcelInfoRequest messages per parcel ID:

[akleshchev]

Plan:

• At minimumum some dupplicate request prevention. Differemnt UIs requesting same parcel data is fine, multiple network requests are not.
• Potentially reuse tabs instead of recreating them each time data arrives, this would reduce requests, but likely to be risky and not worth it.
• At maximum some short term caching (minutes?). In case user needs to rebuild that list often. Since vewer isn't aware of parcel changes, viewer can't afford long term caching.