TapTap/FastSync
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Feature: Compression algorithm negotiation (not just zstd) #184

New Issue
Closed
opened 2026-07-30 18:33:35 +02:00 by TapTap · 0 comments
TapTap commented 2026-07-30 18:33:35 +02:00
Owner
Copy Link
Copy Source

Corresponding rsync flags/behavior:

  • rsync supports --compress-choice=zstd|zlib|lz4 and --zc / --compress-level
  • Negotiates compression algorithm between client and server

Current FastSync behavior:
FastSync only supports zstd. The client unilaterally sets use_compression and compression_level, and the server must accept zstd. If a future peer does not support zstd, the connection cannot proceed.

Proposed changes:

  • CLI flags: --compress-choice=<algo> (or --zc), keep -c/--compress as shortcut for zstd default
  • Config field: CompressionAlgorithm compression_algorithm and existing compression_level
  • Supported algorithms: none, zstd (default), optionally lz4 and zlib
  • Protocol changes:
    • During config handshake, advertise supported algorithms
    • Pick a mutually supported algorithm; fall back to no compression if none match
    • Send chosen algorithm in config or via a new STATUS_NEGOTIATE step
  • Implementation:
    • Abstract compression interface with per-algorithm compress/decompress functions
    • Make data_compress/data_decompress dispatch based on negotiated algorithm

Priority: low
Rationale: zstd is excellent, but supporting lz4 (faster, lower CPU) and zlib (broader compatibility) gives users more trade-offs. Negotiation is also needed for protocol extensibility.

Acceptance criteria:

  • --compress-choice=none disables compression even when -c is used
  • Client and server negotiate zstd when both support it
  • A client requiring only lz4 falls back to no compression against an older zstd-only server
  • Compression choice is reflected in --stats output
**Corresponding rsync flags/behavior:** - rsync supports `--compress-choice=zstd|zlib|lz4` and `--zc` / `--compress-level` - Negotiates compression algorithm between client and server **Current FastSync behavior:** FastSync only supports zstd. The client unilaterally sets `use_compression` and `compression_level`, and the server must accept zstd. If a future peer does not support zstd, the connection cannot proceed. **Proposed changes:** - CLI flags: `--compress-choice=<algo>` (or `--zc`), keep `-c/--compress` as shortcut for zstd default - Config field: `CompressionAlgorithm compression_algorithm` and existing `compression_level` - Supported algorithms: `none`, `zstd` (default), optionally `lz4` and `zlib` - Protocol changes: - During config handshake, advertise supported algorithms - Pick a mutually supported algorithm; fall back to no compression if none match - Send chosen algorithm in config or via a new `STATUS_NEGOTIATE` step - Implementation: - Abstract compression interface with per-algorithm compress/decompress functions - Make `data_compress`/`data_decompress` dispatch based on negotiated algorithm **Priority:** low **Rationale:** zstd is excellent, but supporting lz4 (faster, lower CPU) and zlib (broader compatibility) gives users more trade-offs. Negotiation is also needed for protocol extensibility. **Acceptance criteria:** - [ ] `--compress-choice=none` disables compression even when `-c` is used - [ ] Client and server negotiate zstd when both support it - [ ] A client requiring only lz4 falls back to no compression against an older zstd-only server - [ ] Compression choice is reflected in `--stats` output
TapTap added the enhancementneeds-triage labels 2026-07-30 18:33:35 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Defect or bug
 enhancement
Feature or improvement
 memory
Memory safety issue
 needs-triage
Needs human review
 performance
Performance issue
 quality
Code quality improvement
 security
Security vulnerability
 threading
Threading or concurrency
No Label enhancement needs-triage
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
TapTap
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: TapTap/FastSync#184
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?