From bb5ee2f50b505f2889b7e597a93f981dcb6dd96e Mon Sep 17 00:00:00 2001 From: Alexander Ivanov Date: Fri, 1 Oct 2021 19:01:57 +0800 Subject: [PATCH 01/12] Create bep_0056.rst --- beps/bep_0056.rst | 130 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 beps/bep_0056.rst diff --git a/beps/bep_0056.rst b/beps/bep_0056.rst new file mode 100644 index 0000000..7aee53c --- /dev/null +++ b/beps/bep_0056.rst @@ -0,0 +1,130 @@ +:BEP: 56 +:Title: Extension for Peers to Send Metadata Files +:Version: $Revision$ +:Last-Modified: $Date$ +:Author: Alexander Ivanov +:Status: Draft +:Type: Standards Track +:Created: 31-Sep-2021 +:Post-History: + +Abstract +======== +This extension adds a capability for clients to apply on-the-fly +compression on seeded pieces (next - chunks), effectively improving +bandwidth on torrents for clients supporting it. + +Rationale +========= +This extension would allow clients to download files faster, without +using file archivers. Since large files are often precompressed before +torrent creation, downloaders needs to keep both the archives +(for seeding) and uncompresed files (for own usage). + +Most users prefer to remove such torrents, thus harming proper file +distribution. For example: Organizations using bittorrent for software +distribution needs to have centralized storage for new customers, no +matter how many customers already have same software. + +Extension header +================ + +This extension uses the extension protocol (specified in `BEP 0010`_) +to advertize client capability of using chunk compression. It defines +following items in the extension protocol handshake message: ++-------+-----------------------------------------------------------+ +| name | description | ++=======+===========================================================+ +| c | Dictionary of supported compression algorithm which maps | +| | its identifiers to its priority (unsigned 8-bit integer), | +| | clients can adjust it based on compression speed/ratio, | +| | hardware support, performance and power mode, et cetera. | +| | Priority set to zero means that the compression algorithm | +| | is not supported or disabled by user, The client should | +| | ignore any algorithms it doesn't recognize/malformed. | ++-------+-----------------------------------------------------------+ +| cp | Optional field with prefered compression algorithm. | +| | If client supports that algorithm and it's not disabled, | +| | then it must expect to recieve pieces compressed by that | +| | specified algorithm. | ++-------+-----------------------------------------------------------+ + + + +Compression algorithm is selected by taking dictionary item with highest +priority from intersection of items supported by both peers, if there +isn't any suitable compression algorithm - compression will be disabled. + +Example of extension handshake message: + +:: + + { + 'c': { + 'lz4': 21, + 'density_chameleon': 18, + 'density_cheetah': 13, + 'density_lion': 9, + 'zstd': 0 + }, + 'cp': 'lz4' + } + + +Piece compression +================= +Some algorithms can't compress unreasonably small pieces efficiently, so +client should lower algorithm's priority during handshake, depending on +expected compression ratio for defined piece size (down to zero in worst case). +After compression algorithm is negotiated, next pieces are sent compressed. + +If client is caching seeding/recieved pieces in memory, then pieces should +be stored compressed, decompressing when saving to disk or sending to peer +which not supports that compression. To avoid re-compression pieces when +sending, client can specify ``cp`` field during handshake. + +Allowed compression algorithms +------------------------------ + +Compression algorithms must satisfy following requirements: + +1. Decompression speed must not be lower than 1000MB/s. + +2. It must not produce larger piece than original by 1%. + ++-------------+-----------------------------------------------------+ +| identifier | compression algorithm | ++=============+=====================================================+ +| lz4 | LZ4 | ++-------------+-----------------------------------------------------+ +| lz4_hc | High compression derivative of LZ4 | ++-------------+-----------------------------------------------------+ +| d_chameleon | Chameleon algorithm for DENSITY | ++-------------+-----------------------------------------------------+ +| d_cheetah | Cheetah algorithm for DENSITY | ++-------------+-----------------------------------------------------+ +| d_lion | Lion algorithm for DENSITY | ++-------------+-----------------------------------------------------+ + +WARNING: Table is for demonstration purposes only, since this is a draft. + +References +========== + +.. _`BEP 0010`: http://www.bittorrent.org/beps/bep_0010.html + + +Copyright +========= + +This document has been placed in the public domain. + + +.. + Local Variables: + mode: indented-text + indent-tabs-mode: nil + sentence-end-double-space: t + fill-column: 70 + coding: utf-8 + End: From 99193e672d6944e4c1e194caac251236e42e0b9a Mon Sep 17 00:00:00 2001 From: Alexander Ivanov Date: Tue, 24 May 2022 20:46:02 +0800 Subject: [PATCH 02/12] Update bep_0056.rst --- beps/bep_0056.rst | 58 +++++++++++++++++++++-------------------------- 1 file changed, 26 insertions(+), 32 deletions(-) diff --git a/beps/bep_0056.rst b/beps/bep_0056.rst index 7aee53c..df99857 100644 --- a/beps/bep_0056.rst +++ b/beps/bep_0056.rst @@ -10,9 +10,8 @@ Abstract ======== -This extension adds a capability for clients to apply on-the-fly -compression on seeded pieces (next - chunks), effectively improving -bandwidth on torrents for clients supporting it. +This extension adds a capability for clients to enable compression of +data streams, effectively improving bandwidth for clients supporting it. Rationale ========= @@ -62,24 +61,23 @@ Example of extension handshake message: { 'c': { 'lz4': 21, - 'density_chameleon': 18, - 'density_cheetah': 13, - 'density_lion': 9, - 'zstd': 0 + 'zstd': 16, + 'density': 7 }, - 'cp': 'lz4' + 'cp': 'zstd' } -Piece compression +Stream compression ================= -Some algorithms can't compress unreasonably small pieces efficiently, so -client should lower algorithm's priority during handshake, depending on -expected compression ratio for defined piece size (down to zero in worst case). -After compression algorithm is negotiated, next pieces are sent compressed. - -If client is caching seeding/recieved pieces in memory, then pieces should -be stored compressed, decompressing when saving to disk or sending to peer +Compression can't be efficient on pieces less than 4 MB, so whole stream is +being compressed instead by clients. During handshake, clients should lower +or raise algorithm's priority depending on expected compression ratio or +any other factors that could impact compression efficiency and performance. +After compression algorithm is negotiated, whole stream is being compressed. + +If client is caching seeding/recieved pieces in memory, then pieces can be +stored compressed, decompressing when saving to disk or sending to peer which not supports that compression. To avoid re-compression pieces when sending, client can specify ``cp`` field during handshake. @@ -88,25 +86,21 @@ Allowed compression algorithms Compression algorithms must satisfy following requirements: -1. Decompression speed must not be lower than 1000MB/s. +1. Decompression speed must not be lower than 500MB/s. 2. It must not produce larger piece than original by 1%. -+-------------+-----------------------------------------------------+ -| identifier | compression algorithm | -+=============+=====================================================+ -| lz4 | LZ4 | -+-------------+-----------------------------------------------------+ -| lz4_hc | High compression derivative of LZ4 | -+-------------+-----------------------------------------------------+ -| d_chameleon | Chameleon algorithm for DENSITY | -+-------------+-----------------------------------------------------+ -| d_cheetah | Cheetah algorithm for DENSITY | -+-------------+-----------------------------------------------------+ -| d_lion | Lion algorithm for DENSITY | -+-------------+-----------------------------------------------------+ - -WARNING: Table is for demonstration purposes only, since this is a draft. ++-------------+-----------------------------+ +| identifier | compression algorithm | ++=============+=============================+ +| lz4 | LZ4 | ++-------------+-----------------------------+ +| density | Chameleon (DENSITY library) | ++-------------+-----------------------------+ +| zstd | ZStandard | ++-------------+-----------------------------+ + +NOTE: Only ``zstd`` compression required to be implemented to use compression. References ========== From d4b3ab4ba1d63932b06e8fba09d40c582cd09d23 Mon Sep 17 00:00:00 2001 From: Alexander Ivanov Date: Wed, 21 Feb 2024 18:14:49 +0800 Subject: [PATCH 03/12] Grammar and consistency fix --- beps/bep_0056.rst | 42 ++++++++++++++++++++---------------------- 1 file changed, 20 insertions(+), 22 deletions(-) diff --git a/beps/bep_0056.rst b/beps/bep_0056.rst index df99857..4a0cab3 100644 --- a/beps/bep_0056.rst +++ b/beps/bep_0056.rst @@ -1,5 +1,5 @@ :BEP: 56 -:Title: Extension for Peers to Send Metadata Files +:Title: Data compression extension :Version: $Revision$ :Last-Modified: $Date$ :Author: Alexander Ivanov @@ -10,49 +10,45 @@ Abstract ======== -This extension adds a capability for clients to enable compression of -data streams, effectively improving bandwidth for clients supporting it. +This extension adds a capability for clients to negotiate and use +compression methods for data streams or torrent pieces, effectively +improving bandwidth for supporting clients. Rationale ========= This extension would allow clients to download files faster, without -using file archivers. Since large files are often precompressed before +using file archivers. Since large files are often pre-compressed before torrent creation, downloaders needs to keep both the archives -(for seeding) and uncompresed files (for own usage). +(for seeding) and uncompressed files (for own usage). Most users prefer to remove such torrents, thus harming proper file -distribution. For example: Organizations using bittorrent for software +distribution. For example: Organizations using Bittorrent for software distribution needs to have centralized storage for new customers, no -matter how many customers already have same software. +matter how many customers have the same software already. Extension header ================ This extension uses the extension protocol (specified in `BEP 0010`_) -to advertize client capability of using chunk compression. It defines +to advertise client capability of using chunk compression. It defines following items in the extension protocol handshake message: +-------+-----------------------------------------------------------+ | name | description | +=======+===========================================================+ -| c | Dictionary of supported compression algorithm which maps | +| c | Dictionary of supported compression algorithms which maps | | | its identifiers to its priority (unsigned 8-bit integer), | | | clients can adjust it based on compression speed/ratio, | -| | hardware support, performance and power mode, et cetera. | +| | hardware support, performance, and power mode et cetera. | | | Priority set to zero means that the compression algorithm | -| | is not supported or disabled by user, The client should | -| | ignore any algorithms it doesn't recognize/malformed. | -+-------+-----------------------------------------------------------+ -| cp | Optional field with prefered compression algorithm. | -| | If client supports that algorithm and it's not disabled, | -| | then it must expect to recieve pieces compressed by that | -| | specified algorithm. | +| | is not supported or disabled by user, the client must | +| | ignore unknown algorithms. | +-------+-----------------------------------------------------------+ -Compression algorithm is selected by taking dictionary item with highest -priority from intersection of items supported by both peers, if there -isn't any suitable compression algorithm - compression will be disabled. +The compression algorithm is selected by taking the dictionary item with +highest priority from intersection of items supported by both peers, +if there isn't any suitable compression algorithm - compression will be disabled. Example of extension handshake message: @@ -84,9 +80,11 @@ sending, client can specify ``cp`` field during handshake. Allowed compression algorithms ------------------------------ -Compression algorithms must satisfy following requirements: +Compression algorithms must satisfy the following requirements: + +1. Decompression speed must not be lower than 500 MB/s. -1. Decompression speed must not be lower than 500MB/s. +2. It must not produce a larger piece than the original by 1%. 2. It must not produce larger piece than original by 1%. From 853c3fa9b1f896209be4c648859330833fa46ff4 Mon Sep 17 00:00:00 2001 From: Alexander Ivanov Date: Wed, 21 Feb 2024 18:17:42 +0800 Subject: [PATCH 04/12] Rework --- beps/bep_0056.rst | 67 +++++++++++++++++++++++++++++++---------------- 1 file changed, 45 insertions(+), 22 deletions(-) diff --git a/beps/bep_0056.rst b/beps/bep_0056.rst index 4a0cab3..78c8262 100644 --- a/beps/bep_0056.rst +++ b/beps/bep_0056.rst @@ -56,26 +56,37 @@ Example of extension handshake message: { 'c': { - 'lz4': 21, - 'zstd': 16, - 'density': 7 - }, - 'cp': 'zstd' + 'p_zstd': 255, + 's_zstd': 153, + 'p_lz4': 106, + 'p_density': 70, + 's_lz4': 41, + 's_density': 37 + } } -Stream compression -================= -Compression can't be efficient on pieces less than 4 MB, so whole stream is -being compressed instead by clients. During handshake, clients should lower -or raise algorithm's priority depending on expected compression ratio or -any other factors that could impact compression efficiency and performance. -After compression algorithm is negotiated, whole stream is being compressed. - -If client is caching seeding/recieved pieces in memory, then pieces can be -stored compressed, decompressing when saving to disk or sending to peer -which not supports that compression. To avoid re-compression pieces when -sending, client can specify ``cp`` field during handshake. +Compression methods +=================== +Extension provides two approaches (methods) to compression, which have +their own trade-offs, so choice between these should be made by clients +on per-torrent basis, using its metadata (properties like piece size). + +With **by-piece compression** method, client must compress each piece +individually, which lowers overall compression ratio but result can +be stored in cache and reused, probably providing more efficiency. +If the client is caching compressed pieces in memory, then it can be +decompressed when saving to disk or sending to peer, which not supports +compression. To reduce piece re-compression, client should raise +current algorithm's priority during handshake. This method has low +efficiency with pieces smaller than 4 MB. + +Clients using **stream compression** method instead compresses whole +data stream, so compression ratio should be higher. During handshake, +clients should lower or raise algorithm's priority depending on expected +factors that could impact compression efficiency and performance. This +method can introduce performance issues if used on thousands of +simultaneous connections. Allowed compression algorithms ------------------------------ @@ -86,19 +97,31 @@ Compression algorithms must satisfy the following requirements: 2. It must not produce a larger piece than the original by 1%. -2. It must not produce larger piece than original by 1%. +For consistency, identifiers are prefixed by ``p_`` or ``s_`` +for "piece" and "stream" compression methods accordingly. +-------------+-----------------------------+ | identifier | compression algorithm | +=============+=============================+ -| lz4 | LZ4 | +| p_lz4 | LZ4 | ++-------------+-----------------------------+ +| s_lz4 | LZ4 | ++-------------+-----------------------------+ +| p_density | Chameleon (DENSITY library) | +-------------+-----------------------------+ -| density | Chameleon (DENSITY library) | +| s_density | Chameleon (DENSITY library) | +-------------+-----------------------------+ -| zstd | ZStandard | +| p_zstd | ZStandard | +-------------+-----------------------------+ +| s_zstd | ZStandard | ++-------------+-----------------------------+ + +This specification deliberately doesn't provide negotiation +for configuration options, default ones must be used unless +specified otherwise. -NOTE: Only ``zstd`` compression required to be implemented to use compression. +**NOTE**: Currently, only ``p_zstd`` and ``s_zstd`` algorithms +are required for implementation. References ========== From 3fc28499000447f0eec7ef3fcee3600a5b4f6796 Mon Sep 17 00:00:00 2001 From: Alexander Ivanov Date: Wed, 21 Feb 2024 18:26:09 +0800 Subject: [PATCH 05/12] Quickfix --- beps/bep_0056.rst | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/beps/bep_0056.rst b/beps/bep_0056.rst index 78c8262..7815ca3 100644 --- a/beps/bep_0056.rst +++ b/beps/bep_0056.rst @@ -54,16 +54,16 @@ Example of extension handshake message: :: - { - 'c': { - 'p_zstd': 255, + { + 'c': { + 'p_zstd': 255, 's_zstd': 153, 'p_lz4': 106, - 'p_density': 70, + 'p_density': 70, 's_lz4': 41, - 's_density': 37 - } - } + 's_density': 37 + } + } Compression methods From 6c17e1df25bb872aa7bc26a8ddce2144f3bf5d00 Mon Sep 17 00:00:00 2001 From: Alexander Ivanov Date: Thu, 22 Feb 2024 16:44:42 +0800 Subject: [PATCH 06/12] Rolled back ID prefixing --- beps/bep_0056.rst | 22 ++++------------------ 1 file changed, 4 insertions(+), 18 deletions(-) diff --git a/beps/bep_0056.rst b/beps/bep_0056.rst index 7815ca3..f523a8a 100644 --- a/beps/bep_0056.rst +++ b/beps/bep_0056.rst @@ -97,31 +97,17 @@ Compression algorithms must satisfy the following requirements: 2. It must not produce a larger piece than the original by 1%. -For consistency, identifiers are prefixed by ``p_`` or ``s_`` -for "piece" and "stream" compression methods accordingly. - +-------------+-----------------------------+ | identifier | compression algorithm | +=============+=============================+ -| p_lz4 | LZ4 | -+-------------+-----------------------------+ -| s_lz4 | LZ4 | -+-------------+-----------------------------+ -| p_density | Chameleon (DENSITY library) | +| lz4 | LZ4 | +-------------+-----------------------------+ -| s_density | Chameleon (DENSITY library) | +| density | Chameleon (DENSITY library) | +-------------+-----------------------------+ -| p_zstd | ZStandard | +| zstd | ZStandard | +-------------+-----------------------------+ -| s_zstd | ZStandard | -+-------------+-----------------------------+ - -This specification deliberately doesn't provide negotiation -for configuration options, default ones must be used unless -specified otherwise. -**NOTE**: Currently, only ``p_zstd`` and ``s_zstd`` algorithms -are required for implementation. +**NOTE**: Currently, only ``zstd`` algorithm is required for implementation. References ========== From 4896a5ffea700cca61a6606c5bfe55d570b73c19 Mon Sep 17 00:00:00 2001 From: Alexander Ivanov Date: Thu, 22 Feb 2024 16:45:31 +0800 Subject: [PATCH 07/12] Renamed methods to modes --- beps/bep_0056.rst | 55 ++++++----------------------------------------- 1 file changed, 7 insertions(+), 48 deletions(-) diff --git a/beps/bep_0056.rst b/beps/bep_0056.rst index f523a8a..38848be 100644 --- a/beps/bep_0056.rst +++ b/beps/bep_0056.rst @@ -8,11 +8,9 @@ :Created: 31-Sep-2021 :Post-History: -Abstract -======== -This extension adds a capability for clients to negotiate and use -compression methods for data streams or torrent pieces, effectively -improving bandwidth for supporting clients. +Data compression extension adds a capability for clients to negotiate +and use compression algorithms to improve bandwidth. + Rationale ========= @@ -26,53 +24,14 @@ distribution. For example: Organizations using Bittorrent for software distribution needs to have centralized storage for new customers, no matter how many customers have the same software already. -Extension header -================ - -This extension uses the extension protocol (specified in `BEP 0010`_) -to advertise client capability of using chunk compression. It defines -following items in the extension protocol handshake message: -+-------+-----------------------------------------------------------+ -| name | description | -+=======+===========================================================+ -| c | Dictionary of supported compression algorithms which maps | -| | its identifiers to its priority (unsigned 8-bit integer), | -| | clients can adjust it based on compression speed/ratio, | -| | hardware support, performance, and power mode et cetera. | -| | Priority set to zero means that the compression algorithm | -| | is not supported or disabled by user, the client must | -| | ignore unknown algorithms. | -+-------+-----------------------------------------------------------+ - - - -The compression algorithm is selected by taking the dictionary item with -highest priority from intersection of items supported by both peers, -if there isn't any suitable compression algorithm - compression will be disabled. - -Example of extension handshake message: - -:: - - { - 'c': { - 'p_zstd': 255, - 's_zstd': 153, - 'p_lz4': 106, - 'p_density': 70, - 's_lz4': 41, - 's_density': 37 - } - } - -Compression methods +Compression modes =================== -Extension provides two approaches (methods) to compression, which have +Extension provides two approaches (modes) to compression, which have their own trade-offs, so choice between these should be made by clients on per-torrent basis, using its metadata (properties like piece size). -With **by-piece compression** method, client must compress each piece +With **by-piece compression** mode, client must compress each piece individually, which lowers overall compression ratio but result can be stored in cache and reused, probably providing more efficiency. If the client is caching compressed pieces in memory, then it can be @@ -81,7 +40,7 @@ compression. To reduce piece re-compression, client should raise current algorithm's priority during handshake. This method has low efficiency with pieces smaller than 4 MB. -Clients using **stream compression** method instead compresses whole +Clients using **stream compression** mode instead compresses whole data stream, so compression ratio should be higher. During handshake, clients should lower or raise algorithm's priority depending on expected factors that could impact compression efficiency and performance. This From f75109aabecfae15783eb49a1292f574ae039286 Mon Sep 17 00:00:00 2001 From: Alexander Ivanov Date: Thu, 22 Feb 2024 16:45:53 +0800 Subject: [PATCH 08/12] Rewriting protocol extension --- beps/bep_0056.rst | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/beps/bep_0056.rst b/beps/bep_0056.rst index 38848be..a57c3a2 100644 --- a/beps/bep_0056.rst +++ b/beps/bep_0056.rst @@ -47,6 +47,27 @@ factors that could impact compression efficiency and performance. This method can introduce performance issues if used on thousands of simultaneous connections. + +Protocol Extension +================== + +This extension uses the extension protocol [#BEP-10]_ to advertise +client capability regarding compression, as well as introducing a +new messages in the extension handshake: + +.. parsed-literal:: + + { + m: { + crequest: **, + cresponse: **, + cpiece: **, + ... + }, + ... + } + + Allowed compression algorithms ------------------------------ From 7c5bc3c564f11b9e83b07636ba3deece1a17322a Mon Sep 17 00:00:00 2001 From: Alexander Ivanov Date: Thu, 22 Feb 2024 17:11:30 +0800 Subject: [PATCH 09/12] Describe new messages --- beps/bep_0056.rst | 73 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) diff --git a/beps/bep_0056.rst b/beps/bep_0056.rst index a57c3a2..0bf3748 100644 --- a/beps/bep_0056.rst +++ b/beps/bep_0056.rst @@ -68,6 +68,79 @@ new messages in the extension handshake: } +The ```crequest``` message itself consists of the extension message header +and the following bencoded payload: + +.. parsed-literal:: + + { + "algos": [ + [ + **, + ** + ], + ... + ], + "pref": + } + + +Connecting client fills ```algos``` list with supported compression +algorithms, sorted by preference in descending order. Clients can adjust +preference based on compression speed/ratio, hardware acceleration support, +performance and other factors. This list can be empty. + +```pref``` field specifies algorithm for compression preferred by client. + +Flags in bit-array are defined as follows: + + ==== =========================================== + Bit when set + ==== =========================================== + 0x01 supports stream mode for decompression + 0x02 supports piece mode for decompression + 0x04 (reserved) + 0x08 (reserved) + 0x10 supports stream mode for compression + 0x20 supports piece mode for compression + 0x40 (reserved) + 0x80 (reserved) + ==== =========================================== + + +The ```cresponse``` message is send in response to ```crequest```, consists of +the extension message header and the following bencoded payload: + +.. parsed-literal:: + + { + "recv": [ + **, + *<0x01 or 0x02 for stream/piece mode (positive integer)>* + ], + "send": [ + **, + *<0x10 0r 0x20 for stream/piece mode (positive integer)>* + ], + "resend": ** + } + + +Receiving client select appropriate algorithms and compression modes and +sets ```recv``` and ```send``` fields, which also can be empty. After that +message compression must be enabled/disabled between two clients. Responding +client can ask requesting client to send new request by settings ```resend``` +field is set to 1. + +The ```cpiece``` has same contents as ```piece``` message, but payload is +compressed, in piece mode both types of messages can be used. + +Connecting client can send ```crequest``` message at any point of time, +but should do that right after handshake. Responding client must respond +to that ```cresponse``` message, but also can send that message at any +point of time to disable compression or ask for new request. + + Allowed compression algorithms ------------------------------ From dc66ae2e1b8f19c39e8fa8482385f0c51c097eb0 Mon Sep 17 00:00:00 2001 From: Alexander Ivanov Date: Thu, 22 Feb 2024 17:17:58 +0800 Subject: [PATCH 10/12] Update email --- beps/bep_0056.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/beps/bep_0056.rst b/beps/bep_0056.rst index 0bf3748..6eba0c6 100644 --- a/beps/bep_0056.rst +++ b/beps/bep_0056.rst @@ -2,7 +2,7 @@ :Title: Data compression extension :Version: $Revision$ :Last-Modified: $Date$ -:Author: Alexander Ivanov +:Author: Alexander Ivanov :Status: Draft :Type: Standards Track :Created: 31-Sep-2021 From 5615857662414dc4830148a6b1cc0b9c2c94e84e Mon Sep 17 00:00:00 2001 From: Alexander Ivanov Date: Thu, 22 Feb 2024 17:18:36 +0800 Subject: [PATCH 11/12] TODO: Make proper algorithm list --- beps/bep_0056.rst | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/beps/bep_0056.rst b/beps/bep_0056.rst index 6eba0c6..1eb676b 100644 --- a/beps/bep_0056.rst +++ b/beps/bep_0056.rst @@ -141,14 +141,8 @@ to that ```cresponse``` message, but also can send that message at any point of time to disable compression or ask for new request. -Allowed compression algorithms ------------------------------- - -Compression algorithms must satisfy the following requirements: - -1. Decompression speed must not be lower than 500 MB/s. - -2. It must not produce a larger piece than the original by 1%. +Compression algorithm list +-------------------------- +-------------+-----------------------------+ | identifier | compression algorithm | @@ -160,7 +154,8 @@ Compression algorithms must satisfy the following requirements: | zstd | ZStandard | +-------------+-----------------------------+ -**NOTE**: Currently, only ``zstd`` algorithm is required for implementation. +This is a list of known algorithms, to submit a allocation please +contact author of this specification. References ========== From ed2add61a50e903b1100f7a829d1ea57c61a145a Mon Sep 17 00:00:00 2001 From: Alexander Ivanov Date: Thu, 22 Feb 2024 17:21:44 +0800 Subject: [PATCH 12/12] Add stream mode clarification --- beps/bep_0056.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/beps/bep_0056.rst b/beps/bep_0056.rst index 1eb676b..066203c 100644 --- a/beps/bep_0056.rst +++ b/beps/bep_0056.rst @@ -140,6 +140,9 @@ but should do that right after handshake. Responding client must respond to that ```cresponse``` message, but also can send that message at any point of time to disable compression or ask for new request. +If using stream mode compression, everything past ```crequest``` message +is (un)compressed by algorithm specified in that message. + Compression algorithm list --------------------------