DirectlyDrop Test Results and Performance Notes

Two Chromium tabs were paired in a local preview of the production bundle with a four-digit room code. A 1 MiB synthetic file was first rejected and then accepted; the sender displayed the correct rejection message and the accepted transfer completed on both sides. A zero-byte file was also completed through code 0132, preserving its leading zero.

The same build was forced to use relay-only ICE. Because no valid production TURN credentials were configured, the relay could not connect; the new 15-second timeout entered an error state and left retry available. This validates the direct flow and failure handling, but not relay transfer across separate internet providers.

Measurements were taken on August 7, 2026, on Windows desktop with Chromium 151. Sender and recipient ran in separate tabs. A production-site pairing verified both peer identities, while timed repetitions used a local preview of the production build on the same computer.

This setup measures connection, chunking, recipient writes, download preparation, and completion acknowledgement together. It is a low-latency best case, not a speed promise for mobile networks, distant cities, corporate firewalls, or TURN relays.

Synthetic 1, 5, and 20 MiB files containing zero bytes were generated to avoid personal data. Each size was sent three times with a new room and peer connection. Wall-clock time ran from the sender's Send command to the recipient's completed state.

Effective throughput divides file size by median end-to-end time. It includes metadata, 16 KB chunks, temporary writes, and the final acknowledgement, making it more conservative than a momentary in-app speed reading.

All nine measured transfers completed on both sides. Fixed connection and acknowledgement overhead represented more of the 1 MiB trial, while that cost was spread across more data for 5 and 20 MiB files.

Higher throughput for larger files does not guarantee the same result elsewhere. CPU load, OPFS write speed, Wi-Fi quality, tab scheduling, the selected ICE route, and TURN use can all change performance.

End-to-end transfer was directly tested only on Chromium 151 for this release. API availability in current Chrome, Edge, Firefox, and Safari does not prove the entire flow on every operating system and network.

The live check below reports WebRTC, OPFS, service worker, and clipboard API availability only on this device. It neither connects to a network peer nor sends a file. Use a small, non-sensitive file for a real compatibility check.

On desktop, add testFileMiB=0, 1, 5, or 20 to the home-page query string to prepare a synthetic file. The zero value tests an empty file. Test mode does not connect or send automatically.

Open the normal home page on a second device, enter the test room code, and send after the connection is ready. Record file size, elapsed time, both completion states, browsers, and network type, then repeat at least three times.

Completion means the recipient processed the expected chunks and acknowledged the sender. The downloaded SHA-256 digest was not compared in this benchmark; critical transfers should add that integrity check.

The test does not measure background-tab continuity, device sleep, resume after disconnection, or public TURN capacity. These remain documented limits until separate tests are completed.

Measurements will be repeated after changes to chunk size, buffer thresholds, PeerJS, temporary storage, or TURN configuration. The environment and date will be published with each revision.

Future browser and real-device tables will retain failures with browser, operating system, network, and error details instead of reporting only successful runs.