1GB file transfer

How it works

One decimal gigabyte is 8,000 megabits. At 20 Mbps up, plan on about 400 seconds before overhead. Mail caps near 25 MB reject it. Object storage takes it as one PUT. A two-hour link covers a typical download. A five-minute link does not.

A 1.1 GB reel leaves mail and lands through a link in six minutes at 25 Mbps. The recipient pulls it in three minutes at 50 Mbps. Both legs fit a two-hour expiry.

How it differs

A 1 GB job is not a 10 GB job. You can skip multipart. You cannot skip the link.

Zipping a video reel does not get it under an attachment cap.

Quote the sender's up link, not the recipient's down link, when you book the upload.

On the ticket

• The practical close is a log line: time, actor, byte count, result.
• Without that line the transfer is a story.
• With it, the next person can see whether this door did what the ticket claimed.
• If the path is shared, say so in the partner profile so a later change does not silently pick a different limit, key, or region.
• On a real ticket, write down the door, the byte count, and the clock.
• For one gb file transfer, that means naming the host or bucket, the expected size, and the time the other side must have a complete file.
• A progress bar is not that record.
• A 200 response that arrives before the complete call is not that record.
• If a retry is allowed, say how many and whether it resumes.
• If a person must approve the send, name the person.
• Partners who receive one gb file transfer files should match on hash or size before they import.
• A same-length corrupt file passes a size check and fails a hash.
• Keep the published hash off the only channel an attacker can edit, or treat it as a corruption check rather than a substitution check.
• When the path changes, new key, new region, new cap, update the profile the same day so the next run does not use a stale limit.