Jason Transfer Protocol (JTP)

Note

JTP has been submitted as an Internet-Draft to the IETF. As such, it is a work in progress and subject to change based on ongoing discussion and review within the IETF community.

JTP is a high-performance binary protocol for transferring images over TCP with optional TLS encryption and intelligent compression.

Features

• Content-addressed: Images identified by xxHash64 of their bytes
• Efficient: Compact binary framing with varint encoding
• Secure: Optional TLS encryption with ALPN support (jtp/1)
• Compression: Adaptive Zstd compression for compressible formats
• Connection reuse: Keep-alive support to avoid repeated TLS handshakes
• Delta sync: BATCH mode downloads only missing images

A wider list of applications can be found here.

Getting Started

Prerequisites

• Rust 1.72+
• On Windows, CMake may be required for TLS dependencies

Building

git clone https://github.com/punctuations/jtp.git
cd jtp
cargo build --release

Running

Server (listens on 0.0.0.0:8443 by default):

cargo run --bin server -- --images ./images

Client (connects to 127.0.0.1:8443 by default):

cargo run --bin client

Command-Line Options

Server:

--bind ADDR               Bind address (default: 0.0.0.0:8443)
--images DIR              Images directory (default: images)
--only SUBSTRING          Only serve files containing SUBSTRING
--compression-threshold   Min ratio to use compression (default: 0.95)
--keep-alive-timeout SEC  Idle timeout in seconds (default: 30)
--rate-limit N            Max requests per window (default: unlimited)
--rate-limit-window SEC   Rate limit window in seconds (default: 1)
--no-tls, --plain         Plain TCP mode (no encryption)
--verbose, -v             Enable detailed logging

Client:

--addr HOST:PORT          Server address (default: 127.0.0.1:8443)
--tls, --secure           Use TLS encryption
--no-tls, --plain         Use plain TCP (default)
--server-name NAME        TLS SNI name (default: localhost)
--cert PATH               Server certificate path (default: cert.pem)
--out DIR                 Output directory (default: output)
--batch                   Delta sync: download only missing images
--keep-alive, -k          Reuse connection for multiple requests
--parallel N, -p N        Parallel workers (default: 1, max: 32)
--repeat N                Download N times
--verbose, -v             Enable detailed logging

Protocol Overview

JTP uses a request/response model over TCP (optionally TLS-wrapped).

ImageID

Images are identified by a 64-bit content hash:

ImageID = xxHash64(image_bytes, seed=0)

Request Types

Type	Code	Description
LIST	1	Get catalog of available images
GET_BY_ID	0	Request specific images by ID
BATCH	2	Delta sync (send IDs you have, receive missing)
LIST_AND_GET	5	Combined catalog + all images

Response Headers

Header	Description
JTPL	LIST response (catalog)
JTPB	BATCH response
JTPG	LIST_AND_GET response
JTPE	ERROR response

For the complete protocol specification, see RFC.md.

Compression

JTP uses Zstd compression with adaptive levels based on file size. Only compressible formats (BMP, unknown) are compressed. Already-compressed formats (PNG, JPEG, WebP, GIF) are sent as-is.

Testing

Testing is handled through integration (tests/integration.rs), to run against the tests (if changing or altering the rust implementation) you can use the following:

cargo test --test integration

OR for a more verbose output per test:

cargo test --test integration -- --nocapture

Contributing

See CONTRIBUTING.md for guidelines.

Applications

While it may not be clear what the big pros and use cases are for this protocol right away, the main ones are as follows:

• Fast image distribution over a network: a server hosts an image catalog and clients fetch images by ID.
• Client/server sync of image sets: clients can list available images, then download only what they need.
• Delta synchronization: BATCH mode is for updating a client that already has some images, so it only transfers missing ones.
• Efficient repeated transfers: keep-alive and optional TLS make it practical for many requests over one connection.

More specific applications could include:

• Photo library sync tools: keeping image folders in sync between a desktop and a server.
• Image CDN/origin backends: a server can expose a catalog of assets and let edge nodes fetch by content ID.
• Backup/replication for image archives: moving large sets of media files efficiently with delta sync.
• Desktop/mobile gallery sync: apps that need to download only missing photos from a remote library.
• Machine-learning dataset distribution: shipping large image datasets to training nodes.
• Asset delivery for static sites or apps: pushing image bundles to deployment targets.
• On-prem media management systems: catalogs of screenshots, scans, or design assets.

License

MIT