Support downloading packages in parallel, with multiple connections per package (similar to apt-fast)
### Relevant area(s) - WinGet CLI ### Description of the new feature / enhancement Support downloading a **single package** using **multiple concurrent connections/streams** (segmented download) to improve throughput — especially on high-latency or intermittently slow links. The concept is similar to apt-fast and other download accelerators. > Note: This issue is scoped to accelerating the download of **one** package via multiple streams. Downloading the **next** package while the current one installs (multi-package pipeline) is tracked separately in #4105. ### Proposed technical implementation details - This relies on HTTP **Range** requests (`bytes=`) to fetch segments in parallel and reassemble them. - Current state in WinGet: - WinGet tries **Delivery Optimization (DO)** first for installer downloads, which already performs connection/CDN optimization transparently. - The **WinINet** fallback path downloads sequentially on a single stream (no Range). - WinGet already issues HTTP Range requests elsewhere — the random-access `HttpStream` used for appx reading — so Range-based segmented download is feasible against sources that advertise `Accept-Ranges`. - Considerations: sources that don't support ranges must fall back to a single stream; DO may already deliver most of this benefit for installer downloads, so the incremental value should be measured before investing. ### Related - #4105 --- *Updated with GitHub Copilot.*
Posted by nth10sd on May 19, 2020, 11:34 PM
Tags
Related issues
- The only thing keeping me on VSCode these days is the remote SSH development.
- Something similar was done in a sheep model: "A bioactive supramolecular and covalent polymer scaffold for cartilage repair in a sheep m...
- Proposal for OpenHarmony Adaptation of [ ThreadPool ]
- Proposal for a pipe-like operator to chain constructor/method invocations without nesting
- Implement support for Node Stashing
- RSC and CDN interaction makes next.js inefficient for highload projects
Raise real-world problems, find people facing the same issue, and discuss solutions.3,500 issues0 comments
support (E-commerce)
The only thing keeping me on VSCode these days is the remote SSH development.
Something similar was done in a sheep model: "A bioactive supramolecular and covalent polymer scaffold for cartilage repair in a sheep m...
Proposal for OpenHarmony Adaptation of [ ThreadPool ]
Proposal for a pipe-like operator to chain constructor/method invocations without nesting
Implement support for Node Stashing
RSC and CDN interaction makes next.js inefficient for highload projects
Extract Action Notifier framework for push notifications
Improve support for monorepo by supporting git options such as depth, and sparse checkout
Support downloading packages in parallel, with multiple connections per package (similar to apt-fast)
### Relevant area(s) - WinGet CLI ### Description of the new feature / enhancement Support downloading a **single package** using **multiple concurrent connections/streams** (segmented download) to improve throughput — especially on high-latency or intermittently slow links. The concept is similar to apt-fast and other download accelerators. > Note: This issue is scoped to accelerating the download of **one** package via multiple streams. Downloading the **next** package while the current one installs (multi-package pipeline) is tracked separately in #4105. ### Proposed technical implementation details - This relies on HTTP **Range** requests (`bytes=`) to fetch segments in parallel and reassemble them. - Current state in WinGet: - WinGet tries **Delivery Optimization (DO)** first for installer downloads, which already performs connection/CDN optimization transparently. - The **WinINet** fallback path downloads sequentially on a single stream (no Range). - WinGet already issues HTTP Range requests elsewhere — the random-access `HttpStream` used for appx reading — so Range-based segmented download is feasible against sources that advertise `Accept-Ranges`. - Considerations: sources that don't support ranges must fall back to a single stream; DO may already deliver most of this benefit for installer downloads, so the incremental value should be measured before investing. ### Related - #4105 --- *Updated with GitHub Copilot.*
Comments (0)
No comments yet. Start the discussion.