Skip to content

mavproxy_ftp: support concurrent, faster and resilient transfers - #1733

Closed
tridge wants to merge 6 commits into
ArduPilot:masterfrom
tridge:pr-multi-ftp
Closed

mavproxy_ftp: support concurrent, faster and resilient transfers#1733
tridge wants to merge 6 commits into
ArduPilot:masterfrom
tridge:pr-multi-ftp

Conversation

@tridge

@tridge tridge commented Aug 18, 2026

Copy link
Copy Markdown
Contributor

Summary

This reworks the MAVProxy FTP client to support multiple simultaneous operations and substantially improve transfer performance and resilience.

This replaces #1724

  • allow independent FTP workers so parameter FTP, directory listing, downloads, and uploads can run concurrently
  • queue operations when all MAVFTP session IDs are in use, and quarantine recently retired IDs to avoid delayed-packet collisions
  • pipeline reads and writes, negotiate accelerated upload capabilities, and batch outgoing MAVLink packets
  • keep network writes below a safe datagram size while preserving efficient serial batching and reliable stream writes
  • recover missing blocks efficiently under receive or transmit loss, with configurable loss and variable-lag simulation
  • cancel delayed simulated traffic when a worker terminates
  • support directory modification timestamps
  • preserve idle FTP status output
  • retain compatibility with older MAVFTP servers and reject accidental capability matches

Why

The previous FTP module effectively serialized operations and used conservative request/response behavior. This prevented commands such as parameter FTP, ftp list, and ftp get from progressing together, limited throughput on fast links, and amplified stalls caused by loss or variable latency.

The new worker manager isolates transfer state per operation, bounds active sessions, and uses pipelining plus selective retry to keep the link busy without sacrificing compatibility.

Compatibility

Accelerated uploads are enabled only after a server returns the MFQ1 capability marker. Older servers continue to use the legacy single-request upload path. Cumulative acknowledgements remain compatible across old and new client/server combinations.

Validation

  • pytest -q tests/test_mavproxy_ftp.py: 22 passed
  • ArduPilot SITL integration coverage for concurrent list/get/put operations
  • SITL upload batching, duplicate-request, filename, timestamp, and poor-link regression tests
  • transfer testing against Pixhawk6X over USB and STLink-V3
  • final adversarial review of cancellation, session reuse, capability negotiation, batching, retry caching, and write-window behavior

@tridge
tridge marked this pull request as ready for review August 19, 2026 01:27
@tridge

tridge commented Aug 26, 2026

Copy link
Copy Markdown
Contributor Author

closing for #1740

@tridge tridge closed this Aug 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant