RFC4464 日本語訳
4464 Signaling Compression (SigComp) Users' Guide. A. Surtees, M.West. May 2006. (Format: TXT=79643 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Surtees
Request for Comments: 4464 M. West
Category: Informational Siemens/Roke Manor Research
May 2006
コメントを求めるワーキンググループA.サーティーズの要求をネットワークでつないでください: 4464年のM.の西カテゴリ: 情報のシーメンス/Roke荘園研究2006年5月
Signaling Compression (SigComp) Users' Guide
シグナリング圧縮(SigComp)ユーザのガイド
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document provides an informational guide for users of the Signaling Compression (SigComp) protocol. The aim of the document is to assist users when making SigComp implementation decisions, for example, the choice of compression algorithm and the level of robustness against lost or misordered packets.
このドキュメントはSignaling Compression(SigComp)プロトコルのユーザに情報のガイドを提供します。 ドキュメントの目的は例えばSigComp実現決定を圧縮アルゴリズムの選択と無くなっているかmisorderedされたパケットに対する丈夫さのレベルにするとき、ユーザを補助することです。
Surtees & West Informational [Page 1] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[1ページ]のRFC4464SigCompユーザのガイド2006年5月
Table of Contents
目次
1. Introduction ....................................................3
2. Overview of the User Guide ......................................3
3. UDVM Assembly Language ..........................................4
3.1. Lexical Level ..............................................4
3.2. Syntactic Level ............................................5
3.2.1. Expressions .........................................7
3.2.2. Instructions ........................................8
3.2.3. Directives ..........................................9
3.2.4. Labels .............................................10
3.3. Uploading the Bytecode to the UDVM ........................11
4. Compression Algorithms .........................................12
4.1. Well-known Compression Algorithms .........................12
4.1.1. LZ77 ...............................................12
4.1.2. LZSS ...............................................16
4.1.3. LZW ................................................18
4.1.4. DEFLATE ............................................21
4.1.5. LZJH ...............................................24
4.2. Adapted Algorithms ........................................28
4.2.1. Modified DEFLATE ...................................28
5. Additional SigComp Mechanisms ..................................31
5.1. Acknowledging a State Item ................................32
5.2. Static Dictionary .........................................33
5.3. CRC Checksum ..............................................34
5.4. Announcing Additional Resources ...........................35
5.5. Shared Compression ........................................37
6. Security Considerations ........................................38
7. Acknowledgements ...............................................38
8. Intellectual Property Right Considerations .....................38
9. Informative References .........................................38
Appendix A. UDVM Bytecode for the Compression Algorithms ..........40
A.1. Well-known Algorithms .....................................40
A.1.1. LZ77 ..............................................40
A.1.2. LZSS ..............................................40
A.1.3. LZW ...............................................40
A.1.4. DEFLATE ...........................................40
A.1.5. LZJH ..............................................41
A.2. Adapted Algorithms ........................................41
A.2.1. Modified DEFLATE ...................................41
1. 序論…3 2. ユーザガイドの概観…3 3. UDVMアセンブリ言語…4 3.1. 語彙レベル…4 3.2. 構文のレベル…5 3.2.1. 表現…7 3.2.2. 指示…8 3.2.3. 指示…9 3.2.4. ラベル…10 3.3. バイトコードをUDVMにアップロードします…11 4. 圧縮アルゴリズム…12 4.1. 周知の圧縮アルゴリズム…12 4.1.1. LZ77…12 4.1.2. LZSS…16 4.1.3. LZW…18 4.1.4. 空気を抜いてください…21 4.1.5. LZJH…24 4.2. アルゴリズムを適合させます…28 4.2.1. 変更されて、空気を抜いてください…28 5. 追加SigCompメカニズム…31 5.1. 州の項目を承認します…32 5.2. 静的な辞書…33 5.3. CRCチェックサム…34 5.4. 追加リソースを発表します…35 5.5. 圧縮を共有します…37 6. セキュリティ問題…38 7. 承認…38 8. 知的所有権問題…38 9. 有益な参照…圧縮アルゴリズムのための38付録A.UDVMバイトコード…40 A.1。 周知のアルゴリズム…40 A.1.1。 LZ77…40 A.1.2。 LZSS…40 A.1.3。 LZW…40 A.1.4。 空気を抜いてください…40 A.1.5。 LZJH…41 A.2。 アルゴリズムを適合させます…41 A.2.1。 変更されて、空気を抜いてください…41
Surtees & West Informational [Page 2] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[2ページ]のRFC4464SigCompユーザのガイド2006年5月
1. Introduction
1. 序論
This document provides an informational guide for users of the SigComp protocol, RFC 3320 [2]. The idea behind SigComp is to standardize a Universal Decompressor Virtual Machine (UDVM) that can be programmed to understand the output of many well-known compressors including DEFLATE [8] and LZW [7]. The bytecode for the chosen compression algorithm is uploaded to the UDVM as part of the compressed data.
このドキュメントはSigCompプロトコル、RFC3320[2]のユーザに情報のガイドを提供します。 SigCompの後ろの考えはDEFLATE[8]とLZW[7]を含む多くの周知のコンプレッサーの出力を理解するようにプログラムできるUniversal Decompressor Virtual Machine(UDVM)を標準化することです。 選ばれた圧縮アルゴリズムのためのバイトコードは圧縮されたデータの一部としてUDVMにアップロードされます。
The basic SigComp RFC describes the actions that an endpoint must take upon receiving a SigComp message. However, the entity responsible for generating new SigComp messages (the SigComp compressor) is left as an implementation decision; any compressor can be used provided that it generates SigComp messages that can be successfully decompressed by the receiving endpoint.
基本的なSigComp RFCはSigCompメッセージを受け取る終点が持っていかなければならない動作について説明します。 しかしながら、新しいSigCompメッセージ(SigCompコンプレッサー)を発生させるのに原因となる実体は実現決定として残されます。 受信終点で首尾よく減圧できるSigCompメッセージを発生させれば、どんなコンプレッサーも使用できます。
This document gives examples of a number of different compressors that can be used by the SigComp protocol. It also gives examples of how to use some of the mechanisms (such as acknowledgements) described in RFC 3321 [3].
このドキュメントはSigCompプロトコルで使用できる多くの異なったコンプレッサーに関する例を出します。 また、それはどうRFC3321[3]で説明されたメカニズム(承認などの)のいくつかを使用するかに関する例を出します。
2. Overview of the User Guide
2. ユーザガイドの概観
When implementing a SigComp compressor, the first step is to choose a compression algorithm that can encode the application messages into a (hopefully) smaller form. Since SigComp can upload bytecode for new algorithms to the receiving endpoint, arbitrary compression algorithms can be supported provided that suitable bytecode has been written for the corresponding decompressor.
SigCompコンプレッサーを実行するとき、第一歩は(希望をいだいて)より小さいフォームにアプリケーションメッセージをコード化できる圧縮アルゴリズムを選ぶことです。 SigCompが新しいアルゴリズムのために受信終点にバイトコードをアップロードできるので、適当なバイトコードが対応する減圧装置のために書かれれば、任意の圧縮アルゴリズムを支持できます。
This document provides example bytecode for the following algorithms:
このドキュメントは例のバイトコードを以下のアルゴリズムに提供します:
1. LZ77 2. LZSS 3. LZW 4. DEFLATE 5. LZJH
1. LZ77 2。 LZSS3。 LZW4。 5に空気を抜かせてください。 LZJH
Any of the above algorithms may be useful depending on the desired compression ratio, processing and memory requirements, code size, implementation complexity, and Intellectual Property (IPR) considerations.
必要な圧縮比、処理、およびメモリ要件によって、上のアルゴリズムのどれかは役に立つかもしれません、コードサイズ、実現の複雑さ、およびIntellectual Property(IPR)問題。
As well as encoding the application messages using the chosen algorithm, the SigComp compressor is responsible for ensuring that messages can be correctly decompressed even if packets are lost or misordered during transmission. The SigComp feedback mechanism can
選ばれたアルゴリズムを使用することでアプリケーションメッセージをコード化することと同様に、パケットがトランスミッションの間、失われている、またはmisorderedされても正しくメッセージを減圧できるのを確実にするのにSigCompコンプレッサーは原因となります。 SigCompフィードバック・メカニズムはそうすることができます。
Surtees & West Informational [Page 3] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[3ページ]のRFC4464SigCompユーザのガイド2006年5月
be used to acknowledge successful decompression at the remote endpoint.
使用されて、遠く離れた終点でうまくいっている減圧を承諾してください。
The following robustness techniques and other mechanisms specific to the SigComp environment are covered in this document:
SigComp環境に特定の以下の丈夫さのテクニックと他のメカニズムは本書では含まれています:
1. Acknowledgements using the SigComp feedback mechanism 2. Static dictionary 3. Cyclic redundancy code (CRC) checksum 4. Announcing additional resources 5. Shared compression
1. SigCompフィードバック・メカニズム2を使用する承認。 静的な辞書3。 周期的な冗長コード(CRC)チェックサム4。 追加リソース5を発表します。 共有された圧縮
Any or all of the above mechanisms can be implemented in conjunction with the chosen compression algorithm. An example subroutine of UDVM bytecode is provided for each of the mechanisms; these subroutines can be added to the bytecode for one of the basic compression algorithms. (Note: The subroutine or the basic algorithm may require minor modification to ensure they work together correctly.)
選ばれた圧縮アルゴリズムに関連して上のメカニズムのいずれかすべてを実行できます。 UDVMバイトコードに関する例のサブルーチンをそれぞれのメカニズムに提供します。 基本的な圧縮アルゴリズムの1つのためにこれらのサブルーチンをバイトコードに加えることができます。(注意: サブルーチンか基本的なアルゴリズムが彼らが一緒に正しく働いているのを保証するために小さい方の変更を必要とするかもしれません。)
3. UDVM Assembly Language
3. UDVMアセンブリ言語
Writing UDVM programs directly in bytecode would be a daunting task, so a simple assembly language is provided to facilitate the creation of new decompression algorithms. The assembly language includes mnemonic codes for each of the UDVM instructions, as well as simple directives for evaluating integer expressions, padding the bytecode, and so forth.
直接バイトコードでUDVMにプログラムを書くのは、困難な仕事でしょう、したがって、新しい減圧アルゴリズムの創造を容易にするために簡単なアセンブリ言語を提供します。アセンブリ言語はそれぞれのUDVM指示のための簡略命令コードを含んでいます、バイトコードを水増しして、整数表現を評価するための簡単な指示などと同様に。
The syntax of the UDVM assembly language uses the customary two-level description technique, partitioning the grammar into a lexical and a syntactic level.
UDVMアセンブリ言語の構文は通例の2レベルの記述手法を使用します、語彙レベルと構文のレベルに文法を仕切って。
3.1. Lexical Level
3.1. 語彙レベル
On a lexical level, a string of assembly consists of zero or more tokens optionally separated by whitespace. Each token can be a text name, an instruction opcode, a delimiter, or an integer (specified as decimal, binary, or hex).
語彙レベルでは、アセンブリのストリングは空白によって任意に切り離されたゼロか、より多くの象徴から成ります。 各象徴は、原文名、指示opcode、デリミタ、または整数であるかもしれません(小数、バイナリー、または十六進法として、指定されます)。
Surtees & West Informational [Page 4] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[4ページ]のRFC4464SigCompユーザのガイド2006年5月
The following ABNF description, RFC 4234 [1], specifies the syntax of a token:
以下のABNF記述(RFC4234[1])は象徴の構文を指定します:
token = (name / opcode / delimiter / dec / bin / hex)
name = (lowercase / "_") 0*(lowercase / digit / "_")
opcode = uppercase *(uppercase / digit / "-")
delimiter = "." / "," / "!" / "$" / ":" / "(" / ")" /
operator
dec = 1*(digit)
bin = "0b" 1*("0" / "1")
hex = "0x" 1*(hex-digit)
hex-digit = digit / %x41-46 / %x61-66
digit = %x30-39
uppercase = %x41-5a
lowercase = %x61-7a
operator = "+" / "-" / "*" / "/" / "%" / "&" / "|" /
"^" / "~" / "<<" / ">>"
「象徴=(name / opcode /デリミタ/DEC社/容器/十六進法)名義の=(小文字の/"_")0*(小文字の/ケタ/"_")opcode=は*(大文字/ケタ/「-」)デリミタ=を大文字する」、」 / "," / "!" / "$" / ":" オペレータ..DEC社..等しい..ケタ..容器..0インチ..1インチ..魔法をかける..十六進法..ケタ..十六進法..ケタ..ケタ..ケタ..大文字..小文字で印刷..オペレータ|「/"^"/「~」/「<<」/「>>」」
When parsing for tokens, the longest match is applied, i.e., a token is the longest string that matches the <token> rule specified above.
象徴のために分析するとき、最も長いマッチが適用されている、すなわち、象徴は上で指定された<象徴>規則に合っている最も長いストリングです。
The syntax of whitespace and comments is specified by the following ABNF:
空白とコメントの構文は以下のABNFによって指定されます:
ws = *(%x09 / %x0a / %x0d / %x20 / comment)
comment = ";" *(%x00-09 / %x0b-0c / %x0e-ff)
(%x0a / %x0d)
「wsは*(%x09/%x0a/%x0d/%x20/コメント)コメント=と等しい」;、」 *(%x00-09/%x0b-0c/%x0e-ff) (%x0a/%x0d)
Whitespace that matches <ws> is skipped between tokens, but serves to terminate the longest match for a token.
<ws>に合っている空白は、象徴の間でスキップされますが、象徴のための最も長いマッチを終えるのに役立ちます。
Comments are specified by the symbol ";" and are terminated by the end of the line, for example:
「コメントはシンボルによって指定される」;、」 そして、行の終わりまでには、例えば、終えられます:
LOAD (temp, 1) ; This is a comment.
ロードしてください(1歳の臨時)。 これはコメントです。
Any other input is a syntax error.
いかなる他の入力も構文エラーです。
When parsing on the lexical level, the string of assembly should be divided up into a list of successive tokens. The whitespace and comments should also be deleted. The assembly should then be parsed on the syntactic level as explained in Section 3.2.
語彙レベルで分析するとき、アセンブリのストリングは連続した象徴のリストに分割されるべきです。 また、空白とコメントは削除されるべきです。 そして、アセンブリはセクション3.2で説明されるように構文のレベルで分析されるべきです。
3.2. Syntactic Level
3.2. 構文のレベル
Once the string of assembly has been divided into tokens as per Section 3.1, the next step is to convert the assembly into a string of UDVM bytecode.
一度、アセンブリのストリングは、次のステップがセクション3.1に従ってUDVMバイトコードのストリングにアセンブリを変換することであるので、象徴に分割されたことがあります。
Surtees & West Informational [Page 5] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[5ページ]のRFC4464SigCompユーザのガイド2006年5月
On a syntactic level, a string of assembly consists of zero or more instructions, directives, or labels, each of which is itself built up from one or more lexical tokens.
構文のレベルでは、アセンブリのストリングはゼロ、より多くの指示、指示、またはラベルから成ります。それは1個以上の字句からそれぞれ確立されます。
The following ABNF description specifies the syntax of the assembly language. Note that the lexical parsing step is assumed to have been carried out; so in particular, the boundaries between tokens are already known, and the comments and whitespace have been deleted:
以下のABNF記述はアセンブリ言語の構文を指定します。 語彙構文解析ステップが行われたと思われることに注意してください。 あまりに特に、象徴の間の境界は既に知られています、そして、コメントと空白は削除されました:
assembly = *(instruction / directive / label)
instruction = opcode ["(" operand *("," operand) ")"]
operand = [["$"] expression]
; Operands can be left blank if they can
; be automatically inferred by the
; compiler, e.g., a literal operand
; that specifies the total number of
; operands for the instruction.
; When "$" is prepended to an operand,
; the corresponding integer is an
; address rather than the actual operand
; value. This symbol is mandatory for
; reference operands, optional for
; multitypes and addresses, and
; disallowed for literals.
label = ":" name
directive = padding / data / set / readonly /
unknown-directive
unknown-directive = name ["(" expression *("," expression) ")"]
; The parser can ignore unknown
; directives. The resulting bytecode
; may or may not generate the expected
; results.
padding = ("pad" / "align" / "at") "(" expression ")"
data = ("byte" / "word") "(" expression *(","
expression) ")"
readonly = "readonly" "(" "0" / "1" ")"
set = "set" "(" name "," expression ")"
expression = value / "(" expression operator expression ")"
value = dec / bin / hex / name / "." / "!"
; "." is the location of this
; instruction/directive, whereas "!" is
; the location of the closest
; DECOMPRESSION-FAILURE
アセンブリ=*(指示/指示/ラベル)指示がopcodeと等しい、[「(「オペランド*、(「」、オペランド)、」、)、」、]、オペランド=[[「$」]表現]。 それらがままにできるなら、オペランドを空白のままにできます。 自動的に推論される、。 コンパイラ、例えば、文字通りのオペランド。 それが総数を指定する、。 指示のためのオペランド。 ; 「$」がオペランドにprependedされると。 対応する整数がそうである、。 実際のオペランドよりむしろアドレス。 値。 このシンボルが義務的である、。 参照オペランドで、任意。 そして、「マルチ-タイプ」とアドレス、。 「誤字誤植ラベル=のために禁じられる」:、」 名前指示の=詰め物/データ/セット/ readonly / unknown-指示未知の指示=名、[「(「式*、(「」、表現)、」、)、」、]、。 パーサは未知を無視できます。 指示。 結果として起こるバイトコード。 予想を発生させるかもしれません。 結果..そっと歩く..パッド..並べる..表現..データ..等しい..バイト..単語..表現..表現..等しい..0インチ..1インチ..セット..セット..名前..表現..表現..等しい..値..表現..オペレータ..表現..値..DEC社..捨てる..魔法をかける..命名 / "!" ; 「. 」 この位置です。 “!"はそうですが、指示/指示 最も近くの位置。 減圧失敗
The following sections define how to convert the instructions, labels and directives into UDVM bytecode:
以下のセクションは指示、ラベル、および指示をUDVMバイトコードに変換する方法を定義します:
Surtees & West Informational [Page 6] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[6ページ]のRFC4464SigCompユーザのガイド2006年5月
3.2.1. Expressions
3.2.1. 表現
The operand values needed by particular instructions or directives can be given in the form of expressions. An expression can include one or more values specified as decimal, binary, or hex (binary values are preceded by "0b" and hex values are preceded by "0x"). The expression may also include one or more of the following operators:
表現の形で詳細な指示か指示で必要であるオペランド値は与えることができます。 表現は10進と、2進として指定された1つ以上の値、または十六進法を含むことができます(2進の値は"0b"によって先行されています、そして、十六進法値は"0x"によって先行されています)。 また、表現は以下のオペレータのより多くのひとりを含むかもしれません:
"+" Addition
"-" Subtraction
"*" Multiplication
"/" Integer division
"%" Modulo arithmetic (a%b := a modulo b)
"&" Binary AND
"|" Binary OR
"^" Binary XOR
"~" Binary XNOR
"<<" Binary LSHIFT
">>" Binary RSHIFT
「「+」添加「-」引き算「*」乗法」/、」 整数分割「%」モジュロ演算、(1%、b a法のb)“&"の2進の:=AND、」|「バイナリーか"^"2進のXOR「~」2進のXNOR「<<」2進のLSHIFT「>>」2進のRSHIFT」
The operands for each operator must always be surrounded by parentheses so that the order in which the operators should be evaluated is clear. For example:
括弧で各オペレータのためのオペランドをいつも囲まなければならないので、オペレータが評価されるべきであるオーダーは明確です。 例えば:
((1 + (2 * 3)) & (0xabcd - 0b00101010)) gives the result 3.
(1+(2*3))、結果3を与えます(0xabcd--0b00101010)。
Expressions can also include the special values "." and "!". When the symbol "." is encountered, it is replaced by the location in the bytecode of the current instruction/directive. When the symbol "!" is encountered it is replaced by the location in the bytecode of the closest DECOMPRESSION-FAILURE instruction (i.e., the closest zero byte). This can be useful when writing UDVM instructions that call a decompression failure, for example:
. 」 「表現はそうすることができます、また、特別な値を含めてください、」“!"。 「シンボルであるときに」」、遭遇していて、現在の指示/指示のバイトコードにおける位置はそれを取り替えます。 シンボル“!"に遭遇するとき、最も厳密な減圧失敗指示のバイトコードにおける位置はそれを取り替えます(すなわち、最も近いのはバイトのゼロに合っています)。 例えば、呼ぶUDVM指示に減圧失敗を書くとき、これは役に立つ場合があります:
INPUT-BYTES (1, temp, !)
入力バイト(1臨時!)
The above instruction causes a decompression failure to occur if it tries to input data from beyond the end of the compressed message.
圧縮されたメッセージの終わりを超えてデータを入力しようとするなら、上の指示は起こらない減圧のことを引き起こします。
Note: When using "!" in the assembly language to generate bytecode, care must be taken to ensure that the address of the zero used at bytecode generation time will still contain zero when the bytecode is run. The readonly directive (see Section 3.2.3) can be used to do this.
以下に注意してください。 バイトコードを発生させるのにアセンブリ言語で“!"を使用するとき、バイトコードが走るとき、それでも、バイトコード世代時間に使用されたゼロもののアドレスがゼロを含むのを保証するために注意しなければなりません。 これをするのに、readonly指示(セクション3.2.3を見る)を使用できます。
Surtees & West Informational [Page 7] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[7ページ]のRFC4464SigCompユーザのガイド2006年5月
It is also possible to assign integer values to text names: when a text name is encountered in an expression, it is replaced by the integer value assigned to it. Section 3.2.3 explains how to assign integer values to text names.
また、整数値を原文名に割り当てるのも可能です: 表現で原文名に遭遇するとき、それをそれに割り当てられた整数値に取り替えます。 セクション3.2 .3 整数値を原文名に割り当てる方法を説明します。
3.2.2. Instructions
3.2.2. 指示
A UDVM instruction is specified by the instruction opcode followed by zero or more operands. The instruction operands are enclosed in parentheses and separated by commas, for example:
UDVM指示はゼロか、より多くのオペランドがあとに続いた指示opcodeによって指定されます。 指示オペランドは、括弧に同封されて、例えば、コンマによって切り離されます:
ADD ($3, 4)
加えてください。($3, 4)
When generating the bytecode, the parser should replace the instruction opcode with the corresponding 1-byte value as per Figure 11 of SigComp [2].
バイトコードを発生させるとき、パーサはSigComp[2]の図11に従って指示opcodeを対応する1バイトの値に取り替えるはずです。
Each operand consists of an expression that evaluates to an integer, optionally preceded by the symbol "$". This symbol indicates that the supplied integer value must be interpreted as the memory address at which the operand value can be found, rather than the actual operand value itself.
各オペランドはそれが「$」というシンボルが任意に先行した整数に評価する表現から成ります。 このシンボルは、実際のオペランド値自体よりむしろオペランド値を見つけることができるメモリアドレスとして供給された整数値を解釈しなければならないのを示します。
When converting each instruction operand to bytecode, the parser first determines whether the instruction expects the operand to be a literal, a reference, a multitype, or an address. If the operand is a literal, then, as per Figure 8 of SigComp, the parser inserts bytecode (usually the shortest) capable of encoding the supplied operand value.
それぞれの指示オペランドをバイトコードに変換するとき、パーサは、最初に、指示が、オペランドが文字通りのa参照、「マルチ-タイプ」、またはアドレスであると予想するかどうか決定します。 オペランドが次に、SigCompの図8に従って文字通りのaであるなら、パーサは供給されたオペランド値をコード化できるバイトコード(通常最も短い)を挿入します。
Since literal operands are used to indicate the total number of operands for an instruction, it is possible to leave a literal operand blank and allow its value to be inferred automatically by the assembler. For example:
文字通りのオペランドが指示のためにオペランドの総数を示すのに使用されるので、文字通りのオペランドを空白の状態でおいて、値がアセンブラによって自動的に推論されるのを許容するのは可能です。 例えば:
MULTILOAD (64, , 1, 2, 3, 4)
MULTILOAD(64, , 1, 2, 3, 4)
The missing operand should be given the value 4 because it is followed by a total of 4 operands.
合計4つのオペランドがそれのあとに続いているので、値4をなくなったオペランドに与えるべきです。
If the operand is a reference, then, as per Figure 9 of SigComp, the parser inserts bytecode (usually the shortest) capable of encoding the supplied memory address. Note that reference operands will always be preceded by the symbol "$" in assembly because they always encode memory addresses rather than actual operand values.
そして、オペランドが参照であるなら、SigCompの図9に従って、パーサは供給されたメモリアドレスをコード化できるバイトコード(通常最も短い)を挿入します。 いつも実際のオペランド値よりむしろメモリアドレスをコード化するので、「$」というシンボルがアセンブリで参照オペランドにいつも先行することに注意してください。
Surtees & West Informational [Page 8] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[8ページ]のRFC4464SigCompユーザのガイド2006年5月
If the operand is a multitype, then the parser first checks whether the symbol "$" is present. If so, then, as per Figure 10 of SigComp, it inserts bytecode (usually the shortest) capable of encoding the supplied integer as a memory address. If not, then, as per Figure 10 of SigComp, it inserts bytecode (usually the shortest) that encodes the supplied integer as an operand value.
オペランドが「マルチ-タイプ」であるなら、パーサは、最初に、「$」というシンボルが存在しているかどうかチェックします。 そうだとすれば、そして、SigCompの図10に従って、それはメモリアドレスとして供給された整数をコード化できるバイトコード(通常最も短い)を挿入します。 そうでなければ、そして、SigCompの図10に従って、それはオペランド値として供給された整数をコード化するバイトコード(通常最も短い)を挿入します。
If the operand is an address, then the parser checks whether the symbol "$" is present. If so, then the supplied integer is encoded as a memory address, just as for the multitype instruction above. If not, then the byte position of the opcode is subtracted from the supplied integer modulo 16, and the result is encoded as an operand value as per Figure 10 of SigComp.
オペランドがアドレスであるなら、パーサは、「$」というシンボルが存在しているかどうかチェックします。 そうだとすれば、そして、供給された整数はまさしく上の「マルチ-タイプ」指示のようにメモリアドレスとしてコード化されます。 そうでなければ、次に、opcodeのバイト位置は供給された整数法16から引き算されます、そして、結果はSigCompの図10に従ってオペランド値としてコード化されます。
The length of the resulting bytecode is dependent on the parser in use. There can be several correct and usable representations of the same instruction.
結果として起こるバイトコードの長さは使用中のパーサに依存しています。 同じ指示のいくつかの正しくて使用可能な表現があることができます。
3.2.3. Directives
3.2.3. 指示
The assembly language provides a number of directives for evaluating expressions, moving instructions to a particular memory address, etc.
アセンブリ言語は表現を評価するための多くの指示、特定のメモリアドレスへの感動的な指示などを提供します。
The directives "pad", "align", and "at" can be used to add padding to the bytecode.
指示「パッド」は「並びます」、そして、加えるのにバイトコードにそっと歩きながら、“at"は使用できます。
The directive "pad (n)" appends n consecutive padding bytes to the bytecode. The actual value of the padding bytes is unimportant, so when the bytecode is uploaded to the UDVM, the padding bytes can be set to the initial values contained in the UDVM memory (this helps to reduce the size of a SigComp message).
指示の「パッド(n)」はバイトコードにn連続した詰め物バイト添えます。 詰め物バイトの実価が重要でないので、バイトコードがUDVMにアップロードされるとき、UDVMメモリに含まれた初期の値に詰め物バイトを設定できます(これは、SigCompメッセージのサイズを減少させるのを助けます)。
The directive "align (n)" appends the minimum number of padding bytes to the bytecode such that the total number of bytes of bytecode generated so far is a multiple of n bytes. If the bytecode is already aligned to a multiple of n bytes, then no padding bytes are added.
「(n)を並べてください」が今までのところ発生しているバイトのバイトコードの総数がnバイトの倍数であるようにバイトコードにバイトを水増ししながら最小の数を追加する指示。 バイトコードが既にnバイトの倍数に並べられるなら、詰め物バイトは全く加えられません。
The directive "at (n)" appends enough padding bytes to the bytecode such that the total number of bytes of bytecode generated so far is exactly n bytes. If more than n bytes have already been generated before the "at" directive is encountered then the assembly code contains an error.
「(n)」の指示がバイトコードに十分な詰め物バイト添えるので、今までのところ発生しているバイトのバイトコードの総数はちょうどnバイトです。 “at"指示が遭遇する前にnバイトが既に発生したなら、アセンブリコードは誤りを含んでいます。
The directives "byte" and "word" can be used to add specific data strings to the bytecode.
特定のデータ列をバイトコードに加えるのに指示「バイト」と「単語」を使用できます。
Surtees & West Informational [Page 9] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[9ページ]のRFC4464SigCompユーザのガイド2006年5月
The directive "byte (n[0],..., n[k-1])" appends k consecutive bytes to the bytecode. The byte string is supplied as expressions that evaluate to give integers n[0],..., n[k-1] from 0 to 255.
指示の「バイト(n[0]、…、n[k-1])」はk連続したバイトをバイトコードに追加します。 それが整数n[0]に与えるために評価する表現としてバイトストリングを供給します…, 0〜255までのn[k-1]。
The directive "word (n[0],..., n[k-1])" appends k consecutive 2-byte words to the bytecode. The word string is supplied as expressions that evaluate to give integers n[0],..., n[k-1] from 0 to 65535.
指示の「単語(n[0]、…、n[k-1])」はk連続した2バイトの単語をバイトコードに追加します。 それが整数n[0]に与えるために評価する表現として単語ストリングを供給します…, 0〜65535までのn[k-1]。
The directive "set (name, n)" assigns an integer value n to a specified text name. The integer value can be supplied in the form of an expression.
指示の「セット(名前、n)」は整数値nを指定された原文名に割り当てます。 表現の形で整数値を供給できます。
The directive "readonly (n)" where n is 0 or 1 can be used to indicate that an area of memory could be changed (0) or will not be changed (1) during the execution of the UDVM. This directive could be used, for example, in conjunction with "!" to ensure that the address of the zero used will still contain zero when the bytecode is executed. If no readonly directive is used, then any address containing zero can be used by "!" (i.e., by default, there is assumed to be a readonly (1) directive at Address 0) and it is up to the author of the assembly code to ensure that the address in question will still contain zero when the bytecode is executed. If the readonly directive is used, then bytes between a readonly (0) and readonly (1) pair are NOT to be used by "!". When a readonly directive has been used, the bytes obey that directive from that address to either another readonly directive or the end of UDVM memory, whichever comes first.
変えられないでください。nが0であるかメモリの領域を変えることができたのを示すのに1を使用できる指示「readonly(n)」(0)か意志、UDVMの実行の間の(1)。 例えば、“!"に関連してバイトコードが実行されるとき、それでも、使用されるゼロもののアドレスがゼロを含むのを保証するのにこの指示を使用できました。 どんなreadonly指示も使用されていないなら、“!"はゼロを含むどんなアドレスも使用できます。 (デフォルトで、すなわち、Address0でreadonly(1)指示があると仮定されます) そして、バイトコードが実行されるとき、それでも、問題のアドレスがゼロを含むのを保証するのは、アセンブリコードの作者次第です。 readonly指示が使用されているなら、“!"によって使用されるように、readonly(0)とreadonly(1)組の間のバイトはありません。 readonly指示が使用されたとき、バイトはそのUDVMメモリの別のreadonly指示かそのアドレスから終わりのどちらかまでの指示に従います、どれが一番になっても。
3.2.4. Labels
3.2.4. ラベル
A label is a special directive used to assign memory addresses to text names.
ラベルはメモリアドレスを原文名に割り当てるのに使用される特別な指示です。
Labels are specified by a single colon followed by the text name to be defined. The (absolute) position of the byte immediately following the label is evaluated and assigned to the text name. For example:
ラベルは原文名があとに続いた、定義された1コロンによって指定されます。 すぐにラベルに続くバイトの(絶対)の位置は、原文名に評価されて、割り当てられます。 例えば:
:start
:始め
LOAD (temp, 1)
負荷(1歳の臨時)
Since the label "start" occurs at the beginning of the bytecode, it is assigned the integer value 0.
ラベル「始め」がバイトコードの始めに起こるので、整数値0はそれに割り当てられます。
Note that writing the label ":name" has exactly the same behavior as writing the directive "set (name, .)".
「」 : 名前をラベルに書いて、それに注意してください。」まさに指示を書くのと同じ振舞いは「設定(名前)にさせられます」。
Surtees & West Informational [Page 10] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[10ページ]のRFC4464SigCompユーザのガイド2006年5月
3.3. Uploading the Bytecode to the UDVM
3.3. アップロードはUDVMへのバイトコードです。
Once the parser has converted a string of assembly into the corresponding bytecode, it must be copied to the UDVM memory beginning at Address 0 and then executed, beginning from the first UDVM instruction in the bytecode.
一度、パーサがアセンブリのストリングを対応するバイトコードに変換したことがあって、それをAddress0で始まるUDVMメモリにコピーされて、次に、実行しなければなりません、バイトコードにおける最初のUDVM指示から始まって。
SigComp provides the following message format for uploading bytecode to the UDVM:
SigCompはUDVMへのアップロードバイトコードに以下のメッセージ・フォーマットを提供します:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 | T | 0 |
+---+---+---+---+---+---+---+---+
| |
: returned feedback item : if T = 1
| |
+---+---+---+---+---+---+---+---+
| code_len |
+---+---+---+---+---+---+---+---+
| code_len | destination |
+---+---+---+---+---+---+---+---+
| |
: uploaded UDVM bytecode :
| |
+---+---+---+---+---+---+---+---+
| |
: remaining SigComp message :
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 | T| 0 | +---+---+---+---+---+---+---+---+ | | : 返されたフィードバック項目: Tが1と等しいなら| | +---+---+---+---+---+---+---+---+ | コード_len| +---+---+---+---+---+---+---+---+ | コード_len| 目的地| +---+---+---+---+---+---+---+---+ | | : アップロードされたUDVMバイトコード: | | +---+---+---+---+---+---+---+---+ | | : SigCompメッセージのままで、残っています: | | +---+---+---+---+---+---+---+---+
The destination field should be set to the memory address of the first UDVM instruction. Note that if this address cannot be represented by the destination field, then the bytecode cannot be uploaded to the UDVM using the standard SigComp header. In particular, the memory address of the first UDVM instruction must always be a multiple of 64 bytes or the standard SigComp header cannot be used. Of course, there may be other ways to upload the bytecode to the UDVM, such as retrieving the bytecode directly via the INPUT-BYTES instruction.
あて先フィールドは最初のUDVM指示のメモリアドレスに設定されるべきです。 あて先フィールドでこのアドレスを表すことができないなら標準のSigCompヘッダーを使用することでバイトコードをUDVMにアップロードできないことに注意してください。 いつも最初のUDVM指示のメモリアドレスは特に、64バイトの倍数であるに違いありませんか標準のSigCompヘッダーを使用できません。 もちろん、バイトコードをUDVMにアップロードする他の方法があるかもしれません、直接INPUT-BYTES指示でバイトコードを検索するのなどように。
Additionally, all memory addresses between Address 0 and Address 31 inclusive are initialized to endpoint-specific values by the UDVM, so they must be specified as padding in the bytecode, or the standard SigComp header cannot be used. Memory addresses from Address 32 to Address (destination - 1) inclusive are initialized to 0, so they must be specified either as padding or as 0s if the bytecode is to be successfully uploaded using the standard SigComp header.
さらに、UDVMはAddress0とAddress31の間で包括的なすべてのメモリアドレスを終点特有の値に初期化できるというわけではありませんか、したがって、バイトコードでそっと歩くとそれらを指定できなくなければなりませんか、標準のSigCompヘッダーは使用できません。 Address(目的地--1)によって包括的なメモリアドレスが0に初期化されるので、バイトコードが標準のSigCompヘッダーを使用することで首尾よくアップロードされることであるなら0を水増しするか、0のように彼らを指定しなければなりません。
Surtees & West Informational [Page 11] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[11ページ]のRFC4464SigCompユーザのガイド2006年5月
The code_len field should be set to the smallest value such that all memory addresses beginning at Address (destination + code_len) are either as initialised by the UDVM (to 0) or as set by the bytecode at runtime.
コード_len分野はUDVM(0への)によって初期化されるようにAddress(_目的地+コードlen)で始まるすべてのメモリアドレスがどちらかかランタイムのときにバイトコードによって設定されるように最も小さい値に設定されるべきです。
The "uploaded UDVM bytecode" should be set to contain the segment of bytecode that lies between Address (destination) and Address (destination + code_len - 1) inclusive.
「アップロードされたUDVMバイトコード」がAddress(目的地)とAddress(_目的地+コードlen--1)の間に包括的にあるバイトコードのセグメントを含むように設定されるべきです。
4. Compression Algorithms
4. 圧縮アルゴリズム
This section describes a number of compression algorithms that can be used by a SigComp compressor. In each case, the document provides UDVM bytecode for the corresponding decompression algorithm, which can be uploaded to the receiving endpoint as part of a SigComp message. Each algorithm (as written in this section) assumes that there is a 16K decompression memory size, there are 16 cycles per bit, and there is an 8K state memory size. Decompression will succeed with a smaller value for state memory size; however, the full state will not be created.
このセクションはSigCompコンプレッサーで使用できる多くの圧縮アルゴリズムを説明します。 その都度、ドキュメントは対応する減圧アルゴリズムにUDVMバイトコードを提供します。(SigCompメッセージの一部として受信終点にそれをアップロードできます)。 各アルゴリズム(このセクションで書かれているように)は、16Kの減圧記憶容量があると仮定します、そして、1ビットあたり16サイクルがあります、そして、8Kの州の記憶容量があります。 減圧は州の記憶容量のために、より小さい値で成功するでしょう。 しかしながら、完全な状態は創設されないでしょう。
Section 4.1.1 covers a simple algorithm in some detail, including the steps required to compress and decompress a SigComp message. The remaining sections cover well-known compression algorithms that can be adapted for use in SigComp with minimal modification.
セクション4.1 .1 SigCompメッセージを圧縮して、減圧するのに必要であるステップを含む何らかの詳細に簡単なアルゴリズムをカバーしています。 残っているセクションはSigCompにおける最小量の変更による使用のために適合させることができる周知の圧縮アルゴリズムをカバーします。
4.1. Well-known Compression Algorithms
4.1. 周知の圧縮アルゴリズム
4.1.1. LZ77
4.1.1. LZ77
This section describes how to implement a very simple compression algorithm based on LZ77 [5].
このセクションはLZ77[5]に基づく非常に簡単な圧縮アルゴリズムを実行する方法を説明します。
A compressed message generated by the simplified LZ77 scheme consists of a sequence of 4-byte characters, where each character contains a 2-byte position value followed by a 2-byte length value. Each pair of integers identifies a byte string in the UDVM memory; when concatenated, these byte strings form the decompressed message.
簡易型のLZ77計画で発生する圧縮されたメッセージは4バイトのキャラクタの系列から成ります。そこでは、各キャラクタが2バイトの長さの値があとに続いた2バイトの位置の値を含みます。 それぞれの組の整数はUDVMメモリでバイトストリングを特定します。 連結されると、これらのバイトストリングは減圧されたメッセージを形成します。
When implementing a bytecode decompressor for the simplified LZ77 scheme, the UDVM memory is partitioned into five distinct areas, as shown below:
簡易型のLZ77計画のためにバイトコード減圧装置を実行するとき、UDVMメモリは5つの異なった領域に仕切られます、以下に示すように:
0 64 128 256 512
| scratch-pad | variables | bytecode | dictionary | circular buffer |
+-------------+-----------+----------+------------+-----------------+
<-----------> <---------> <--------> <----------> <--------------->
64 bytes 64 bytes 128 bytes 256 bytes 512+ bytes
0 64 128 256 512 | スクラッチ・パッド| 変数| バイトコード| 辞書| 円形のバッファ| +-------------+-----------+----------+------------+-----------------+ <。-----------><。---------><。--------><。----------><。--------------->64バイト64バイト128バイト256バイト512+バイト
Surtees & West Informational [Page 12] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[12ページ]のRFC4464SigCompユーザのガイド2006年5月
The first 128 bytes are used to hold the 2-byte variables needed by the LZ77 decompressor. Within this memory, the first 64 bytes are used as a scratch-pad, holding the 2-byte variables that can be discarded between SigComp messages. In contrast, the next 64 bytes (and in fact all of the UDVM memory starting from Address 64) should be saved after decompressing a SigComp message to improve the compression ratio of subsequent messages.
最初の128バイトは、LZ77減圧装置によって必要とされた2バイトの変数を保持するのに使用されます。 このメモリの中では、最初の64バイトはスクラッチ・パッドとして使用されます、SigCompメッセージの間で捨てることができる2バイトの変数を保持して。 対照的に、その後のメッセージの圧縮比を改良するSigCompメッセージを減圧した後に、次の64バイト(そして、事実上、Address64から始めるUDVMメモリのすべて)は節約されるべきです。
The bytecode for the LZ77 decompressor is stored beginning at Address 128. A total of 128 bytes are reserved for the bytecode although the LZ77 decompressor requires less; this allows room for adding additional features to the decompressor at a later stage.
LZ77減圧装置のためのバイトコードは、Address128で始まりながら、格納されます。 LZ77減圧装置は以下を必要としますが、合計128バイトはバイトコードのために予約されます。 これは後期段階に減圧装置に付加的な機能を加える余地を許容します。
The next 256 bytes are initialized by the bytecode to contain the integers 0 to 255 inclusive. The purpose of this memory area is to provide a dictionary of all possible uncompressed characters; this is important to ensure that the compressor can always generate a sequence of position/length pairs that encode a given message. For example, a byte with value 0x41 (corresponding to the ASCII character "A") can be found at Address 0x0141 of the UDVM memory, so the compressed character 0x0141 0001 will decompress to give this ASCII character. Note that encoding each byte in the application message as a separate 4-byte compressed character is not recommended, however, as the resulting "compressed" message is four times as large as the original uncompressed message.
次の256バイトはバイトコードによって初期化されて、0〜255に包括的に整数を含みます。 このメモリ領域の目的はすべての可能な解凍されたキャラクタの辞書を提供することです。 これは、コンプレッサーが与えられたメッセージをコード化する位置/長さの組の系列をいつも発生させることができるのを保証するために重要です。 例えば、UDVMメモリのアドレス0x0141で値0x41(ASCII文字「A」にとって、対応する)に従った1バイトを見つけることができるので、圧縮されたキャラクタ0x0141 0001はこのASCII文字に与えるために減圧されるでしょう。 しかしながら、結果として起こる「圧縮された」メッセージがオリジナルがメッセージを解凍したより4倍大きいように別々の4バイトの圧縮されたキャラクタが推薦されないようにアプリケーションメッセージの各バイトをコード化して、それに注意してください。
The compression ratio of LZ77 is improved by the remaining UDVM memory, which is used to store a history buffer containing the previously decompressed messages. Compressed characters can point to strings that have previously been decompressed and stored in the buffer, so the overall compression ratio of the LZ77 algorithm improves as the decompressor "learns" more text strings and is able to encode longer strings using a single compressed character. The buffer is circular, so older messages are overwritten by new data when the buffer becomes full.
LZ77の圧縮比は残っているUDVMメモリによって改良されます。(それは、以前に減圧されたメッセージを含む歴史バッファを格納するのに使用されます)。 圧縮されたキャラクタが以前にバッファに減圧されて、格納されたストリングを示すことができるので、LZ77アルゴリズムの総合的な圧縮比は、減圧装置が、より多くのテキスト文字列を「学ぶ」とき向上して、単独の圧縮されたキャラクタを使用するのにおいて、より長いストリングをコード化できます。 バッファが円形であるので、バッファが完全になるとき、より古いメッセージは新しいデータによって上書きされます。
The steps required to implement an LZ77 compressor and decompressor are similar, although compression is more processor-intensive as it requires a searching operation to be performed. Assembly for the simplified LZ77 decompressor is given below:
LZ77コンプレッサーと減圧装置を実行するのに必要であるステップは同様です、実行されるのが探す操作を必要とするとき、圧縮が、よりプロセッサ徹底的ですが。 簡易型のLZ77減圧装置のための議会を以下に与えます:
; Variables that do not need to be stored after decompressing each ; SigComp message are stored here:
; それぞれを減圧した後に格納される必要はない変数。 SigCompメッセージはここに格納されます:
at (32)
at(32)
:position_value pad (2) :length_value pad (2)
:位置_値のパッド(2): 長さ_値のパッド(2)
Surtees & West Informational [Page 13] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[13ページ]のRFC4464SigCompユーザのガイド2006年5月
at (42)
at(42)
set (requested_feedback_location, 0)
セットします。(要求された_フィードバック_位置、0)
; The UDVM registers must be stored beginning at Address 64:
; Address64で始まりながら、UDVMレジスタを格納しなければなりません:
at (64)
at(64)
; Variables that should be stored after decompressing a message are ; stored here. These variables will form part of the SigComp state ; item created by the bytecode:
; メッセージを減圧した後に格納されるべきである変数はそうです。 ここに格納されます。 これらの変数はSigComp状態の一部を形成するでしょう。 項目はバイトコードで作成しました:
:byte_copy_left pad (2) :byte_copy_right pad (2) :decompressed_pointer pad (2)
:バイト_コピー_はパッド(2): バイト_コピー_を右のパッド(2)に残しました: _ポインタパッドを減圧します。(2)
set (returned_parameters_location, 0)
セットします。(返された_パラメタ_位置、0)
align (64)
並んでください。(64)
:initialize_memory
:_メモリを初期化してください。
set (udvm_memory_size, 8192) set (state_length, (udvm_memory_size - 64))
セット(udvm_メモリ_サイズ、8192)セット(_長さを述べてください、(udvm_メモリ_サイズ--64))
; The UDVM registers byte_copy_left and byte_copy_right are set to ; indicate the bounds of the circular buffer in the UDVM memory. A ; variable decompressed_pointer is also created and set pointing to ; the start of the circular buffer:
; あと_コピー_とバイト_が_まさしくコピーするUDVMレジスタバイトは設定されます。 UDVMメモリの円形のバッファの領域を示してください。 A。 可変減圧された_ポインタは、また、作成されて、指すのにそうするように設定しました。 円形のバッファの始まり:
MULTILOAD (64, 3, circular_buffer, udvm_memory_size, circular_buffer)
MULTILOAD(64、3、円形の_バッファ、udvm_メモリ_サイズ、円形の_バッファ)
; The "dictionary" area of the UDVM memory is initialized to contain ; the values 0 to 255 inclusive:
; UDVMメモリの「辞書」領域が含むように初期化される、。 値、0 255に包括的:
MEMSET (static_dictionary, 256, 0, 1)
MEMSET(静的な_辞書、256、0、1)
:decompress_sigcomp_message
:_sigcomp_メッセージを減圧してください。
:next_character
:次の_キャラクタ
; The next character in the compressed message is read by the UDVM ; and the position and length integers are stored in the variables ; position_value and length_value, respectively. If no more ; compressed data is available, the decompressor jumps to the ; "end_of_message" subroutine:
; 圧縮されたメッセージの次のキャラクタはUDVMによって読まれます。 そして、位置と長さの整数は変数に格納されます。 値と長さの_がそれぞれ評価する_を置いてください。 もうなら。 圧縮されたデータが利用可能である、減圧装置がとび移る、。 「_メッセージの終わりの_」サブルーチン:
INPUT-BYTES (4, position_value, end_of_message)
入力バイト(4、位置の_価値、_メッセージの終わりの_)
Surtees & West Informational [Page 14] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[14ページ]のRFC4464SigCompユーザのガイド2006年5月
; The position_value and length_value point to a byte string in the ; UDVM memory, which is copied into the circular buffer at the ; position specified by decompressed_pointer. This allows the string ; to be referenced by later characters in the compressed message:
; 位置の_価値と長さの_価値がバイトストリングに指す、。 UDVMメモリ、;(それは、回覧によりもみ皮製でコピーされます)。 位置は減圧された_ポインタで指定しました。 これはストリングを許容します。 圧縮されたメッセージの後のキャラクタによって参照をつけられるように:
COPY-LITERAL ($position_value, $length_value, $decompressed_pointer)
コピー文字通りです。(値、$長さ_値、$が_ポインタを減圧したという$位置の_)
; The byte string is also outputted onto the end of the decompressed ; message:
; また、バイトストリングは減圧の終わりにoutputtedされます。 メッセージ:
OUTPUT ($position_value, $length_value)
出力($位置の_価値、$長さの_価値)
; The decompressor jumps back to consider the next character in the ; compressed message:
; 次のキャラクタを考えるためには逆減圧装置ジャンプ、。 メッセージを圧縮します:
JUMP (next_character)
ジャンプ(次の_キャラクタ)
:end_of_message
:_メッセージの終わりの_
; The decompressor saves the UDVM memory and halts:
; 減圧装置は、UDVMメモリを保存して、停止します:
END-MESSAGE (requested_feedback_location, returned_parameters_location, state_length, 64, decompress_sigcomp_message, 6, 0)
終わりメッセージ(要求された_フィードバック_位置、返された_パラメタ_位置が、_長さ、64が_sigcomp_メッセージ、6を減圧すると述べる、0)
at (256)
at(256)
; Memory for the dictionary and the circular buffer are reserved by ; the following statements:
; バッファが予約される辞書と回覧のためのメモリ。 以下の声明:
:static_dictionary pad (256) :circular_buffer
:静的な_辞書パッド(256): 回覧_バッファ
The task of an LZ77 compressor is simply to discover a sequence of 4-byte compressed characters that the above bytecode will decompress to give the desired application message. As an example, a message compressed using the simplified LZ77 algorithm is given below:
LZ77コンプレッサーに関するタスクは上のバイトコードが減圧する4バイトの圧縮されたキャラクタの系列が必要なアプリケーションメッセージを与えると単に発見することです。 例として、簡易型のLZ77アルゴリズムを使用することで圧縮されたメッセージを以下に与えます:
0x0154 0001 0168 0001 0165 0001 0120 0001 0152 0001 0165 0001 0173 0x0002 0161 0001 0175 0001 0172 0001 0161 0001 016e 0001 0174 0001 0x0120 0001 0161 0001 020d 0002 0174 0001 0201 0003 0145 0001 016e 0x0001 0164 0001 0120 0001 016f 0001 0166 0001 0211 0005 0155 0001 0x016e 0001 0169 0001 0176 0001 0165 0001 0172 0002 0165 0001 010a 0x0001
0×0154 0001 0168 0001 0165 0001 0120 0001 0152 0001 0165 0001 0173 0×0002 0161 0001 0175 0001 0172 0001 0161 0001 016e0001 0174 0001 0×0120 0001 0161 0001 020d0002 0174 0001 0201 0003 0145 0001 016e0×0001 0164 0001 0120 0001 016f0001 0166 0001 0211 0005 0155 0001 0x016e0001 0169 0001 0176 0001 0165 0001 0172 0002 0165 0001 010a0x0001
The uncompressed message is "The Restaurant at the End of the Universe\n".
解凍されたメッセージは「宇宙\nの終わりのレストラン」です。
Surtees & West Informational [Page 15] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[15ページ]のRFC4464SigCompユーザのガイド2006年5月
The bytecode for the LZ77 decompressor can be uploaded as part of the compressed message, as specified in Section 3.3. However, in order to improve the overall compression ratio, it is important to avoid uploading bytecode in every compressed message. For this reason, SigComp allows the UDVM to save an area of its memory as a state item between compressed messages. Once a state item has been created, it can be retrieved by sending the corresponding state identifier using the following SigComp message format:
圧縮されたメッセージの一部、指定にされるとしてセクション3.3でLZ77減圧装置のためのバイトコードをアップロードできます。 しかしながら、総合的な圧縮比を改良するために、あらゆる圧縮されたメッセージのアップロードバイトコードを避けるのは重要です。 この理由で、SigCompはUDVMに圧縮されたメッセージの間の州の項目としてメモリの領域を救わせます。 州の項目がいったん作成されると、以下のSigCompメッセージ・フォーマットを使用することで対応する州の識別子を送ることによって、それを検索できます:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 | T | 1 |
+---+---+---+---+---+---+---+---+
| |
: returned feedback item : if T = 1
| |
+---+---+---+---+---+---+---+---+
| |
: partial state identifier :
| |
+---+---+---+---+---+---+---+---+
| |
: remaining SigComp message :
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 | T| 1 | +---+---+---+---+---+---+---+---+ | | : 返されたフィードバック項目: Tが1と等しいなら| | +---+---+---+---+---+---+---+---+ | | : 部分的な州の識別子: | | +---+---+---+---+---+---+---+---+ | | : SigCompメッセージのままで、残っています: | | +---+---+---+---+---+---+---+---+
The partial_state_identifier field must contain the first 6 bytes of the state identifier for the state item to be accessed (see [2] for details of how state identifiers are derived).
部分的な_状態_識別子分野は、州の項目がアクセスされるために州の識別子の最初の6バイトを含まなければなりません(州の識別子がどう引き出されるかに関する詳細のための[2]を見てください)。
Note that the partial_state_identifier field could be 9 or 12 bytes and that in these cases, bits 6 and 7 of the first byte of the message would be 10 or 11, respectively.
6とメッセージの最初の7バイトのビットがこれらの場合では、それぞれ部分的な_状態_識別子分野が9バイトか12バイトであるかもしれなく、10か11であることに注意してください。
4.1.2. LZSS
4.1.2. LZSS
This section provides UDVM bytecode for the simple but effective LZSS compression algorithm [6].
このセクションは簡単な、しかし、効果的なLZSS圧縮アルゴリズム[6]にUDVMバイトコードを提供します。
The principal improvement offered by LZSS over LZ77 is that each compressed character begins with a 1-bit indicator flag to specify whether the character is a literal or an offset/length pair. A literal value is simply a single uncompressed byte that is appended directly to the decompressed message.
LZSSによってLZ77の上に提供された主要な改良は圧縮されたキャラクタが文字通りの長さであるかオフセット/長さであることにかかわらず1ビットのインディケータ旗で指定し始めるそれぞれに対にされるということです。 文字通りの値は単に直接減圧されたメッセージに追加される解凍された1バイトです。
An offset/length pair contains a 12-bit offset value from 1 to 4096 inclusive, followed by a 4-bit length value from 3 to 18 inclusive. Taken together, these values specify one of the previously received
オフセット/長さの組は包括的に12ビットのオフセット1〜4096年までの値を含んでいます、3〜18までの4ビットの長さの値が包括的にあとに続いていて。 一緒に取って、これらの値は以前に受け取られていることの1つを指定します。
Surtees & West Informational [Page 16] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[16ページ]のRFC4464SigCompユーザのガイド2006年5月
text strings in the circular buffer, which is then appended to the end of the decompressed message.
円形のバッファのテキスト文字列。(次に、それは、減圧されたメッセージの終わりまで追加されます)。
Assembly for an LZSS decompressor is given below:
LZSS減圧装置のための議会を以下に与えます:
at (32) readonly (0)
(32) readonlyで(0)
:index pad (2) :length_value pad (2) :old_pointer pad (2)
:インデックスパッド(2): 長さ_値のパッド(2): 古い_ポインタパッド(2)
at (42)
at(42)
set (requested_feedback_location, 0)
セットします。(要求された_フィードバック_位置、0)
at (64)
at(64)
:byte_copy_left pad (2) :byte_copy_right pad (2) :input_bit_order pad (2) :decompressed_pointer pad (2)
:バイト_コピー_はパッド(2): バイト_コピー_を右のパッド(2)に残しました: 入力_は_オーダーパッド(2)に噛み付きました: _ポインタパッドを減圧します。(2)
set (returned_parameters_location, 0)
セットします。(返された_パラメタ_位置、0)
align (64) readonly (1)
(64) readonlyに並んでください。(1)
:initialize_memory
:_メモリを初期化してください。
set (udvm_memory_size, 8192) set (state_length, (udvm_memory_size - 64))
セット(udvm_メモリ_サイズ、8192)セット(_長さを述べてください、(udvm_メモリ_サイズ--64))
MULTILOAD (64, 4, circular_buffer, udvm_memory_size, 0, circular_buffer)
MULTILOAD(64、4、円形の_バッファ、udvm_メモリ_サイズ、0、円形の_バッファ)
:decompress_sigcomp_message
:_sigcomp_メッセージを減圧してください。
:next_character
:次の_キャラクタ
INPUT-HUFFMAN (index, end_of_message, 2, 9, 0, 255, 16384, 4, 4096, 8191, 1) COMPARE ($index, 8192, length, end_of_message, literal)
INPUT-ハフマン、(索引をつけてください、そして、_メッセージの_、2、9、0、255、16384、4、4096、8191、1)COMPAREを終わらせてください。($インデックス、8192、長さはメッセージで、文字通りで_の_を終わらせます)
:literal
:文字通り
set (index_lsb, (index + 1))
セットします。(インデックス_lsb、(インデックス+1))
Surtees & West Informational [Page 17] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[17ページ]のRFC4464SigCompユーザのガイド2006年5月
OUTPUT (index_lsb, 1) COPY-LITERAL (index_lsb, 1, $decompressed_pointer) JUMP (next_character)
コピー文字通り(インデックス_lsb、1、$は_ポインタを減圧した)のジャンプを出力してください(インデックス_lsb、1)。(次の_キャラクタ)
:length
:長さ
INPUT-BITS (4, length_value, !) ADD ($length_value, 3) LOAD (old_pointer, $decompressed_pointer) COPY-OFFSET ($index, $length_value, $decompressed_pointer) OUTPUT ($old_pointer, $length_value) JUMP (next_character)
INPUT-BITS(4、長さの_価値!) ($長さ_値、3)がコピーオフセット($インデックス、$長さ_値、$は_ポインタを減圧した)出力($の古い_ポインタ、$長さの_価値)ジャンプをロードする(古い_ポインタ、$は_ポインタを減圧した)と言い足してください。(次の_キャラクタ)
:end_of_message
:_メッセージの終わりの_
END-MESSAGE (requested_feedback_location, returned_parameters_location, state_length, 64, decompress_sigcomp_message, 6, 0)
終わりメッセージ(要求された_フィードバック_位置、返された_パラメタ_位置が、_長さ、64が_sigcomp_メッセージ、6を減圧すると述べる、0)
readonly (0) :circular_buffer
readonly(0): 回覧_バッファ
An example of a message compressed using the LZSS algorithm is given below:
LZSSアルゴリズムを使用することで圧縮されたメッセージに関する例は以下に出されます:
0x279a 0406 e378 b200 6074 1018 4ce6 1349 b842
0x279a0406e378 b200 6074 1018 4ce6 1349b842
The uncompressed message is "Oh no, not again!".
解凍されたメッセージは「再びないいやだ!」ということです。
4.1.3. LZW
4.1.3. LZW
This section provides UDVM bytecode for the well-known LZW compression algorithm LZW [7]. This algorithm is used in a number of standards including the GIF image format.
このセクションは周知のLZW圧縮アルゴリズムLZW[7]にUDVMバイトコードを提供します。 このアルゴリズムはGIF画像形式を含む多くの規格に使用されます。
LZW compression operates in a similar manner to LZ77 in that it maintains a circular buffer of previously received decompressed data, and each compressed character references exactly one byte string from the circular buffer. However, LZW also maintains a "codebook" containing 1024 position/length pairs that point to byte strings that LZW believes are most likely to occur in the uncompressed data.
以前にの円形のバッファが円形のバッファから減圧されたデータ、およびそれぞれのちょうど人物証明書の1バイトの圧縮されたストリングを受け取ったと主張するので、LZW圧縮は同じようにLZ77に作動します。 しかしながら、また、解凍されたデータに最も起こりそうなLZWが、信じているバイトストリングを示す1024位置/長さの組を含んでいて、LZWは「符号表」を維持します。
The byte strings stored in the LZW codebook can be referenced by sending a single 10-bit value from 0 to 1023 inclusive. The UDVM extracts the corresponding text string from the codebook and appends it to the end of the decompressed message. It then creates a new codebook entry containing the current text string and the next character to occur in the decompressed message.
0〜1023年まで包括的にただ一つの10ビットの値を送ることによって、ストリングがLZW符号表に格納したバイトに参照をつけることができます。 UDVMは符号表から対応するテキスト文字列を抽出して、減圧されたメッセージの終わりに追加します。 そして、それは、減圧されたメッセージに起こるように現在のテキスト文字列と次のキャラクタを含む新しい符号表エントリーを作成します。
Surtees & West Informational [Page 18] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[18ページ]のRFC4464SigCompユーザのガイド2006年5月
Assembly for an LZW decompressor is given below:
LZW減圧装置のための議会を以下に与えます:
at (32)
at(32)
:length_value pad (2) :position_value pad (2) :index pad (2)
:長さ_値のパッド(2): 位置_値のパッド(2):indexパッド(2)
at (42)
at(42)
set (requested_feedback_location, 0)
セットします。(要求された_フィードバック_位置、0)
at (64)
at(64)
:byte_copy_left pad (2) :byte_copy_right pad (2) :input_bit_order pad (2)
:バイト_コピー_左のパッド(2): バイト_コピー_権利パッド(2): 入力_ビット_オーダーパッド(2)
:codebook_next pad (2) :current_length pad (2) :decompressed_pointer pad (2)
:次の符号表_パッド(2): 現在の_長さのパッド(2): 減圧された_ポインタパッド(2)
set (returned_parameters_location, 0)
セットします。(返された_パラメタ_位置、0)
align (64)
並んでください。(64)
:initialize_memory
:_メモリを初期化してください。
set (udvm_memory_size, 8192) set (state_length, (udvm_memory_size - 64))
セット(udvm_メモリ_サイズ、8192)セット(_長さを述べてください、(udvm_メモリ_サイズ--64))
MULTILOAD (64, 6, circular_buffer, udvm_memory_size, 0, codebook, 1, static_dictionary)
MULTILOAD(64、6、円形の_バッファ、udvm_メモリ_サイズ、0、符号表、1、静的な_辞書)
:initialize_codebook
:_符号表を初期化してください。
; The following instructions are used to initialize the first 256 ; entries in the LZW codebook with single ASCII characters:
; 以下の指示は最初の256を初期化するのに使用されます。 単独のASCII文字がいるLZW符号表におけるエントリー:
set (index_lsb, (index + 1)) set (current_length_lsb, (current_length + 1))
セット(インデックス_lsb、(インデックス+1))セット(_現在の_の長さのlsb、(現在の_長さ+1))
COPY-LITERAL (current_length_lsb, 3, $codebook_next) COPY-LITERAL (index_lsb, 1, $decompressed_pointer) ADD ($index, 1) COMPARE ($index, 256, initialize_codebook, next_character, 0)
コピー文字通り、(_現在の_の長さのlsb、3、次のコピー文字通り(インデックス_lsb、1、$は_ポインタを減圧した)の$符号表_は($インデックス、1)が比較されると言い足します。($インデックス、256は_符号表、次の0歳の_キャラクタを初期化します)
:decompress_sigcomp_message
:_sigcomp_メッセージを減圧してください。
Surtees & West Informational [Page 19] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[19ページ]のRFC4464SigCompユーザのガイド2006年5月
:next_character
:次の_キャラクタ
; The following INPUT-BITS instruction extracts 10 bits from the ; compressed message:
; 以下のINPUT-BITS指示が10ビットを抽出する、。 メッセージを圧縮します:
INPUT-BITS (10, index, end_of_message)
入力ビット(10、インデックス、_メッセージの終わりの_)
; The following instructions interpret the received bits as an index ; into the LZW codebook and extract the corresponding ; position/length pair:
; 以下の指示はインデックスとして容認されたビットを解釈します。 LZW符号表と抽出の中との対応。 位置/長さの組:
set (length_value_lsb, (length_value + 1))
セットします。(_長さ_値のlsb、(長さ_値+1))
MULTIPLY ($index, 3) ADD ($index, codebook) COPY ($index, 3, length_value_lsb)
MULTIPLY($インデックス、3)ADD($インデックス、符号表)COPY($インデックス、3、長さの_は_lsbを評価します)
; The following instructions append the selected text string to the ; circular buffer and create a new codebook entry pointing to this ; text string:
; 以下の指示が選択されたテキスト文字列を追加する、。 回覧は、これを示す新しい符号表エントリーを、バッファリングして、作成します。 テキスト文字列:
LOAD (current_length, 1) ADD ($current_length, $length_value) COPY-LITERAL (current_length_lsb, 3, $codebook_next) COPY-LITERAL ($position_value, $length_value, $decompressed_pointer)
負荷(現在の_の長さ、1)がコピー文字通りで(_現在の_の長さのlsb、3、$符号表_次)加える、($の現在の_の長さ、$長さの_価値)コピー文字通り(値、$長さ_値、$が_ポインタを減圧したという$位置の_)
; The following instruction outputs the text string specified by the ; position/length pair:
; テキスト文字列が指定した以下の指示出力、。 位置/長さの組:
OUTPUT ($position_value, $length_value) JUMP (next_character)
出力($位置の_価値、$長さの_価値)ジャンプ(次の_キャラクタ)
:end_of_message
:_メッセージの終わりの_
END-MESSAGE (requested_feedback_location, returned_parameters_location, state_length, 64, decompress_sigcomp_message, 6, 0)
終わりメッセージ(要求された_フィードバック_位置、返された_パラメタ_位置が、_長さ、64が_sigcomp_メッセージ、6を減圧すると述べる、0)
:static_dictionary pad (256) :circular_buffer
:静的な_辞書パッド(256): 回覧_バッファ
at (4492)
at(4492)
:codebook
:符号表
Surtees & West Informational [Page 20] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[20ページ]のRFC4464SigCompユーザのガイド2006年5月
An example of a message compressed using the LZW algorithm is given below:
LZWアルゴリズムを使用することで圧縮されたメッセージに関する例は以下に出されます:
0x14c6 f080 6c1b c6e1 9c20 1846 e190 201d 0684 206b 1cc2 0198 6f1c 0x9071 b06c 42c6 8195 111a 4731 a021 02bf f0
0x14c6 f080 6c1b c6e1 9c20 1846 e190 201d0684 206b 1cc2 0198 6f1c0x9071b06c 42c6 8195 111a4731a021 02bf f0
The uncompressed message is "So long and thanks for all the fish!\n".
したがって、切望してください、そして、すべての魚をありがとうございます。解凍されたメッセージがそうである、「\n」。
4.1.4. DEFLATE
4.1.4. 空気を抜いてください。
This section provides UDVM bytecode for the DEFLATE compression algorithm. DEFLATE is the algorithm used in the well-known "gzip" file format.
このセクションはDEFLATE圧縮アルゴリズムにUDVMバイトコードを提供します。 DEFLATEは周知の"gzip"ファイル形式に使用されるアルゴリズムです。
The following bytecode will decompress the DEFLATE compressed data format [8] with the following modifications:
以下のバイトコードは減圧されるでしょう。DEFLATEは以下の変更でデータの形式[8]を圧縮しました:
1. The DEFLATE compressed data format separates blocks of compressed
data by transmitting 7 consecutive zero bits. Each SigComp
message is assumed to contain a separate block of compressed
data, so the end-of-block bits are implicit and do not need to be
transmitted at the end of a SigComp message.
1. DEFLATEは、7個の連続したゼロ・ビット伝わることによって、データの形式セパレーツブロックの圧縮されたデータを圧縮しました。 それぞれのSigCompメッセージが圧縮されたデータの別々のブロックを含むと思われて、ブロックの端のビットは暗黙であり、SigCompメッセージの終わりで伝えられる必要はありません。
2. This bytecode supports only DEFLATE block type 01 (data
compressed with fixed Huffman codes).
2. このバイトコードはDEFLATEゴシック体01だけ(固定ハフマン符号で圧縮されたデータ)を支持します。
Assembly for the DEFLATE decompressor is given below:
DEFLATE減圧装置のための議会を以下に与えます:
at (32) readonly (0)
(32) readonlyで(0)
:index pad (2) :extra_length_bits pad (2) :length_value pad (2) :extra_distance_bits pad (2) :distance_value pad (2)
:インデックスパッド(2): 余分な_長さ_ビットは(2)を水増しします: 長さ_値のパッド(2): 余分な_距離_ビットは(2)を水増しします: _値のパッドを遠ざけてください。(2)
at (42)
at(42)
set (requested_feedback_location, 0)
セットします。(要求された_フィードバック_位置、0)
at (64)
at(64)
:byte_copy_left pad (2) :byte_copy_right pad (2) :input_bit_order pad (2) :decompressed_pointer pad (2)
:バイト_コピー_はパッド(2): バイト_コピー_を右のパッド(2)に残しました: 入力_は_オーダーパッド(2)に噛み付きました: _ポインタパッドを減圧します。(2)
Surtees & West Informational [Page 21] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[21ページ]のRFC4464SigCompユーザのガイド2006年5月
:length_table pad (116) :distance_table pad (120)
:長さ_テーブルパッド(116): 距離_テーブルパッド(120)
set (returned_parameters_location, 0)
セットします。(返された_パラメタ_位置、0)
align (64)
並んでください。(64)
readonly (1) :initialize_memory
readonly(1): _メモリを初期化してください。
set (udvm_memory_size, 8192) set (state_length, (udvm_memory_size - 64)) set (length_table_start, (((length_table - 4) + 65536) / 4)) set (length_table_mid, (length_table_start + 24)) set (distance_table_start, (distance_table / 4))
セット(udvm_メモリ_サイズ、8192)セット(状態_長さ、(udvm_メモリ_サイズ--64)セット(+ _テーブル_始め、(長さ_テーブル--4)65536)/4の長さ))セット(長さの_は中間であることで_をテーブルの上に置きます、(長さ_テーブル_始め+24))セット(距離_テーブル_始め、(距離_テーブル/4))
MULTILOAD (64, 122, circular_buffer, udvm_memory_size, 5, circular_buffer,
MULTILOAD、(64、122(回覧_バッファ)は_メモリ_サイズ、5、円形の_バッファをudvmします。
0, 3, 0, 4, 0, 5, 0, 6, 0, 7, 0, 8, 0, 9, 0, 10, 1, 11, 1, 13, 1, 15, 1, 17, 2, 19, 2, 23, 2, 27, 2, 31, 3, 35, 3, 43, 3, 51, 3, 59, 4, 67, 4, 83, 4, 99, 4, 115, 5, 131, 5, 163, 5, 195, 5, 227, 0, 258,
0, 3, 0, 4, 0, 5, 0, 6, 0, 7, 0, 8, 0, 9, 0, 10, 1, 11, 1, 13, 1, 15, 1, 17, 2, 19, 2, 23, 2, 27, 2, 31, 3, 35, 3, 43, 3, 51, 3, 59, 4, 67, 4, 83, 4, 99, 4, 115, 5, 131, 5, 163, 5, 195, 5, 227, 0, 258,
0, 1, 0, 2, 0, 3, 0, 4, 1, 5, 1, 7, 2, 9, 2, 13, 3, 17, 3, 25, 4, 33, 4, 49, 5, 65, 5, 97, 6, 129, 6, 193, 7, 257, 7, 385, 8, 513, 8, 769, 9, 1025, 9, 1537, 10, 2049, 10, 3073, 11, 4097, 11, 6145, 12, 8193, 12, 12289, 13, 16385, 13, 24577)
0, 1, 0, 2, 0, 3, 0, 4, 1, 5, 1, 7, 2, 9, 2, 13, 3, 17, 3, 25, 4, 33, 4, 49, 5, 65, 5, 97, 6, 129, 6, 193, 7, 257, 7, 385, 8, 513, 8, 769, 9, 1025, 9, 1537, 10, 2049, 10, 3073, 11, 4097, 11, 6145, 12, 8193, 12, 12289, 13, 16385, 13, 24577)
:decompress_sigcomp_message
:_sigcomp_メッセージを減圧してください。
INPUT-BITS (3, extra_length_bits, !)
入力ビット(3、余分な_長さ_ビット!)
:next_character
:次の_キャラクタ
Surtees & West Informational [Page 22] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[22ページ]のRFC4464SigCompユーザのガイド2006年5月
INPUT-HUFFMAN (index, end_of_message, 4,
7, 0, 23, length_table_start,
1, 48, 191, 0,
0, 192, 199, length_table_mid,
1, 400, 511, 144)
COMPARE ($index, length_table_start, literal, end_of_message,
length_distance)
INPUT-ハフマン、(インデックス、_メッセージの終わりの_、4、7、0、23、長さ_テーブル_始め、1、48、191、0、0、192、199、長さの_が中間であることで_をテーブルの上に置く、1、400、511、144)COMPARE($インデックス、長さ_テーブル_始め、_メッセージ、長さの_距離の文字通りの終わりの_)
:literal
:文字通り
set (index_lsb, (index + 1))
セットします。(インデックス_lsb、(インデックス+1))
OUTPUT (index_lsb, 1) COPY-LITERAL (index_lsb, 1, $decompressed_pointer) JUMP (next_character)
コピー文字通り(インデックス_lsb、1、$は_ポインタを減圧した)のジャンプを出力してください(インデックス_lsb、1)。(次の_キャラクタ)
:length_distance
:長さ_距離
; this is the length part
; これは長さの部分です。
MULTIPLY ($index, 4) COPY ($index, 4, extra_length_bits) INPUT-BITS ($extra_length_bits, extra_length_bits, !) ADD ($length_value, $extra_length_bits)
MULTIPLY($インデックス、4)COPY($インデックス、4、余分な_長さ_ビット)INPUT-BITS($余分な_長さの_ビット、余分な_長さの_ビット!) 加えてください。($長さの_価値、$余分な_長さ_ビット)
; this is the distance part
; これは距離部分です。
INPUT-HUFFMAN (index, !, 1, 5, 0, 31, distance_table_start) MULTIPLY ($index, 4) COPY ($index, 4, extra_distance_bits)
INPUT-ハフマン、(索引をつけてください、1、5、0、31は_テーブル_始め) MULTIPLY($インデックス、4)COPYを遠ざけます。($インデックス、4、余分な_距離_ビット)
INPUT-BITS ($extra_distance_bits, extra_distance_bits, !) ADD ($distance_value, $extra_distance_bits) LOAD (index, $decompressed_pointer) COPY-OFFSET ($distance_value, $length_value, $decompressed_pointer) OUTPUT ($index, $length_value) JUMP (next_character)
INPUT-BITS($余分な_距離_ビット、余分な_距離_ビット!) 負荷(インデックス、$は_ポインタを減圧した)コピーオフセット($距離_価値、$長さの_価値、$は_ポインタを減圧した)出力($インデックス、$長さ_値)ジャンプを加えてください($距離_価値、$の余分な_は_ビットを遠ざけます)。(次の_キャラクタ)
:end_of_message
:_メッセージの終わりの_
END-MESSAGE (requested_feedback_location, returned_parameters_location, state_length, 64, decompress_sigcomp_message, 6, 0)
終わりメッセージ(要求された_フィードバック_位置、返された_パラメタ_位置が、_長さ、64が_sigcomp_メッセージ、6を減圧すると述べる、0)
readonly (0) :circular_buffer
readonly(0): 回覧_バッファ
Surtees & West Informational [Page 23] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[23ページ]のRFC4464SigCompユーザのガイド2006年5月
An example of a message compressed using the DEFLATE algorithm is given below:
DEFLATEアルゴリズムを使用することで圧縮されたメッセージに関する例は以下に出されます:
0xf3c9 4c4b d551 28c9 4855 08cd cb2c 4b2d 2a4e 5548 cc4b 5170 0532 0x2b4b 3232 f3d2 b900
0xf3c9 4c4b d551 28c9 4855 08cd cb2c 4b2d 2a4e5548cc4b5170 0532 0x2b4b3232f3d2 b900
The uncompressed message is "Life, the Universe and Everything\n".
解凍されたメッセージがそうである、「人生、宇宙、およびすべて、\n」。
4.1.5. LZJH
4.1.5. LZJH
This section provides UDVM bytecode for the LZJH compression algorithm. LZJH is the algorithm adopted by the International Telecommunication Union (ITU-T) Recommendation V.44 [9].
このセクションはLZJH圧縮アルゴリズムにUDVMバイトコードを提供します。 LZJHは国際電気通信連合(ITU-T)推薦V.44[9]によって採用されたアルゴリズムです。
Assembly for the LZJH decompressor is given below:
LZJH減圧装置のための議会を以下に与えます:
at (32) readonly (0)
(32) readonlyで(0)
; The following 2-byte variables are stored in the scratch-pad memory ; area because they do not need to be saved after decompressing a ; SigComp message:
; 以下の2バイトの変数はスクラッチパッドメモリに格納されます。 彼らがするので、aを減圧した後に、領域は救われる必要はありません。 SigCompメッセージ:
:length_value pad (2) :position_value pad (2) :index pad (2) :extra_extension_bits pad (2) :codebook_old pad (2)
:長さ_値のパッド(2): _値のパッド(2):indexパッド(2)を置いてください: 余分な_拡大_ビットは(2): 符号表の_の古いパッドを水増しします。(2)
at (42)
at(42)
set (requested_feedback_location, 0)
セットします。(要求された_フィードバック_位置、0)
at (64)
at(64)
; UDVM_registers
; UDVM_レジスタ
:byte_copy_left pad (2) :byte_copy_right pad (2)
:バイト_コピー_はパッド(2): バイト_コピー_を右のパッドに残しました。(2)
:input_bit_order pad (2)
:入力_ビット_オーダーパッド(2)
Surtees & West Informational [Page 24] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[24ページ]のRFC4464SigCompユーザのガイド2006年5月
; The following 2-byte variables are saved as state after ; decompressing a SigComp message:
; 変数が状態に保存される以下の2バイト。 SigCompメッセージを減圧します:
:current_length pad (2) :decompressed_pointer pad (2) :ordinal_length pad (2) :codeword_length pad (2) :codebook_next pad (2)
:現在の_長さのパッド(2): 次の減圧された_ポインタパッド(2): 序数_長さのパッド(2): 符号語_長さのパッド(2): 符号表_はそっと歩きます。(2)
set (returned_parameters_location, 0)
セットします。(返された_パラメタ_位置、0)
align (64) readonly (1)
(64) readonlyに並んでください。(1)
:initialize_memory
:_メモリを初期化してください。
; The following constants can be adjusted to configure the LZJH ; decompressor. The current settings are as recommended in the V.44 ; specification (given that a total of 8K UDVM memory is available):
; LZJHを構成するように以下の定数を調整できます。 減圧装置。 現在の設定はV.44でお勧めです。 仕様(合計8KのUDVMメモリが利用可能であるなら):
set (udvm_memory_size, 8192) ; sets the total memory for LZJH set (max_extension_length, 8) ; sets the maximum string extension set (min_ordinal_length, 7) ; sets the minimum ordinal length set (min_codeword_length, 6) ; sets the minimum codeword length
セットしてください(udvm_メモリ_サイズ、8192)。 LZJHセット(最大_拡大_の長さ、8)のための総記憶を設定します。 最大のストリング拡大が設定したセット(分_序数_の長さ、7)。 最小の序数の長さのセットは(分_符号語_の長さ、6)を設定します。 最小の符号語の長さを設定します。
set (codebook_start, 4492) set (first_codeword, (codebook_start - 12)) set (state_length, (udvm_memory_size - 64))
セット(符号表_始め、4492)セット((符号表_は始動します--12)最初の_符号語である)セット(_長さを述べてください、(udvm_メモリ_サイズ--64))
MULTILOAD (64, 8, circular_buffer, udvm_memory_size, 7, 0, circular_buffer, min_ordinal_length, min_codeword_length, codebook_start)
MULTILOAD(64、8、円形の_バッファ、udvm_メモリ_サイズ、7、0、円形の_バッファ、分_序数_の長さ、分_符号語_の長さ、符号表_始め)
:decompress_sigcomp_message
:_sigcomp_メッセージを減圧してください。
:standard_prefix
:標準の_接頭語
; The following code decompresses the standard 1-bit LZJH prefix ; that specifies whether the next character is an ordinal or a ; codeword/control value:
; 以下のコードは標準の1ビットのLZJH接頭語を減圧します。 それは次のキャラクタが序数であるか、そして、aを指定します。 符号語/コントロール値:
INPUT-BITS (1, index, end_of_message) COMPARE ($index, 1, ordinal, codeword_control, codeword_control)
INPUT-BITS(1、インデックス、_メッセージの終わりの_)COMPARE($インデックス、1、序数、符号語_コントロール、符号語_コントロール)
:prefix_after_codeword
:_符号語の後の接頭語_
Surtees & West Informational [Page 25] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[25ページ]のRFC4464SigCompユーザのガイド2006年5月
; The following code decompresses the special LZJH prefix that only ; occurs after a codeword. It specifies whether the next character ; is an ordinal, a codeword/control value, or a string extension:
; 以下のコードは減圧されます。特別なLZJHはそれだけを前に置きます。 符号語の後に起こります。 それが指定する、次のキャラクタ。 序数、符号語/コントロール値、またはストリング拡大です:
INPUT-HUFFMAN (index, end_of_message, 2, 1, 1, 1, 2, 1, 0, 1, 0) COMPARE ($index, 1, ordinal, string_extension, codeword_control)
INPUT-ハフマン、(索引をつけてください、そして、_メッセージの_、2、1、1、1、2、1、0、1、0)COMPAREを終わらせてください。($インデックス、1、序数、ストリング_拡張子、符号語_コントロール)
:ordinal
:序数
; The following code decompresses an ordinal character and creates ; a new codebook entry consisting of the ordinal character and the ; next character to be decompressed:
; そして、以下のコードが目のキャラクタを減圧する、作成します。 そして、目のキャラクタから成る新しい符号表エントリー、。 次の減圧されるべきキャラクタ:
set (index_lsb, (index + 1)) set (current_length_lsb, (current_length + 1))
セット(インデックス_lsb、(インデックス+1))セット(_現在の_の長さのlsb、(現在の_長さ+1))
INPUT-BITS ($ordinal_length, index, !) OUTPUT (index_lsb, 1) LOAD (current_length, 2) COPY-LITERAL (current_length_lsb, 3, $codebook_next) COPY-LITERAL (index_lsb, 1, $decompressed_pointer) JUMP (standard_prefix)
INPUT-BITS($の序数_長さ、インデックス!) 出力されて(インデックス_lsb、1)、コピー文字通り(_現在の_の長さのlsb、3、次の$符号表_)のコピー文字通り(インデックス_lsb、1、$は_ポインタを減圧した)のジャンプをロードしてください(現在の_の長さ、2)。(標準の_接頭語)
:codeword_control
:符号語_コントロール
; The following code decompresses a codeword/control value:
; 以下のコードは符号語/コントロール値を減圧します:
INPUT-BITS ($codeword_length, index, !) COMPARE ($index, 3, control_code, initialize_memory, codeword)
INPUT-BITS($の符号語_長さ、インデックス!) 比較してください。($インデックス、3、規制_コードは_メモリ、符号語を初期化します)
:codeword
:符号語
; The following code interprets a codeword as an index into the LZJH ; codebook. It extracts the position/length pair from the specified ; codebook entry; the position/length pair points to a byte string ; in the circular buffer, which is then copied to the end of the ; decompressed message. The code also creates a new codebook entry ; consisting of the byte string plus the next character to be ; decompressed:
; 以下のコードはインデックスとしてLZJHに符号語を解釈します。 符号表。 それは指定から位置/長さの組を抽出します。 符号表エントリー。 1バイトへのポイントが結ぶ位置/長さの組。 終わりまでコピーされたその時が円形のバッファでは、どれのものであるか、。 メッセージを減圧しました。 また、コードは新しい符号表エントリーを作成します。 バイトストリングと次のキャラクタから成る、。 減圧される:
set (length_value_lsb, (length_value + 1))
セットします。(_長さ_値のlsb、(長さ_値+1))
MULTIPLY ($index, 3) ADD ($index, first_codeword) COPY ($index, 3, length_value_lsb) LOAD (current_length, 1) ADD ($current_length, $length_value) LOAD (codebook_old, $codebook_next)
MULTIPLY($インデックス、3)ADD($インデックス、最初の_符号語)COPY($インデックス、3、長さの_は_lsbを評価する)LOAD(現在の_の長さ、1)ADD($の現在の_の長さ、$長さの_価値)LOAD(次の古い符号表_$符号表_)
Surtees & West Informational [Page 26] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[26ページ]のRFC4464SigCompユーザのガイド2006年5月
COPY-LITERAL (current_length_lsb, 3, $codebook_next) COPY-LITERAL ($position_value, $length_value, $decompressed_pointer) OUTPUT ($position_value, $length_value) JUMP (prefix_after_codeword)
コピー文字通り(_現在の_の長さのlsb、3、次の$符号表_)のコピー文字通り($位置の_価値、$長さの_価値、$は_ポインタを減圧した)の出力($位置の_価値、$長さの_価値)ジャンプ(_符号語の後の接頭語_)
:string_extension
:ストリング_拡大
; The following code decompresses a Huffman-encoded string extension:
; 以下のコードはハフマンによってコード化されたストリング拡大を減圧します:
INPUT-HUFFMAN (index, !, 4, 1, 1, 1, 1, 2, 1, 3, 2, 1, 1, 1, 13, 3, 0, 7, 5) COMPARE ($index, 13, continue, extra_bits, extra_bits)
ハフマンが入力される、(索引をつけてください、4、1、1、1、1、2、1、3、2、1、1、1、13、3、0、7、5は)比較されます。($インデックス、13が続いて、余分な_がビットであり、余分な_はビットです)
:extra_bits
:余分な_ビット
INPUT-BITS (max_extension_length, extra_extension_bits, !) ADD ($index, $extra_extension_bits)
INPUT-BITS(最大_拡大_の長さ、余分な_拡大_ビット!) 加えてください。($インデックス、$余分な_拡大_ビット)
:continue
:続いてください。
; The following code extends the most recently created codebook entry ; by the number of bits specified in the string extension:
; 以下のコードは最も最近作成された符号表エントリーを広げています。 ストリング拡大で指定されたビットの数に従って:
COPY-LITERAL ($position_value, $length_value, $position_value) COPY-LITERAL ($position_value, $index, $decompressed_pointer) OUTPUT ($position_value, $index) ADD ($index, $length_value) COPY (index_lsb, 1, $codebook_old) JUMP (standard_prefix)
コピー文字通り($位置の_価値、$長さの_価値、$は_値を置く)のコピー文字通り($位置_値、$は索引をつけて、$は_ポインタを減圧した)の出力($位置_値、$は索引をつける)は、($インデックス、$長さ_値)がジャンプをコピーする(_lsb、1、$符号表_に古い状態で索引をつける)と言い足します。(標準の_接頭語)
:control_code
:コントロール_コード
; The code can handle all of the control characters in V.44 except ; for ETM (Enter Transparent Mode), which is not required for ; message-based protocols such as SigComp.
; V.44の制御文字のすべてが除くコード缶のハンドル。 ETM(Transparent Modeに入る)に、どれは必要でないか、。 SigCompなどのメッセージベースのプロトコル。
COMPARE ($index, 1, !, flush, stepup)
比較してください。($インデックス、1!、水洗、stepup)
:flush
:水洗
; The FLUSH control character jumps to the beginning of the next ; complete byte in the compressed message:
; FLUSH制御文字は次の始まりまでジャンプします。 圧縮されたメッセージのバイトを完成してください:
INPUT-BYTES (0, 0, 0) JUMP (standard_prefix)
入力バイト(0、0、0)はジャンプします。(標準の_接頭語)
:stepup
:stepup
Surtees & West Informational [Page 27] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[27ページ]のRFC4464SigCompユーザのガイド2006年5月
; The STEPUP control character increases the number of bits used to ; encode an ordinal value or a codeword:
; ビットの数が以前はよくそうしていたSTEPUP制御文字増加。 序数の値か符号語をコード化してください:
INPUT-BITS (1, index, !) COMPARE ($index, 1, stepup_ordinal, stepup_codeword, 0)
INPUT-BITS(1 インデックス!) 比較してください。($インデックス、1、stepupの_の序数の、そして、stepupな_符号語、0)
:stepup_ordinal
:stepup_序数
ADD ($ordinal_length, 1) JUMP (ordinal)
ジャンプを加えてください($の序数_長さ、1)。(序数)です。
:stepup_codeword
:stepup_符号語
ADD ($codeword_length, 1) JUMP (codeword_control)
ジャンプを加えてください($の符号語_長さ、1)。(符号語_コントロール)
:end_of_message
:_メッセージの終わりの_
END-MESSAGE (requested_feedback_location, returned_parameters_location, state_length, 64, decompress_sigcomp_message, 6, 0)
終わりメッセージ(要求された_フィードバック_位置、返された_パラメタ_位置が、_長さ、64が_sigcomp_メッセージ、6を減圧すると述べる、0)
readonly (0) :circular_buffer
readonly(0): 回覧_バッファ
An example of a message compressed using the LZJH algorithm is given below:
LZJHアルゴリズムを使用することで圧縮されたメッセージに関する例は以下に出されます:
0x5c09 e6e0 cadc c8d2 dcce 40c2 40f2 cac2 e440 c825 c840 ccde 29e8 0xc2f0 40e0 eae4 e0de e6ca e65c 1403
0x5c09 e6e0 cadc c8d2 dcce 40c2 40f2 cac2 e440 c825 c840 ccde 29e8 0xc2f0 40e0 eae4 e0de e6ca e65c1403
The uncompressed message is "...spending a year dead for tax purposes.\n".
「解凍されたメッセージはそうです」…「税金目的\nで死んでいた状態で1年を過ごします。」
4.2. Adapted Algorithms
4.2. 適合しているアルゴリズム
4.2.1. Modified DEFLATE
4.2.1. 変更されて、空気を抜いてください。
Alternative algorithms can also be used with SigComp. This section shows a modified version of the DEFLATE [8] algorithm. The two-stage encoding of DEFLATE is replaced by a single step with a discrete Huffman code for each symbol. The literal/length symbol probabilities are dependent upon whether the previous symbol was a literal or a match. Bit handling is also simpler, in that all bits are input using the INPUT-HUFFMAN instruction and the value of the H bit does not change so all bits are input, read, and interpreted in the same order.
また、SigCompと共に代替のアルゴリズムを使用できます。 このセクションはDEFLATE[8]アルゴリズムの変更されたバージョンを示しています。 各シンボルのために離散的なハフマン符号でDEFLATEの2ステージのコード化をシングルステップに取り替えます。 文字通りの/長さシンボル確率は前のシンボルが文字通りかaマッチであったかどうかに依存しています。 また、ビット操作も、より簡単です、すべてのビットがINPUT-ハフマン指示を使用する入力であり、Hビットの価値が変化しないで、読まれるので、すべてのビットが同次で入力されて、解釈されるので。
Surtees & West Informational [Page 28] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[28ページ]のRFC4464SigCompユーザのガイド2006年5月
Assembly for the algorithm is given below. String matching rules are the same as for the other LZ-based algorithms, with the alternative encoding of the literals and length/distance pairs.
アルゴリズムのための議会を以下に与えます。 ストリングマッチング規則は他のLZベースのアルゴリズムのように同じです、誤字誤植と長さ/距離組の代替のコード化で。
at (32) readonly (0)
(32) readonlyで(0)
:index pad (2) :distance_value pad (2) :old_pointer pad (2)
:インデックスパッド(2): 距離_値のパッド(2): 古い_ポインタパッド(2)
at (42)
at(42)
set (requested_feedback_location, 0)
セットします。(要求された_フィードバック_位置、0)
at (64)
at(64)
:byte_copy_left pad (2) :byte_copy_right pad (2) :input_bit_order pad (2) :decompressed_pointer pad (2)
:バイト_コピー_はパッド(2): バイト_コピー_を右のパッド(2)に残しました: 入力_は_オーダーパッド(2)に噛み付きました: _ポインタパッドを減圧します。(2)
set (returned_parameters_location, 0)
セットします。(返された_パラメタ_位置、0)
at (128) readonly (1)
(128) readonlyで(1)
:initialize_memory
:_メモリを初期化してください。
set (udvm_memory_size, 8192) set (state_length, (udvm_memory_size - 64))
セット(udvm_メモリ_サイズ、8192)セット(_長さを述べてください、(udvm_メモリ_サイズ--64))
MULTILOAD (64, 4, circular_buffer, udvm_memory_size, 0, circular_buffer)
MULTILOAD(64、4、円形の_バッファ、udvm_メモリ_サイズ、0、円形の_バッファ)
:decompress_sigcomp_message
:_sigcomp_メッセージを減圧してください。
:character_after_literal
:次々と文字通りのキャラクタ_
INPUT-HUFFMAN (index, end_of_message, 16,
5, 0, 11, 46,
0, 12, 12, 256,
1, 26, 32, 257,
1, 66, 68, 32,
0, 69, 94, 97,
0, 95, 102, 264,
0, 103, 103, 511,
2, 416, 426, 35,
INPUT-ハフマン、(索引をつけてくださいといって、_メッセージの_を終わらせてください、16、5、0、11、46、0、12、12、256、1、26、32、257、1、66、68、32、0、69、94、97、0、95、102、264、0、103、103、511、2、416、426、35
Surtees & West Informational [Page 29] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[29ページ]のRFC4464SigCompユーザのガイド2006年5月
0, 427, 465, 58,
0, 466, 481, 272,
1, 964, 995, 288,
3, 7968, 7988, 123,
0, 7989, 8115, 384,
1, 16232, 16263, 0,
0, 16264, 16327, 320,
1, 32656, 32767, 144)
0, 427, 465, 58, 0, 466, 481, 272, 1, 964, 995, 288, 3, 7968, 7988, 123, 0, 7989, 8115, 384, 1, 16232, 16263, 0, 0, 16264, 16327, 320, 1, 32656, 32767, 144)
COMPARE ($index, 256, literal, distance, distance)
比較してください。(文字通りの256が、$が索引をつけるのを遠ざける、距離)
:character_after_match
:_マッチの後のキャラクタ_
INPUT-HUFFMAN (index, end_of_message, 16,
4, 0, 0, 511,
1, 2, 9, 256,
1, 20, 22, 32,
0, 23, 30, 264,
1, 62, 73, 46,
0, 74, 89, 272,
2, 360, 385, 97,
0, 386, 417, 288,
1, 836, 874, 58,
0, 875, 938, 320,
1, 1878, 1888, 35,
0, 1889, 2015, 384,
1, 4032, 4052, 123,
1, 8106, 8137, 0,
1, 16276, 16379, 144,
1, 32760, 32767, 248)
ハフマンは入力されます。(索引をつけてくださいといって、_メッセージの_を終わらせてください、16、4、0、0、511、1、2、9、256、1、20、22、32、0、23、30、264、1、62、73、46、0、74、89、272、2、360、385、97、0、386、417、288、1、836、874、58、0、875、938、320、1、1878、1888、35、0、1889、2015、384、1、4032、4052、123、1、8106、8137、0、1、16276、16379、144、1、32760、32767、248)
COMPARE ($index, 256, literal, distance, distance)
比較してください。(文字通りの256が、$が索引をつけるのを遠ざける、距離)
:literal
:文字通り
set (index_lsb, (index + 1))
セットします。(インデックス_lsb、(インデックス+1))
OUTPUT (index_lsb, 1) COPY-LITERAL (index_lsb, 1, $decompressed_pointer) JUMP (character_after_literal)
コピー文字通り(インデックス_lsb、1、$は_ポインタを減圧した)のジャンプを出力してください(インデックス_lsb、1)。(次々と文字通りのキャラクタ_)
:distance
:距離
SUBTRACT ($index, 253)
INPUT-HUFFMAN (distance_value, !, 9,
9, 0, 7, 9,
0, 8, 63, 129,
1, 128, 135, 1,
($インデックス、253)INPUTハフマンを引き算してください。(距離_が評価する、9、9、0、7、9、0、8、63、129、1、128、135、1
Surtees & West Informational [Page 30] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[30ページ]のRFC4464SigCompユーザのガイド2006年5月
0, 136, 247, 17,
0, 248, 319, 185,
1, 640, 1407, 257,
2, 5632, 6655, 1025,
1, 13312, 15359, 2049,
2, 61440, 65535, 4097)
0, 136, 247, 17, 0, 248, 319, 185, 1, 640, 1407, 257, 2, 5632, 6655, 1025, 1, 13312, 15359, 2049, 2, 61440, 65535, 4097)
LOAD (old_pointer, $decompressed_pointer) COPY-OFFSET ($distance_value, $index, $decompressed_pointer) OUTPUT ($old_pointer, $index) JUMP (character_after_match)
負荷(古い_ポインタ、$は_ポインタを減圧した)コピーオフセット($距離_値、$は索引をつけて、$は_ポインタを減圧した)出力($の古い_ポインタ、$は索引をつける)ジャンプ(_マッチの後のキャラクタ_)
:end_of_message
:_メッセージの終わりの_
END-MESSAGE (requested_feedback_location, returned_parameters_location, state_length, 64, decompress_sigcomp_message, 6, 0)
終わりメッセージ(要求された_フィードバック_位置、返された_パラメタ_位置が、_長さ、64が_sigcomp_メッセージ、6を減圧すると述べる、0)
readonly (0) :circular_buffer
readonly(0): 回覧_バッファ
An example of a message compressed using the modified DEFLATE algorithm is given below:
変更されたDEFLATEアルゴリズムを使用することで圧縮されたメッセージに関する例は以下に出されます:
0xd956 b132 cd68 5424 c5a9 6215 8a70 a64d af0a 5499 3621 509b 3e4c 0x28b4 a145 b362 653a d0a6 498b 5a6d 2970 ac4c 930a a4ca 74a4 c268 0x0c
0xd956 b132 cd68 5424 c5a9 6215 8a70 a64d af0a5499 3621 509b 3e4c 0x28b4 a145 b362 653a d0a6 498b 5a6d2970ac4c 930a a4ca 74a4 c268 0x0c
The uncompressed message is "Arthur leapt to his feet like an author hearing the phone ring".
解凍されたメッセージは「アーサーは電話の呼び出し音を聞く作者のように彼の足に跳ねました」です。
5. Additional SigComp Mechanisms
5. 追加SigCompメカニズム
This section covers the additional mechanisms that can be employed by SigComp to improve the overall compression ratio, including the use of acknowledgements, dictionaries, and sharing state between two directions of a compressed message flow.
このセクションはSigCompが総合的な圧縮比を改良するのに使うことができる追加メカニズムをカバーします、圧縮されたメッセージ流動の2つの方向の間の承認、辞書、および共有状態の使用を含んでいて。
An example of assembly code is provided for these mechanisms. Depending on the mechanism and basic algorithm in use, the assembly code for either the mechanism or the basic algorithm may require modification (e.g., if the algorithm uses 'no more input' to jump to end_of_message, following end_of_message with an input instruction for CRC will not work). In any case, these are examples and there may be alternative ways to make use of the mechanisms.
アセンブリコードに関する例をこれらのメカニズムに提供します。使用中のメカニズムと基本的なアルゴリズムによって、メカニズムか基本的なアルゴリズムのどちらかのためのアセンブリコードは、変更を必要とするかもしれません(例えば、アルゴリズムが_メッセージの_を終わらせるためにジャンプするのに'それ以上の入力がありません'を使用すると、CRCのための入力命令で_メッセージの終わりの_に続くのは働かないでしょう)。 どのような場合でも、これらは例です、そして、メカニズムを利用する代替の方法があるかもしれません。
Surtees & West Informational [Page 31] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[31ページ]のRFC4464SigCompユーザのガイド2006年5月
When each of the compression algorithms described in Section 4 has successfully decompressed the current SigComp message, the contents of the UDVM memory are saved as a SigComp state item. Subsequent messages can access this state item by uploading the correct state identifier to the receiving endpoint, which avoids the need to upload the bytecode for the compression algorithm on a per-message basis. However, before a state item can be accessed, the compressor must first ensure that it is available at the receiving endpoint.
セクション4で説明されたそれぞれの圧縮アルゴリズムが首尾よく現在のSigCompメッセージを減圧したとき、UDVMメモリの内容はSigComp州の品目として保存されます。 正しい州の識別子を受信終点にアップロードすることによって、その後のメッセージはこの州の項目にアクセスできます。(終点は1メッセージあたり1個のベースの圧縮アルゴリズムのためにバイトコードをアップロードする必要性を避けます)。 しかしながら、州の項目にアクセスできる前にコンプレッサーは、最初に、それが受信終点で利用可能であることを確実にしなければなりません。
For each SigComp compartment, the receiving endpoint maintains a list of currently available states (where the total amount of state saved does not exceed the state_memory_size for the compartment). The SigComp compressor should maintain a similar list containing the states that it has instructed the receiving endpoint to save.
それぞれのSigCompコンパートメントに関しては、受信終点は現在利用可能な州(節約された状態の総量が状態_メモリ_サイズをコンパートメントに超えていないところ)のリストを維持します。 SigCompコンプレッサーはそれが、受信終点が救うよう命令した州を含む同様のリストを維持するはずです。
As well as tracking the list of state items that it has saved at the remote endpoint, the compressor also maintains a flag for each state item indicating whether or not the state can safely be accessed. State items should not be accessed until they have been acknowledged (e.g., by using the SigComp feedback mechanism as per Section 5.1).
また、それが遠く離れた終点に保存した州の項目のリストを追跡することと同様に、コンプレッサーは安全に状態にアクセスできるかどうかを示すそれぞれの州の項目のために旗を維持します。 それらが承認されるまで(例えば、セクション5.1に従ってSigCompフィードバック・メカニズムを使用することによって)、州の項目にアクセスするべきではありません。
State items are deleted from the list when adding a new piece of state when the total state_memory_size for the compartment is full. The state to be deleted is determined according to age and retention priority as discussed in SigComp [2]. The SigComp compressor should not attempt to access any state items that have been deleted in this manner, as they may no longer be available at the receiving endpoint.
コンパートメントへの総状態_メモリ_サイズが完全であるときに、新しい状態を加えるとき、州の項目はリストから削除されます。 時代と保有優先権に従って、削除されるべき状態はSigComp[2]で議論するように決定しています。 SigCompコンプレッサーは、この様に削除されたどんな州の項目にもアクセスするのを試みるはずがありません、それらがもう受信終点で利用可能でないときに。
5.1. Acknowledging a State Item
5.1. 州の項目を承認します。
SigComp [2] defines a feedback mechanism to allow the compressor to request feedback from the decompressor, to give the compressor indication that a message has been received and correctly decompressed and that state storage has been attempted. (Note: This mechanism cannot convey the success or failure of individual state creation requests.) In order to invoke the feedback mechanism, the following fields must be reserved in the UDVM memory:
SigComp[2]は、コンプレッサーが減圧装置からフィードバックを要求して、メッセージが受け取られて、正しく減圧されて、州の格納を試みてあるというコンプレッサー指示を与えるのを許容するためにフィードバック・メカニズムを定義します。 (注意: このメカニズムは個々の州の創造要求の成否を運ぶことができません。) フィードバック・メカニズムを呼び出すために、UDVMメモリで以下の分野を予約しなければなりません:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| reserved | Q | S | I | requested_feedback_location
+---+---+---+---+---+---+---+---+
| 1 | requested_feedback_length | if Q = 1
+---+---+---+---+---+---+---+---+
| |
: requested_feedback_field : if Q = 1
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 予約されます。| Q| S| I| 要求された_フィードバック_位置+---+---+---+---+---+---+---+---+ | 1 | 要求された_のフィードバック_長さ| Qが1+と等しいなら---+---+---+---+---+---+---+---+ | | : 要求された_フィードバック_分野: Qが1と等しいなら| | +---+---+---+---+---+---+---+---+
Surtees & West Informational [Page 32] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[32ページ]のRFC4464SigCompユーザのガイド2006年5月
These fields can be reserved in any of the algorithms of Section 4 by replacing the line "set (requested_feedback_location, 0)" with the following assembly:
以下のアセンブリで「セット(_フィードバック_位置、0を要求する)」という線を置き換えるのによるセクション4のアルゴリズムのどれかでこれらの分野を予約できます:
:requested_feedback_location pad (1) :requested_feedback_length pad (1) :requested_feedback_field pad (12) :hash_start pad (8)
:要求された_フィードバック_位置のパッド(1): 要求された_フィードバック_長さのパッド(1): 要求された_フィードバック_分野パッド(12): 細切れ肉料理_スタートパッド(8)
When a SigComp message is successfully decompressed and saved as state, the following bytecode instructs the receiving endpoint to return the first 6 bytes of the corresponding state identifier. The bytecode can be added to any of the compression algorithms of Section 4 immediately following the ":end_of_message" label:
SigCompメッセージが首尾よく減圧されて、状態として保存されるとき、以下のバイトコードは、最初の6バイトの対応する州の識別子を返すよう受信終点に命令します。 「すぐに続くとセクション4の圧縮アルゴリズムのどれかにバイトコードを追加できる、」 : _の終わりの_は」 ラベルを通信させます:
:end_of_message
:_メッセージの終わりの_
set (hash_length, (state_length + 8))
セットします。(細切れ肉料理_長さ、(状態_長さ+8))
LOAD (requested_feedback_location, 1158) MULTILOAD (hash_start, 4, state_length, 64, decompress_sigcomp_message, 6) SHA-1 (hash_start, hash_length, requested_feedback_field)
LOAD(_フィードバック_位置、1158を要求する)MULTILOAD(細切れ肉料理_始め、4は、_長さ、64が_sigcomp_メッセージ、6を減圧すると述べる)SHA-1(細切れ肉料理_始め(細切れ肉料理_長さ)は_フィードバック_分野を要求しました)
The receiving endpoint then returns the state identifier in the "returned feedback field" of the next SigComp message to be transmitted in the reverse direction.
そして、受信終点は次の反対の方向に伝えられるべきSigCompメッセージの「返されたフィードバック分野」で州の識別子を返します。
When the state identifier is returned, the compressor can set the availability flag for the corresponding state to 1.
州の識別子を返すとき、コンプレッサーは1への対応する状態に有用性旗を設定できます。
5.2. Static Dictionary
5.2. 静的な辞書
Certain protocols that can be compressed using SigComp offer a fixed, mandatory state item known as a static dictionary. This dictionary contains a number of text strings that commonly occur in messages generated by the protocol in question. The overall compression ratio can often be improved by accessing the text phrases from this static dictionary rather than by uploading them as part of the compressed message.
SigCompを使用することで圧縮できるあるプロトコルは静的な辞書として知られている修理されて、義務的な州の商品を提供します。 この辞書は問題のプロトコルで発生するメッセージに一般的に現れる多くのテキスト文字列を含んでいます。 テキストにアクセスしながらしばしば圧縮比を改良できる総合的は圧縮されたメッセージの一部としてアップロードでというよりむしろこの静的な辞書からそれらを言葉で表します。
As an example, a static dictionary is provided for the protocols SIP and SDP, RFC 3485 [4]. This dictionary is designed for use by a wide range of compression algorithms including all of the ones covered in Section 4.
例として、プロトコルのSIPとSDPに静的な辞書を提供して、RFC3485は[4]です。 この辞書は使用のためにセクション4でカバーされたもののすべてを含むさまざまな圧縮アルゴリズムで設計されています。
Surtees & West Informational [Page 33] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[33ページ]のRFC4464SigCompユーザのガイド2006年5月
In any of the compression algorithms of Section 4, the static dictionary can be accessed by inserting the following instruction immediately after the ":initialize_memory" label:
「セクション4の圧縮アルゴリズムのどれかでは、直後の以下の指示を挿入することによって静的な辞書にアクセスできる、」、:、_メモリを初期化してください、」 以下をラベルしてください。
STATE-ACCESS (dictionary_id, 6, 0, 0, 1024, 0)
州アクセス(辞書_イド、6、0、0、1024、0)
The parameters of STATE-ACCESS instruction will depend on the compression algorithm in use.
州-ACCESS指示のパラメタは使用中の圧縮アルゴリズムに依存するでしょう。
The following lines should also be inserted immediately after the END-MESSAGE instruction:
また、以下の線はEND-MESSAGE指示直後挿入されるべきです:
:dictionary_id
:辞書_イド
byte (0xfb, 0xe5, 0x07, 0xdf, 0xe5, 0xe6)
バイト(0xfb、0xe5、0×07、0xdf、0xe5、0xe6)
The text strings contained in the static dictionary can then be accessed in exactly the same manner as the text strings from previously decompressed messages (see Section 5.1 for further details).
そして、まさにテキスト文字列と同じ方法で以前に減圧されたメッセージから静的な辞書に含まれたテキスト文字列にアクセスできます(さらに詳しい明細についてはセクション5.1を見てください)。
Note that in some cases it is sufficient to load only part of the static dictionary into the UDVM memory. Further information on the contents of the SIP and SDP static dictionary can be found in the relevant document, RFC 3485 [4].
いくつかの場合、静的な辞書の一部だけをUDVMメモリに積み込むのが十分であることに注意してください。 関連ドキュメント(RFC3485[4])でSIPとSDPの静的な辞書のコンテンツに関する詳細を見つけることができます。
5.3. CRC Checksum
5.3. CRCチェックサム
The acknowledgement scheme of Section 5.1 is designed to indicate the successful decompression of a message. However, it does not guarantee that the decompressed message is identical to the original message, since decompression of a corrupted message could succeed but with some characters being incorrect. This could lead to an incorrect message being passed to the application or unexpected contents of state to be stored. In order to prevent this happening, a CRC check could be used.
セクション5.1の承認計画は、メッセージのうまくいっている減圧を示すように設計されています。 しかしながら、減圧されたメッセージがオリジナルのメッセージと同じであることを保証しません、しかし、何人かのキャラクタが不正確な状態で崩壊したメッセージの減圧が成功できたので。 これは格納されるために状態のアプリケーションか予期していなかったコンテンツに通過される不正確なメッセージに通じるかもしれません。 この出来事を防ぐために、CRCチェックを使用できました。
If an additional CRC check is required, then the following bytecode can be inserted after the ":end_of_message" label:
「追加CRCチェックが必要であるなら後に以下のバイトコードを挿入できる、」 : _の終わりの_は」 ラベルを通信させます:
INPUT-BYTES (2, index, !) CRC ($index, 64, state_length, !)
INPUT-BYTES(2 インデックス!) CRC($インデックス、64、状態_長さ!)
The bytecode extracts a 2-byte CRC from the end of the SigComp message and compares it with a CRC calculated over the UDVM memory. Decompression failure occurs if the two CRC values do not match.
バイトコードは、SigCompメッセージの終わりから2バイトのCRCを抽出して、UDVMメモリに関して計算されたCRCとそれを比べます。 2つのCRC値が合っていないなら、減圧失敗は起こります。
Surtees & West Informational [Page 34] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[34ページ]のRFC4464SigCompユーザのガイド2006年5月
A definition of the CRC polynomial used by the CRC instruction can be found in SigComp [2].
SigComp[2]でCRC指示で使用されるCRC多項式の定義を見つけることができます。
5.4. Announcing Additional Resources
5.4. 追加リソースを発表します。
If a particular endpoint is able to offer more processing or memory resources than the mandatory minimum, the SigComp feedback mechanism can be used to announce that these resources are available to the remote endpoint. This may help to improve the overall compression ratio between the two endpoints.
特定の終点が義務的な最小限より処理かメモリリソースを提供できるなら、これらのリソースが遠く離れた終点に利用可能であると発表するのにSigCompフィードバック・メカニズムを使用できます。 これは、2つの終点の間の総合的な圧縮比を改良するのを助けるかもしれません。
Additionally, if an endpoint has any pieces of state that may be useful for the remote endpoint to reference, it can advertise the identifiers for the states. The remote endpoint can then make use of any that it also knows about (i.e., knows the contents of), for example, a dictionary or shared mode state (see Section 5.5).
さらに、終点がどんな遠く離れた終点の役に立つかもしれない状態を参照に持っているなら、それは州のための識別子の広告を出すことができます。 すなわち、次に、遠く離れた終点がまたそれが知っているいずれも利用できる、(コンテンツを知っている、)、辞書の、または、例えば、共有されたモード状態(セクション5.5を見ます)。
The values of the following SigComp parameters can be announced using the SigComp advertisement mechanism:
SigComp広告メカニズムを使用することで以下のSigCompパラメタの値を発表できます:
cycles_per_bit
decompression_memory_size
state_memory_size
SigComp_version
state identifiers
_噛み付いている減圧_メモリの状態_メモリ_サイズSigComp_バージョン州の_サイズ識別子あたりの_を循環させます。
Surtees & West Informational [Page 35] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[35ページ]のRFC4464SigCompユーザのガイド2006年5月
As explained in SigComp, in order to announce the values of these parameters, the following fields must be reserved in the UDVM memory:
SigCompで説明されるように、これらのパラメタの値を発表するためにUDVMメモリで以下の分野を予約しなければなりません:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| cpb | dms | sms | returned_parameters_location
+---+---+---+---+---+---+---+---+
| SigComp_version |
+---+---+---+---+---+---+---+---+
| length_of_partial_state_ID_1 |
+---+---+---+---+---+---+---+---+
| |
: partial_state_identifier_1 :
| |
+---+---+---+---+---+---+---+---+
: :
+---+---+---+---+---+---+---+---+
| length_of_partial_state_ID_n |
+---+---+---+---+---+---+---+---+
| |
: partial_state_identifier_n :
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | cpb| dms| sms| 返された_パラメタ_位置+---+---+---+---+---+---+---+---+ | SigComp_バージョン| +---+---+---+---+---+---+---+---+ | _部分的な_州の_ID_1の長さの_| +---+---+---+---+---+---+---+---+ | | : 部分的な_州の_識別子_1: | | +---+---+---+---+---+---+---+---+ : : +---+---+---+---+---+---+---+---+ | _部分的な_状態_IDの長さの_| +---+---+---+---+---+---+---+---+ | | : 部分的な_状態_識別子: | | +---+---+---+---+---+---+---+---+
These fields can be reserved in any of the algorithms of Section 4 by replacing the line "set (returned_parameters_location, 0)" with the following piece of assembly:
以下のアセンブリで「セット(_パラメタ_位置、0を返す)」という線を置き換えるのによるセクション4のアルゴリズムのどれかでこれらの分野を予約できます:
:adverts_len pad (1) :adverts_len_lsb pad (1) :returned_parameters_location pad (1) :returned_sigcomp_version pad (1) :state_ids pad (x)
:言及、_lenは(1)を水増しします: _lenに、_lsbパッド(1): 返された_パラメタ_位置のパッド(1): 返された_sigcomp_バージョンパッド(1): 状態_イドパッドについて言及します。(x)
where x is enough space for the number state identifiers that the endpoint wishes to advertise.
xが終点がそうしたがっている数の州の識別子のための十分なスペースであるところでは、広告を出してください。
When a SigComp message is successfully decompressed and saved as state, the following bytecode announces to the receiving endpoint that additional resources and pieces of state are available at the sending endpoint:
SigCompメッセージが首尾よく減圧されて、状態として保存されるとき、以下のバイトコードは、状態の追加リソースと断片が送付終点で利用可能であると受信終点に発表します:
:end_of_message
:_メッセージの終わりの_
LOAD (returned_parameters_location, N) INPUT-BYTES (1, adverts_len_lsb, done) INPUT-BYTES ($adverts_len, state_ids, done)
LOAD(_位置、Nを_パラメタに返す)INPUT-BYTES、(1、_lenに_lsbについて言及して、して、INPUT-BYTES($は_len、行われた状態_イドについて言及します)
Surtees & West Informational [Page 36] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[36ページ]のRFC4464SigCompユーザのガイド2006年5月
:done
:します。
Note that the integer value "N" should be set equal to the amount of resources available at the sending endpoint. N should be expressed as a 2-byte integer with the most significant bits corresponding to the cycles_per_bit parameter and the least significant bits corresponding to the SigComp_version parameter.
整数値「N」が送付終点で利用可能なリソースの量と等しいセットであることに注意してください。 Nは、1_あたりの_がサイクルに対応する最も重要なビットがある2バイトの整数にパラメタと最下位ビットに噛み付いて、SigComp_バージョンパラメタに対応していたので、言い表されるべきです。
The length of the state identifiers followed by the state identifiers in the format shown are appended to the end of the compressed message.
圧縮されたメッセージの終わりまで示された書式での州の識別子があとに続いた州の識別子の長さを追加します。
5.5. Shared Compression
5.5. 共有された圧縮
This section provides bytecode for implementing the SigComp shared compression mechanism, RFC 3321 [3]. If two endpoints A and B are communicating via SigComp, shared compression allows the messages sent from Endpoint A to Endpoint B to be compressed relative to the messages sent from Endpoint B to Endpoint A (and vice versa). This may improve the overall compression ratio by reducing the need to transmit the same information in both directions.
このセクションは共有された圧縮機構、RFC3321[3]をSigCompを実行するためのバイトコードに提供します。 2つの終点AとBがSigCompを通って交信する予定であるなら、共有された圧縮は、Endpoint AからEndpoint Bに送られたメッセージがEndpoint BからEndpoint A(逆もまた同様に)に送られたメッセージに比例して圧縮されるのを許容します。 これは、両方の指示の同じ情報を伝える必要性を減少させることによって、総合的な圧縮比を改良するかもしれません。
As described in RFC 3321 [3], two steps must be taken to implement shared compression at an endpoint.
RFC3321[3]で説明されるように、終点で共有された圧縮を実行するために2つの方法を取らなければなりません。
First, it is necessary to announce to the remote endpoint that shared compression is available. This is done by announcing the state identifier as an available piece of state. This can be done using the returned_parameters_location announcement as in Section 5.4.
まず最初に、遠く離れた終点に知らせるために、共有された圧縮が利用可能であることが必要です。 利用可能な状態として州の識別子を発表することによって、これをします。 これはセクション5.4のように返された_パラメタ_位置の発表を使用し終わることができます。
Second, assuming that such an announcement is received from the remote endpoint, then the state created by shared compression needs to be accessed by the message sent in the opposite direction. This can be done in a similar way to accessing the static dictionary (see Section 5.2), but using the appropriate state identifier, for example, by using the INPUT-BYTES instruction as below:
2番目に、そのような発表が遠く離れた終点から受けられると仮定する場合、共有された圧縮で創設された州は、逆方向に送られたメッセージによってアクセスされる必要があります。 静的な辞書(セクション5.2を見る)にアクセスしますが、例えば、以下のINPUT-BYTES同じくらい指示を使用することによって適切な州の識別子を使用することへの同様の方法でこれができます:
:shared_state_id pad (6)
:共有された_状態_イドパッド(6)
:access_shared_state
:アクセス_は_状態を共有しました。
INPUT-BYTES (6, shared_state_id, !) STATE-ACCESS (shared_state_id, 6, 0, 0, $decompressed_start, 0)
INPUT-BYTES(6、共有された_状態_イド!) 州アクセス(共有された_状態_イド、6、0、0、$の減圧された_始め、0)
Surtees & West Informational [Page 37] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[37ページ]のRFC4464SigCompユーザのガイド2006年5月
6. Security Considerations
6. セキュリティ問題
This document describes implementation options for the SigComp protocol [2]. Consequently, the security considerations for this document match those of SigComp.
このドキュメントはSigCompプロトコル[2]のための実現オプションについて説明します。 その結果、このドキュメントのためのセキュリティ問題はSigCompのものに合っています。
7. Acknowledgements
7. 承認
Thanks to Richard Price, Carsten Bormann, Adam Roach, Lawrence Conroy, Christian Schmidt, Max Riegel, Lars-Erik Jonsson, Jonathan Rosenberg, Stefan Forsgren, Krister Svanbro, Miguel Garcia, Christopher Clanton, Khiem Le, Ka Cheong Leung, and Zoltan Barczikay for valuable input and review.
貴重な入力とレビューをリチャードPrice、カルステン・ボルマン、アダム・ローチ、ローレンス・コンロイ、クリスチャンのシュミット、マックス・リーゲル、ラース-エリック・イェンソン、ジョナサン・ローゼンバーグ、ステファンForsgren、Krister Svanbro、ミゲル・ガルシア、クリストファーClanton、Khiem Le、Ka Cheongレオン、およびゾルタンBarczikayをありがとうございます。
Special thanks to Pekka Pessi and Cristian Constantin, who served as committed working group document reviewers.
ペッカPessiとクリスチャンコンスタンチンのおかげで、特別です。コンスタンチンは、遂行されたワーキンググループのドキュメント評論家として勤めました。
8. Intellectual Property Right Considerations
8. 知的所有権問題
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。
9. Normative References
9. 引用規格
[1] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[1] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[2] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu,
Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC
3320, January 2003.
[2] 価格、R.、ボルマン、C.、Christoffersson、J.、ハンヌ、H.、リュウ、Z.、およびJ.ローゼンバーグ、「シグナリング圧縮(SigComp)」、RFC3320(2003年1月)。
[3] Hannu, H., Christoffersson, J., Forsgren, S., Leung, K.-C.,
Liu, Z., and R. Price, "Signaling Compression (SigComp) -
Extended Operations", RFC 3321, January 2003.
[3] ハンヌ、H.、Christoffersson、J.、Forsgren、S.、レオン、K.C.、リュウ、Z.、およびR.は「圧縮(SigComp)--操作を広げると合図すること」でのRFC3321(2003年1月)に値を付けます。
[4] Garcia-Martin, M., Bormann, C., Ott, J., Price, R., and A.B.
Roach, "The Session Initiation Protocol (SIP) and Session
Description Protocol (SDP) Static Dictionary for Signaling
Compression (SigComp)", RFC 3485, February 2003.
[4] ガルシア-マーチン、M.、ボルマン、C.、オット、J.、価格、R.、およびA.B.ローチ、「セッション開始プロトコル(一口)とセッション記述はシグナリング圧縮(SigComp)のために(SDP)静的な辞書について議定書の中で述べます」、RFC3485、2003年2月。
[5] Ziv, J. and A. Lempel, "A universal algorithm for sequential
data compression", IEEE 23:337-343, 1977.
337-343、[5]ZivとJ.とA.Lempel、「連続したデータ圧縮のための普遍的なアルゴリズム」IEEE23:1977。
[6] Storer, J., "Data Compression: Methods and Theory", Computer
Science Press ISBN 0-88175-161-8, 1998.
[6]Storer、J.、「データ圧縮:」 コンピュータサイエンスは、「方法と理論」と押します。ISBN0-88175-161-8、1998。
Surtees & West Informational [Page 38] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[38ページ]のRFC4464SigCompユーザのガイド2006年5月
[7] Nelson, M., "LZW Data Compression", Dr Dobb's Journal,
October 1989.
[7] ネルソン、M.、「LZWデータ圧縮」、ドッブ博士のジャーナル、1989年10月。
[8] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996.
[8] ドイツ語、P.、「DEFLATE Compressed Data Format Specification、バージョン1.3インチ、RFC1951、1996インチ年5月。
[9] "Data Compression Procedures", ITU-T Recommendation V.44,
November 2000.
[9]「データ圧縮手順」、ITU-T推薦V.44、2000年11月。
Surtees & West Informational [Page 39] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[39ページ]のRFC4464SigCompユーザのガイド2006年5月
Appendix A. UDVM Bytecode for the Compression Algorithms
圧縮アルゴリズムのための付録A.UDVMバイトコード
The following sections list the UDVM bytecode generated for each compression algorithm of Section 4.
以下のセクションはセクション4のそれぞれの圧縮アルゴリズムのために発生するUDVMバイトコードを記載します。
Note that the different assemblers can output different bytecode for the same piece of assembly code, so a valid assembler can produce results different from those presented below. However, the following bytecode should always generate the same decompressed messages on any UDVM.
有効なアセンブラが以下に提示されたものと異なった結果を生むことができるように、異なったアセンブラが同じアセンブリコードのために異なったバイトコードを出力できることに注意してください。 しかしながら、以下のバイトコードはどんなUDVMに関する同じ減圧されたメッセージもいつも発生させるべきです。
A.1. Well-known Algorithms
A.1。 周知のアルゴリズム
A.1.1. LZ77
A.1.1。 LZ77
0x0f86 0389 8d89 1588 8800 011c 0420 0d13 5051 2222 5051 16f5 2300 0x00bf c086 a08b 06
0x0f86 0389 8d89 1588 8800 011c0420 0d13 5051 2222 5051 16f5 2300 0x00bf c086 a08b06
A.1.2. LZSS
A.1.2。 LZSS
0x0f86 04a0 c48d 00a0 c41e 2031 0209 00a0 ff8e 048c bfff 0117 508d 0x0f23 0622 2101 1321 0123 16e5 1d04 22e8 0611 030e 2463 1450 5123 0x2252 5116 9fd2 2300 00bf c086 a089 06
0x0f86 04a0 c48d 00a0 c41e 2031 0209 00a0 ff8e 048c bfff0117 508d 0x0f23 0622 2101 1321 0123 16e5 1d04 22e8 0611 030e2463 1450 5123 0×2252 5116 9fd2 2300 00bf c086 a089 06
A.1.3. LZW
A.1.3。 LZW
0x0f86 06a1 ce8d 00b1 8f01 a0ce 13a0 4903 2313 2501 2506 1201 1752 0x88f4 079f 681d 0a24 2508 1203 0612 b18f 1252 0321 0ea0 4801 0624 0x5013 a049 0323 1351 5025 2251 5016 9fde 2300 00bf c086 a09f 06
0x0f86 06a1 ce8d 00b1 8f01 a0ce 13a0 4903 2313 2501 2506 1201 1752 0x88f4 079f 681d 0a24 2508 1203 0612 b18f1252 0321 0ea0 4801 0624 0×5013a049 0323 1351 5025 2251 5016 9fde 2300 00bf c086 a09f06
A.1.4. DEFLATE
A.1.4。 空気を抜いてください。
0x0f86 7aa2 528d 05a2 5200 0300 0400 0500 0600 0700 0800 0900 0a01 0x0b01 0d01 0f01 1102 1302 1702 1b02 1f03 2303 2b03 3303 3b04 a043 0x04a0 5304 a063 04a0 7305 a083 05a0 a305 a0c3 05a0 e300 a102 0001 0x0002 0003 0004 0105 0107 0209 020d 0311 0319 0421 0431 05a0 4105 0xa061 06a0 8106 a0c1 07a1 0107 a181 08a2 0108 a301 09a4 0109 a601 0x0aa8 010a ac01 0bb0 010b b801 0c80 2001 0c80 3001 0d80 4001 0d80 0x6001 1d03 229f b41e 20a0 6504 0700 1780 4011 0130 a0bf 0000 a0c0 0xa0c7 8040 2901 a190 a1ff a090 1750 8040 1109 a046 1322 2101 1321 0x0123 169f d108 1004 1250 0422 1d51 229f d706 1251 1e20 9fcf 0105 0x001f 2f08 1004 1250 0426 1d53 26f6 0614 530e 2063 1454 5223 2250 0x5216 9f9e 2300 00bf c086 a1de 06
0x0f86 7aa2 528d 05a2 5200 0300 0400 0500 0600 0700 0800 0900 0a01 0x0b01 0d01 0f01 1102 1302 1702 1b02 1f03 2303 2b03 3303 3b04 a043 0x04a0 5304a063 04a0 7305a083 05a0 a305 a0c3 05a0 e300 a102 0001 0×0002 0003 0004 0105 0107 0209 020d 0311 0319 0421 0431 05a0 4105 0xa061 06a0 8106a0c1 07a1 0107a181 08a2 0108a301 09a4 0109a601 0x0aa8 010a ac01; 0bb0 010b b801 0c80 2001 0c80 3001 0d80 4001 0d80 0×6001 1d03 229f b41e 20a0 6504 0700 1780 4011 0130a0bf0000a0c0 0xa0c7 8040 2901a190 a1ff a090 1750 8040 1109a046 1322 2101 1321 0×0123 169f d108 1004 1250 0422 1d51 229f d706 1251 1e20 9fcf0105 0x001f 2f08 1004 1250 0426 1d53 26f6 0614 530e2063 1454 5223 2250 0×5216 9f9e 2300 00bf c086 a1de06
Surtees & West Informational [Page 40] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[40ページ]のRFC4464SigCompユーザのガイド2006年5月
A.1.5. LZJH
A.1.5。 LZJH
0x0f86 08a1 5b8d 0700 a15b 0706 b18f 1d01 24a0 c317 5201 1a31 311e 0x24a0 b802 0101 0102 0100 0100 1752 0107 a04e 1e1d 6524 f822 2501 0x0ea0 4602 13a0 4703 2713 2501 2416 9fcd 1d66 24e1 1752 03a0 639f 0xb808 0812 0306 12b1 8312 5203 210e a046 0106 2350 0e28 6713 a047 0x0327 1351 5024 2251 5016 9fa8 1e24 9fb1 0401 0101 0102 0103 0201 0x0101 0d03 0007 0517 520d 0d06 061d 0826 f706 1253 1351 5011 1351 0x5224 2251 5206 1250 1225 0154 169f 6617 5201 9fdb 070f 1c00 009e 0xce16 9f57 1d01 24fa 1752 0107 0d9e c206 2501 169f 6506 2601 169f 0x7623 0000 bfc0 86a0 8e06
0x0f86 08a1 5b8d0700a15b0706b18f 1d01 24a0 c317 5201 1a31 311e 0x24a0 b802 0101 0102 0100 0100 1752 0107a04e 1e1d6524f822 2501 0x0ea0 4602 13a0 4703 2713 2501 2416 9fcd 1d66 24e1 1752 03a0 639f 0xb808 0812 0306 12b1 8312 5203 210e a046 0106 2350 0e28 6713 a047 0x0327 1351; 5024 2251 5016 9fa8 1e24 9fb1 0401 0101 0102 0103 0201 0×0101 0d03 0007 0517 520d 0d06 061d0826f706 1253 1351 5011 1351 0×5224 2251 5206 1250 1225 0154 169f6617 5201 9fdb 070f 1c00 009e 0xce16 9f57 1d01 24fa1752 0107 0d9e c206 2501 169f6506 2601 169f0x7623 0000bfc0 86a0 8e06
A.2. Adapted Algorithms
A.2。 適合しているアルゴリズム
A.2.1. Modified DEFLATE
A.2.1。 変更されて、空気を抜いてください。
0x0f86 04a1 d38d 00a1 d31e 20a1 4010 0500 0b2e 000c 0c88 011a 20a1 0x0101 a042 a044 2000 a045 a05e a061 00a0 5fa0 66a1 0800 a067 a067 0xa1ff 02a1 a0a1 aa23 00a1 aba1 d13a 00a1 d2a1 e1a1 1001 a3c4 a3e3 0xa120 03bf 20bf 34a0 7b00 bf35 bfb3 a180 0180 3f68 803f 8700 0080 0x3f88 803f c7a1 4001 807f 9080 7fff a090 1750 88a0 79a0 83a0 831e 0x20a0 c810 0400 00a1 ff01 0209 8801 1416 2000 171e a108 013e a049 0x2e00 a04a a059 a110 02a1 68a1 81a0 6100 a182 a1a1 a120 01a3 44a3 0x6a3a 00a3 6ba3 aaa1 4001 a756 a760 2300 a761 a7df a180 01af c0af 0xd4a0 7b01 bfaa bfc9 0001 803f 9480 3ffb a090 0180 7ff8 807f ffa0 0xf817 5088 0610 1022 2101 1321 0123 169f 1107 10a0 fd1e 229f d909 0x0900 0709 0008 3fa0 8101 87a0 8701 00a0 88a0 f711 00a0 f8a1 3fa0 0xb901 a280 a57f a101 02b6 00b9 ffa4 0101 8034 0080 3bff a801 0290 0x00ff b001 0e24 6314 5150 2322 5250 169f 3b23 0000 bfc0 86a0 8906
0x0f86 04a1 d38d 00a1 d31e 20a1 4010 0500 0b2e 000c 0c88 011a 20a1 0×0101a042 a044 2000a045 a05e a061 00a0 5fa0 66a1 0800a067 a067 0xa1ff 02a1 a0a1 aa23 00a1 aba1 d13a 00a1 d2a1 e1a1 1001a3c4 a3e3 0xa120 03bf 20bf 34a0 7b00 bf35 bfb3 a180 0180 3f68 803f8700 0080 0x3f88 803f c7a1 4001 807f9080 7fff a090 1750 88a0 79a0 83a0 831e 0x20a0 c810 0400 00a1 ff01 0209 8801 1416 2000 171e a108 013e a049 0x2e00a04a a059 a110 02a1 68a1; 81a0 6100a182 a1a1 a120 01a3 44a3 0x6a3a 00a3 6ba3 aaa1 4001a756 a760 2300a761 a7df a180 01af c0af 0xd4a0 7b01 bfaa bfc9 0001 803f9480 3ffb a090 0180 7ff8 807f ffa0 0xf817 5088 0610 1022 2101 1321 0123 169f 1107 10a0 fd1e 229f d909 0×0900 0709 0008 3fa0 8101 87a0 8701 00a0 88a0 f711 00a0f8a1 3fa0 0xb901 a280 a57f a101 02b6 00b9 ffa4 0101 8034 0080 3bff a801 0290 0x00ff b001 0e24 6314 5150 2322 5250 169f 3b23 0000 bfc0 86a0 8906
Surtees & West Informational [Page 41] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[41ページ]のRFC4464SigCompユーザのガイド2006年5月
Authors' Addresses
作者のアドレス
Abigail Surtees Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK
アビゲールサーティーズシーメンス/Roke Manor Research Roke荘園研究株式会社ロムジー、Hants SO51 0ZNイギリス
Phone: +44 (0)1794 833131 EMail: abigail.surtees@roke.co.uk URI: http://www.roke.co.uk
以下に電話をしてください。 +44 (0) 1794 833131はメールされます: abigail.surtees@roke.co.uk ユリ: http://www.roke.co.uk
Mark A. West Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK
マーク・A.の西シーメンス/Roke Manor Research Roke荘園研究株式会社ロムジー、Hants SO51 0ZNイギリス
Phone: +44 (0)1794 833311 EMail: mark.a.west@roke.co.uk URI: http://www.roke.co.uk
以下に電話をしてください。 +44 (0) 1794 833311はメールされます: mark.a.west@roke.co.uk ユリ: http://www.roke.co.uk
Surtees & West Informational [Page 42] RFC 4464 SigComp Users' Guide May 2006
サーティーズと西情報[42ページ]のRFC4464SigCompユーザのガイド2006年5月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Surtees & West Informational [Page 43]
サーティーズと西洋情報です。[43ページ]
一覧
スポンサーリンク
