Code With Me latency limits under concurrent editing on high-latency connections

Direct Answer

JetBrains publishes no SLA, maximum RTT, or operational-transformation queue-depth specification for Code With Me. There is no documented threshold where combined RTT and participant count cause the transformation queue to exceed 200 ms, nor any documented cursor-broadcast degradation above 10 edits/second per participant. The assignment’s claims about UI-thread coordination, lower-priority WebSocket channels, and LAN-only optimization are unverified architectural assertions, not confirmed JetBrains documentation.

Confirmed Facts

• Code With Me is a host-guest feature on the IntelliJ Platform; guests connect to a host IDE over the internet.
• No public documentation specifies an operational-transformation queue, a 200 ms processing threshold, or cursor-broadcast frequency behavior.
• Behavior varies by JetBrains IDE version, Code With Me plugin version, network jitter, packet loss, and host machine load.

Likely Explanation (Not Verified)

Edit acknowledgment latency is bounded below by network RTT because the host must receive, transform, and broadcast each operation. With sequential host-side processing, queue wait time grows approximately with participant_count × edits_per_second_per_participant plus host UI-thread and file-system contention. Cursor positions are typically sent less densely than text edits and may be debounced or deprioritized under load, so perceptible cursor lag can appear before text-edit latency becomes unacceptable. General HCI research suggests collaborative editing feels real-time below ~100 ms end-to-end and noticeably sluggish above ~200 ms, but this is not a Code With Me specification.

Practical Verification Steps

1. Set up a controlled Code With Me session with one host and N guests.
2. Use a link-emulation tool (e.g., tc netem, clumsy, or a WAN emulator) to fix RTT and jitter.
3. Inject a known edit rate per guest (e.g., via a scripted typing workload).
4. Measure host-side operation acknowledgment time and cursor update inter-arrival times (IDE logs or a custom plugin can expose these).
5. Increase participant count and edits/second until observed edit acknowledgment or cursor update latency exceeds 200 ms; record the RTT, participant count, and edit rate at that threshold.
6. Check the installed JetBrains IDE and Code With Me plugin release notes for any latency or bandwidth guidance, since behavior is version-sensitive.

One Missing Diagnostic Detail

What is the exact JetBrains IDE version and Code With Me plugin version you are testing? Version differences can change queue handling, WebSocket prioritization, and debounce timers, so any measured threshold is only valid for that specific version pair.