Repo Protocol Specification » History » Version 67
Shuo Chen, 02/24/2014 03:00 PM
| 1 | 1 | Shuo Chen | Repo Protocol Specification |
|---|---|---|---|
| 2 | =========================== |
||
| 3 | |||
| 4 | 36 | Shuo Chen | A Repo supports the network by preserving content and responding to Interests requesting content that it holds. A Repo can exist in any node, and is recommended if applications in that node need to preserve data. The NDN repo protocol is a specification of repo operations including reading, insertion and deletion of data objects in repo. |
| 5 | 2 | Shuo Chen | |
| 6 | Repo semantics is based on [Command Interests](http://redmine.named-data.net/projects/nfd/wiki/Command_Interests) with signed commponents an the end of the name and basic common semantics of NDN. |
||
| 7 | |||
| 8 | 11 | Shuo Chen | When some operation of repo including insertion and deletion of data objects is requested, a command interest is sent. The command interest is the interest as command of insertion and deletion and signed as form of command interest for access control. The repo will response the command with the data object. |
| 9 | 4 | Shuo Chen | |
| 10 | The repo protocol can be categorized in three sections of reading, insertion and deletion of data objects. |
||
| 11 | |||
| 12 | ## Repo Reading Specification |
||
| 13 | |||
| 14 | 36 | Shuo Chen | Repo registers prefixes of data objects it holds into NDN fowarding deamon and the repo will respond the data with such prefixes. |
| 15 | 6 | Shuo Chen | |
| 16 | 11 | Shuo Chen | A standard interest is used to fetch content from the repo. The repo will respond when the name of the interest matches the prefix it registered in NFD. If the content in repo matches the interests, it will respond with the data object. When the interest is not matched, it will not respond. |
| 17 | 6 | Shuo Chen | |
| 18 | The protocol is listed as bellow |
||
| 19 | |||
| 20 | If there is a matching data object: |
||
| 21 | |||
| 22 | 7 | Shuo Chen | Requester Repo |
| 23 | | | |
||
| 24 | | | |
||
| 25 | | Interest | |
||
| 26 | t1 |-------------------------->| |
||
| 27 | | | |
||
| 28 | | Data Object | |
||
| 29 | t2 |<==========================| |
||
| 30 | 1 | Shuo Chen | | | |
| 31 | 7 | Shuo Chen | | | |
| 32 | 1 | Shuo Chen | | | |
| 33 | 7 | Shuo Chen | |
| 34 | If there is no matching data object: |
||
| 35 | 6 | Shuo Chen | |
| 36 | Requester Repo |
||
| 37 | | | |
||
| 38 | 1 | Shuo Chen | | | |
| 39 | 7 | Shuo Chen | | Interest | |
| 40 | t1 |-------------------------->| |
||
| 41 | | | |
||
| 42 | | | |
||
| 43 | | | |
||
| 44 | |||
| 45 | 30 | Shuo Chen | ## Repo Command |
| 46 | For insertion, deletion and other operations of repo, these commands are encoded in the form of [sigend command interest](http://redmine.named-data.net/projects/nfd/wiki/Command_Interests). The semantics of repo command interest is as follows: |
||
| 47 | 14 | Shuo Chen | |
| 48 | 8 | Shuo Chen | The name semantics is defined to have following components: |
| 49 | 1 | Shuo Chen | |
| 50 | 17 | Shuo Chen | * ``<name of repo>`` refers to specific name of repo |
| 51 | 30 | Shuo Chen | * ``<command verb>`` refers to the name of command |
| 52 | * ``<RepoCommandParameters>`` refers to parameters of repo command |
||
| 53 | 1 | Shuo Chen | |
| 54 | 38 | Shuo Chen | The following components are components of singed interest for access control: |
| 55 | 1 | Shuo Chen | |
| 56 | * ``<timestamp>`` |
||
| 57 | 8 | Shuo Chen | * ``<random-value>`` |
| 58 | * ``<SignatureInfo>`` |
||
| 59 | * ``<SignatureValue>`` |
||
| 60 | |||
| 61 | 30 | Shuo Chen | For name of the repo /ucla/cs/repo/, the command will be defined as this: |
| 62 | 33 | Shuo Chen | |
| 63 | 30 | Shuo Chen | /ucla/cs/repo/<command verb>/<RepoCommandParameters>/<timestamp>/<random-value>/<SignatureInfo>/<SignatureValue> |
| 64 | 14 | Shuo Chen | |
| 65 | 30 | Shuo Chen | ### RepoCommandParameters |
| 66 | 29 | Shuo Chen | |
| 67 | 48 | Shuo Chen | RepoCommandParameters ::= REPOCOMMANDPARAMETERS-TYPE TLV-LENGTH |
| 68 | 1 | Shuo Chen | Name? |
| 69 | 42 | Shuo Chen | Selectors? |
| 70 | 1 | Shuo Chen | StartBlockId? |
| 71 | EndBlockId? |
||
| 72 | 62 | Shuo Chen | ProcessId? |
| 73 | 29 | Shuo Chen | |
| 74 | 48 | Shuo Chen | Name ::= NAME-TYPE TLV-LENGTH NameComponent* |
| 75 | NameComponent ::= NAME-COMPONENT-TYPE TLV-LENGTH BYTE+ |
||
| 76 | 43 | Shuo Chen | |
| 77 | Selectors ::= SELECTORS-TYPE TLV-LENGTH |
||
| 78 | MinSuffixComponents? |
||
| 79 | MaxSuffixComponents? |
||
| 80 | PublisherPublicKeyLocator? |
||
| 81 | Exclude? |
||
| 82 | 47 | Shuo Chen | ChildSelector? |
| 83 | 43 | Shuo Chen | |
| 84 | MinSuffixComponents ::= MIN-SUFFIX-COMPONENTS-TYPE TLV-LENGTH |
||
| 85 | nonNegativeInteger |
||
| 86 | |||
| 87 | MaxSuffixComponents ::= MAX-SUFFIX-COMPONENTS-TYPE TLV-LENGTH |
||
| 88 | nonNegativeInteger |
||
| 89 | |||
| 90 | PublisherPublicKeyLocator ::= KeyLocator |
||
| 91 | |||
| 92 | Exclude ::= EXCLUDE-TYPE TLV-LENGTH Any? (NameComponent (Any)?)+ |
||
| 93 | Any ::= ANY-TYPE TLV-LENGTH(=0) |
||
| 94 | 47 | Shuo Chen | |
| 95 | ChildSelector ::= CHILD-SELECTOR-TYPE TLV-LENGTH |
||
| 96 | nonNegativeInteger |
||
| 97 | 1 | Shuo Chen | |
| 98 | StartBlockId ::= STARTBLOCKID-TYPE TLV-LENGTH |
||
| 99 | 49 | Shuo Chen | nonNegativeInteger |
| 100 | 1 | Shuo Chen | |
| 101 | EndBlockId ::= ENDBLOCKID-TYPE TLV-LENGTH |
||
| 102 | 49 | Shuo Chen | nonNegativeInteger |
| 103 | 1 | Shuo Chen | |
| 104 | 62 | Shuo Chen | ProcessId ::= PROCESSID-TYPE TLV-LENGTH |
| 105 | nonNegativeInteger |
||
| 106 | |||
| 107 | 45 | Shuo Chen | #### Name |
| 108 | |||
| 109 | 50 | Shuo Chen | Name in command parameter is TLV-encoded block and represents the name or prefix of the data repo will process. The definition and format of name section are the same as the [name section](http://named-data.net/doc/ndn-tlv/name.html#name) of NDN interest. |
| 110 | 45 | Shuo Chen | |
| 111 | 44 | Shuo Chen | #### Repo Command Selectors |
| 112 | 38 | Shuo Chen | |
| 113 | 52 | Shuo Chen | Repo command supports parts of interest selectors of interest to indicate which contents to process. The definition of standard NDN selectors is described in [NDN Selectors Doc](http://named-data.net/doc/ndn-tlv/interest.html#selectors). The concrete definitions of both standard NDN selectors and repo command selectors are the same. |
| 114 | |||
| 115 | The difference between standard NDN interest and Repo Deletion Command interest that, the standard NDN selectors just matches **one** data packet that conforms to the selector conditions, but repo command selectors would matches **any** data packets. For example, if Interest is expressed for /ndn/edu and Exclude specifies one name component ucla, in standard NDN interest, the data producers will first exclude all the data packets with prefix /ndn/edu but not /ndn/edu/ucla, and then just selects one data packet. In repo deletion command interest, it will select all the data packets with prefix /ndn/edu but not /ndn/edu/ucla. However, in repo insert command, the repo will fetch one data just like standard interest selectors. |
||
| 116 | 38 | Shuo Chen | |
| 117 | 51 | Shuo Chen | Repo command supports parts of standard NDN interests including MinSuffixComponents, MaxSuffixComponents, PublisherPublicKeyLocator, Exclude, ChildSelector. If command contains other selectors, repo will ignore these not supported selectors. In addition, selectors are just supported in delete command. If other commands contains selectors, repo will ignore selectors when processing these commands. |
| 118 | 38 | Shuo Chen | |
| 119 | The form of selectors is as follows: |
||
| 120 | |||
| 121 | Selectors ::= SELECTORS-TYPE TLV-LENGTH |
||
| 122 | MinSuffixComponents? |
||
| 123 | MaxSuffixComponents? |
||
| 124 | PublisherPublicKeyLocator? |
||
| 125 | 1 | Shuo Chen | Exclude? |
| 126 | 51 | Shuo Chen | ChildSelector? |
| 127 | 38 | Shuo Chen | |
| 128 | MinSuffixComponents ::= MIN-SUFFIX-COMPONENTS-TYPE TLV-LENGTH |
||
| 129 | nonNegativeInteger |
||
| 130 | |||
| 131 | MaxSuffixComponents ::= MAX-SUFFIX-COMPONENTS-TYPE TLV-LENGTH |
||
| 132 | nonNegativeInteger |
||
| 133 | |||
| 134 | PublisherPublicKeyLocator ::= KeyLocator |
||
| 135 | |||
| 136 | Exclude ::= EXCLUDE-TYPE TLV-LENGTH Any? (NameComponent (Any)?)+ |
||
| 137 | 1 | Shuo Chen | Any ::= ANY-TYPE TLV-LENGTH(=0) |
| 138 | 51 | Shuo Chen | |
| 139 | ChildSelector ::= CHILD-SELECTOR-TYPE TLV-LENGTH |
||
| 140 | nonNegativeInteger |
||
| 141 | 46 | Shuo Chen | |
| 142 | #### StartBlockId, EndBlockId |
||
| 143 | 38 | Shuo Chen | |
| 144 | 54 | Shuo Chen | StartBlockId and EndBlockId are used to process segmented data. StartBlockId indicate the first segment number and EndBlockId indicate the last segment number. Repo will process segment data whose segment id between StartBlockId and EndBlockId. If StartBlockId is missing, the first segment id the repo process is 0; If EndBlockId is missing, this scenario is described in specific process in Repo Insertion Command section and Repo Deletion Command section. |
| 145 | 62 | Shuo Chen | |
| 146 | 67 | Shuo Chen | #### Conflicts of Selectors and StartBlockId, EndBlockId |
| 147 | |||
| 148 | Repo cannot process command with both selectors and StartBlockId, EndBlockId in RepoCommandParameter. If the RepoCommandParameter carries both, repo will ignore this command interest and return with error code of 405. |
||
| 149 | |||
| 150 | 62 | Shuo Chen | #### ProcessId |
| 151 | 53 | Shuo Chen | |
| 152 | 63 | Shuo Chen | ProcessId is used by insertion and deletion check command to indicate specific insertion and deletion process. The ProcessId is fetched by repo command response of insertion and deletion command. |
| 153 | |||
| 154 | 30 | Shuo Chen | ## Repo Command Response |
| 155 | 1 | Shuo Chen | |
| 156 | 30 | Shuo Chen | Repo command response is the response data packet of repo command interest. The response contains statuscode to indicate the status of command process and other information. A TLV-encoded block called ``RepoCommandResponse`` is encoded in content of the data packet. |
| 157 | 1 | Shuo Chen | |
| 158 | 30 | Shuo Chen | RepoCommandResponse ::= INSERTSTATUS-TYPE TLV-LENGTH |
| 159 | 61 | Shuo Chen | ProcessId? |
| 160 | 1 | Shuo Chen | StatusCode? |
| 161 | StartBlockId? |
||
| 162 | EndBlockId? |
||
| 163 | InsertNum? |
||
| 164 | 30 | Shuo Chen | DeleteNum? |
| 165 | 1 | Shuo Chen | |
| 166 | 61 | Shuo Chen | ProcessId ::= PROCESSID-TYPE TLV-LENGTH |
| 167 | 55 | Shuo Chen | nonNegativeInteger |
| 168 | |||
| 169 | 1 | Shuo Chen | StatusCode ::= STATUSCODE-TYPE TLV-LENGTH |
| 170 | nonNegativeInteger |
||
| 171 | |||
| 172 | StartBlockId ::= STARTBLOCKID-TYPE TLV-LENGTH |
||
| 173 | nonNegativeInteger |
||
| 174 | |||
| 175 | EndBlockId ::= ENDBLOCKID-TYPE TLV-LENGTH |
||
| 176 | nonNegativeInteger |
||
| 177 | 17 | Shuo Chen | |
| 178 | InsertNum ::= INSERTNUM-TYPE TLV-LENGTH |
||
| 179 | nonNegativeInteger |
||
| 180 | |||
| 181 | 30 | Shuo Chen | DeleteNum ::= DELETENUM-TYPE TLV-LENGTH |
| 182 | nonNegativeInteger |
||
| 183 | 17 | Shuo Chen | |
| 184 | 61 | Shuo Chen | ### ProcessId |
| 185 | ProcessId is a random number generated by repo to indicate the number of the command process. Client could use this ProcessId to check the status of specific command. |
||
| 186 | 59 | Shuo Chen | |
| 187 | ### StatusCode |
||
| 188 | |||
| 189 | 64 | Shuo Chen | StatusCode indicates the status of repo command process. The statuscodes of insert and deletion command are described in following insertion and deletion specification. |
| 190 | |||
| 191 | 59 | Shuo Chen | ### StartBlockId, EndBlockId |
| 192 | |||
| 193 | 65 | Shuo Chen | StartBlockId and EndBlockId are the same as those of RepoCommandParameter. If either of those in RepoCommandParameter is missing, repo will set them as the Id known for now. For example, if StartBlockId is missing in RepoCommandParameter, StartBlockId in response will be set 0. If EndBlockId is missing in RepoCommandParameter, EndBlockId will be set null untill Repo get FinalBlockId in data packet. If FinalBlockId in returned data packet is less than EndBlockId, the EndBlockId will be set FinalBlockId. |
| 194 | |||
| 195 | 59 | Shuo Chen | ### InsertNum, DeleteNum |
| 196 | 66 | Shuo Chen | InsertNum is used in reponse of insertion status check to indicate how many data packets have been successfully inserted into the repo. DeleteNum is used in response of deletion command and deletion check command. DeleteNum indicates how many data packets have been successfully inserted from repo. |
| 197 | 59 | Shuo Chen | |
| 198 | 58 | Shuo Chen | ## Repo Trust Model |
| 199 | 57 | Shuo Chen | |
| 200 | The trust model of repo depends on people who deploy the repo service, such as PKI. Repo can specify their own verification policies, and data consumers can specify their own trust anchors. The NDN [FAQ](http://named-data.net/project/faq/#How_does_NDN8217s_8220trust_management8221_work) shows how NDN trust managment works. |
||
| 201 | |||
| 202 | 30 | Shuo Chen | ## Repo Insertion Specification |
| 203 | |||
| 204 | Insertion specification is for some client and application to insert data objects into certain NDN repo. A command interest as insertion command will be sent to the repo. This command interest is a signed interest and will be validated with access control policy defined by the repo. When the interested is validated and name of the data is not existed in the repo. The repository will reponse with a data object containing OK status and start to send the interest to fetch the data to insert. |
||
| 205 | |||
| 206 | Segmented data insertion is also supported in the insertion protocol. Segmantation info is defined as a TLV-encoded SegmantationInfo block. If the content is segmented, the final segment id will be encoded in this block. |
||
| 207 | |||
| 208 | ### Insertion command interest semantics |
||
| 209 | |||
| 210 | The name semantics is follows the format of the repo command. The <command verb> is defined as ``insert``. |
||
| 211 | For example, for ``<name of repo>`` as ``/ucla/cs/repo``, the following is an example: |
||
| 212 | 1 | Shuo Chen | |
| 213 | 31 | Shuo Chen | /ucla/cs/repo/insert/<RepoCommandParameters>/<timestamp>/<random-value>/<SignatureInfo>/<SignatureValue> |
| 214 | 30 | Shuo Chen | |
| 215 | ### Insertion status check |
||
| 216 | |||
| 217 | During the insertion progress, the requester could send insertion status check command to check the status of the insertion progress. This status check command is also signed interest. The semantics of insertion status check command is shown as follows: |
||
| 218 | |||
| 219 | <command verb> equals to ``insert check``. For example: |
||
| 220 | 1 | Shuo Chen | |
| 221 | 32 | Shuo Chen | /ucla/cs/repo/insert check/<RepoCommandParameters>/<timestamp>/<random-value>/<SignatureInfo>/<SignatureValue> |
| 222 | 30 | Shuo Chen | |
| 223 | 40 | Shuo Chen | ### Insert and Insert check command seletors |
| 224 | |||
| 225 | Selectors are not supported in these commands. Repo will ignore selectors when processing these commands. |
||
| 226 | |||
| 227 | 30 | Shuo Chen | ### Insertatation status response |
| 228 | |||
| 229 | This insert status data object could be the response data object of both insert command and insert check command. It will follow the format of repo command response. |
||
| 230 | |||
| 231 | StatusCode indicates the status of insertion. InsertNum represents how many data has been intersted into the repo. StartBlockId and EndBlockId is the start and end segment id of data inserted. InsertNum is the how many data segments have been inserted. |
||
| 232 | |||
| 233 | For insert cammand, status code will be set according to definition below, StartBlockId and EndBlockId will be set according to the insert command. |
||
| 234 | |||
| 235 | For insert check command, status code will be set according to definition below, StartBlockId and EndBlockId will be set according to the insert command, insertnum will be set according to insertion progress. |
||
| 236 | |||
| 237 | 1 | Shuo Chen | StatusCode Definition: |
| 238 | 17 | Shuo Chen | |
| 239 | ``StatusCode`` | Description |
||
| 240 | -------------- | ---------------------------------------------- |
||
| 241 | 19 | Shuo Chen | ``100`` | The command is OK. can start to fetch the data |
| 242 | ``200`` | All the data has been inserted |
||
| 243 | 17 | Shuo Chen | ``300`` | This insertion is in progress |
| 244 | ``401`` | This insertion check is invalidated |
||
| 245 | ``404`` | No such this insertion is in progress |
||
| 246 | 30 | Shuo Chen | ``505`` | status check command is not supported |
| 247 | 17 | Shuo Chen | |
| 248 | 22 | Alex Afanasyev | ### Protocol Process |
| 249 | |||
| 250 | 20 | Alex Afanasyev | 1. start to authorize the command; if authorization does not fail immediately, go to step 3 |
| 251 | 17 | Shuo Chen | |
| 252 | 20 | Alex Afanasyev | 2. send a negative response indicating authorization failure, and abort these steps |
| 253 | 14 | Shuo Chen | |
| 254 | 20 | Alex Afanasyev | 3. if both StartBlockId and EndBlockId are missing, go to step 6 |
| 255 | 14 | Shuo Chen | |
| 256 | 20 | Alex Afanasyev | 4. if both StartBlockId and EndBlockId are present, and StartBlockId is less than or equal to EndBlockId, go to step 6 |
| 257 | 14 | Shuo Chen | |
| 258 | 20 | Alex Afanasyev | 5. send a negative response indicating malformed command, and abort these steps |
| 259 | 14 | Shuo Chen | |
| 260 | 20 | Alex Afanasyev | 6. wait for authorization completion |
| 261 | 14 | Shuo Chen | |
| 262 | 20 | Alex Afanasyev | 7. if authorization fails, go to step 2 |
| 263 | 14 | Shuo Chen | |
| 264 | 20 | Alex Afanasyev | 8. send a positive response indicating insert is in progress |
| 265 | 14 | Shuo Chen | |
| 266 | 20 | Alex Afanasyev | 9. if both StartBlockId and EndBlockId are present, go to step 15 |
| 267 | 14 | Shuo Chen | |
| 268 | 20 | Alex Afanasyev | 10. start to retrieve Name |
| 269 | 14 | Shuo Chen | |
| 270 | 20 | Alex Afanasyev | 11. wait for retrieval completion |
| 271 | 14 | Shuo Chen | |
| 272 | 20 | Alex Afanasyev | 12. if retrieval fails, abort these steps |
| 273 | 14 | Shuo Chen | |
| 274 | 20 | Alex Afanasyev | 13. store retrieved Data packet |
| 275 | 14 | Shuo Chen | |
| 276 | 20 | Alex Afanasyev | 14. abort these steps |
| 277 | 14 | Shuo Chen | |
| 278 | 20 | Alex Afanasyev | 15. append StartBlockId to Name |
| 279 | 1 | Shuo Chen | |
| 280 | 20 | Alex Afanasyev | 16. start to retrieve Name |
| 281 | 14 | Shuo Chen | |
| 282 | 20 | Alex Afanasyev | 17. wait for retrieval completion |
| 283 | 14 | Shuo Chen | |
| 284 | 20 | Alex Afanasyev | 18. if retrieval fails, abort these steps |
| 285 | 14 | Shuo Chen | |
| 286 | 20 | Alex Afanasyev | 19. store retrieved Data packet |
| 287 | 15 | Shuo Chen | |
| 288 | 20 | Alex Afanasyev | 20. if retrieved Data packet contains FinalBlockId, and FinalBlockId is less than EndBlockId, let EndBlockId be FinalBlockId |
| 289 | 15 | Shuo Chen | |
| 290 | 20 | Alex Afanasyev | 21. if the last component of Name is greater than or equal to EndBlockId, abort these steps |
| 291 | 15 | Shuo Chen | |
| 292 | 20 | Alex Afanasyev | 22. increment the last component of Name |
| 293 | 15 | Shuo Chen | |
| 294 | 20 | Alex Afanasyev | 23. go to step 16 |
| 295 | 15 | Shuo Chen | |
| 296 | 20 | Alex Afanasyev | Implementation MAY pipeline the Interests. |
| 297 | 1 | Shuo Chen | |
| 298 | 20 | Alex Afanasyev | ### Repo command progress report |
| 299 | 16 | Shuo Chen | |
| 300 | 20 | Alex Afanasyev | Implementation MAY publish a notification of status regarding insert progress. The process of status check is as follows: |
| 301 | 18 | Shuo Chen | |
| 302 | 20 | Alex Afanasyev | 1. start to authorize the insert status command |
| 303 | 1 | Shuo Chen | |
| 304 | 20 | Alex Afanasyev | 2. send a negative response indicating authorization failure, and abort these steps |
| 305 | 18 | Shuo Chen | |
| 306 | 20 | Alex Afanasyev | 3. start to check the progress of the insert with the data name in the command. If no such progress is found, go to 4. or go to 5. |
| 307 | 18 | Shuo Chen | |
| 308 | 20 | Alex Afanasyev | 4. reponse status with status code of 404 |
| 309 | 18 | Shuo Chen | |
| 310 | 20 | Alex Afanasyev | 5. ckeck te status of insertion. return the status data content |
| 311 | |||
| 312 | 17 | Shuo Chen | ### Protocol diagram: |
| 313 | 10 | Alex Afanasyev | |
| 314 | Requester Repo Data producer |
||
| 315 | | | | |
||
| 316 | | | | |
||
| 317 | +---+ Insert command +---+ | |
||
| 318 | | | --------------------> | | | |
||
| 319 | +---+ | | | |
||
| 320 | | | | | |
||
| 321 | +---+ Confirm start | | | |
||
| 322 | | | <==================== | | | |
||
| 323 | +---+ Reject command +---+ | |
||
| 324 | | (with status code) | | |
||
| 325 | | +---+ Interest for Data +---+ |
||
| 326 | 1 | Shuo Chen | | | | --------------------------> | | |
| 327 | | +---+ | | |
||
| 328 | 10 | Alex Afanasyev | | | | | |
| 329 | | +---+ Data segment | | |
||
| 330 | | | | <========================== | | |
||
| 331 | | +---+ +---+ |
||
| 332 | | | | |
||
| 333 | | ~ ~ |
||
| 334 | | ~ ~ |
||
| 335 | | | | |
||
| 336 | | +---+ Interest for Data +---+ |
||
| 337 | | | | --------------------------> | | |
||
| 338 | | +---+ | | |
||
| 339 | 1 | Shuo Chen | | | | | |
| 340 | | +---+ Data segment | | |
||
| 341 | | | | <========================== | | |
||
| 342 | | +---+ +---+ |
||
| 343 | | | | |
||
| 344 | | | | |
||
| 345 | 17 | Shuo Chen | | ~ ~ |
| 346 | 1 | Shuo Chen | | ~ ~ |
| 347 | | | | |
||
| 348 | 30 | Shuo Chen | | | | |
| 349 | 19 | Shuo Chen | | | | |
| 350 | 30 | Shuo Chen | +---+ Status interest +---+ | |
| 351 | 19 | Shuo Chen | | | --------------------> | | | |
| 352 | +---+ | | | |
||
| 353 | | | | | |
||
| 354 | +---+ Status response | | | |
||
| 355 | | | <==================== | | | |
||
| 356 | +---+ +---+ | |
||
| 357 | | | | |
||
| 358 | | | | |
||
| 359 | |||
| 360 | ## Repo Deletion Specification |
||
| 361 | |||
| 362 | Deletion of one content object or content objects under certain prefix are both supported in repo specification. Selectors are used to select multiple content objects. These selectors are different from conventional [selectors](http://named-data.net/doc/ndn-tlv/interest.html#selectors) of interest packet. The conventional selecors of interest would select one data packet of repo. Selecors of delete command will return any data packets which applies for these selectors. |
||
| 363 | |||
| 364 | ### Deletion command interest semantics |
||
| 365 | |||
| 366 | 1 | Shuo Chen | Deletion command interest follows the format of the repo command. For example: |
| 367 | 19 | Shuo Chen | |
| 368 | /ucla/cs/repo/delete/<RepoCommandParameters>/<timestamp>/<random-value>/<SignatureInfo>/<SignatureValue> |
||
| 369 | |||
| 370 | ### Deletion Command Selectors |
||
| 371 | |||
| 372 | 39 | Shuo Chen | Deletion command selectors follows the [repo command selectors](http://redmine.named-data.net/projects/repo-ng/wiki/Repo_Protocol_Specification#Repo-Command-Selectors). |
| 373 | |||
| 374 | 19 | Shuo Chen | ### Deletion status check |
| 375 | |||
| 376 | 30 | Shuo Chen | During the deletion progress, the requester could send deletion status check command to check the status of the deletion progress. This status check command is also signed interest. The semantics of deletion status check command follows the format of repo command. ``<command verb>`` equals to ``delete check``. For example: |
| 377 | 1 | Shuo Chen | |
| 378 | 34 | Shuo Chen | /ucla/cs/repo/delete/<RepoCommandParameters>/<timestamp>/<random-value>/<SignatureInfo>/<SignatureValue> |
| 379 | 19 | Shuo Chen | |
| 380 | 41 | Shuo Chen | ### Deletion Check Command Selectors |
| 381 | |||
| 382 | Selectors are not supported. Repo will ignore selectors when processing deletion status check command. |
||
| 383 | |||
| 384 | 19 | Shuo Chen | ### Deletion status response |
| 385 | |||
| 386 | 30 | Shuo Chen | This delete status data object could be the response data packet of both delete command and delete check command. The name of data packet is the same as that of command.The deletion status is enocoded as a TLV echoded block in content block in data packet. The TLV block format follows RepoCommandResponse. |
| 387 | 19 | Shuo Chen | |
| 388 | StatusCode indicates the status of deletion. DeleteSum is the sum of the deletion. DeleteNum represents how many data has been deleted. |
||
| 389 | |||
| 390 | StatusCode Definition: |
||
| 391 | |||
| 392 | ``StatusCode`` | Description |
||
| 393 | -------------- | -------------------------------------- |
||
| 394 | ``200`` | All the data has been deleted |
||
| 395 | ``300`` | This deletion is in progress |
||
| 396 | ``401`` | This deletion check is invalidated |
||
| 397 | ``404`` | No such this deletion is in progress |
||
| 398 | 30 | Shuo Chen | ``505`` | status check command is not supported |
| 399 | 19 | Shuo Chen | |
| 400 | 17 | Shuo Chen | ### Protocol process |
| 401 | 1 | Shuo Chen | |
| 402 | 21 | Alex Afanasyev | 1. start to authorize the command; if authorization does not fail immediately, go to step 3 |
| 403 | 1 | Shuo Chen | |
| 404 | 21 | Alex Afanasyev | 2. send a negative response indicating authorization failure, and abort these steps |
| 405 | 1 | Shuo Chen | |
| 406 | 21 | Alex Afanasyev | 3. check whether selectors are presented. If selectors are presented, go to step 4, or select the data packet of the exact name of command. If some data is selected, go to step 6. If no data selected, go to step 5 |
| 407 | 1 | Shuo Chen | |
| 408 | 21 | Alex Afanasyev | 4. select all the data packets that comforms to data name of the command and the selectors. If some data packets are selected, go to step 6. Or no data selected, go to step 5. |
| 409 | 1 | Shuo Chen | |
| 410 | 21 | Alex Afanasyev | 5. send a negative response and abort the delete transaction. |
| 411 | 1 | Shuo Chen | |
| 412 | 21 | Alex Afanasyev | 6. wait for authorization completion |
| 413 | 1 | Shuo Chen | |
| 414 | 21 | Alex Afanasyev | 7. if authorization fails, go to step 2 |
| 415 | 1 | Shuo Chen | |
| 416 | 21 | Alex Afanasyev | 8. start to delete the selected data. If deletion success, return positive reponse, or return negative response and abort the deletion. |
| 417 | 19 | Shuo Chen | |
| 418 | 21 | Alex Afanasyev | Implementation MAY publish a notification of status regarding delete progress. The process of status check is as follows: |
| 419 | 19 | Shuo Chen | |
| 420 | 21 | Alex Afanasyev | 1. start to authorize the delete status command |
| 421 | 19 | Shuo Chen | |
| 422 | 21 | Alex Afanasyev | 2. send a negative response indicating authorization failure, and abort these steps |
| 423 | 19 | Shuo Chen | |
| 424 | 21 | Alex Afanasyev | 3. start to check the progress of the delete with the data name in the command. If no such progress is found, go to 4. or go to 5. |
| 425 | 19 | Shuo Chen | |
| 426 | 21 | Alex Afanasyev | 4. reponse status with status code of 404 |
| 427 | |||
| 428 | 5. ckeck te status of delete. return the status data content |
||
| 429 | 19 | Shuo Chen | |
| 430 | ### Protocol diagram: |
||
| 431 | |||
| 432 | Requester Repo |
||
| 433 | | | |
||
| 434 | | | |
||
| 435 | +---+ Delete command +---+ |
||
| 436 | | | --------------------> | | |
||
| 437 | +---+ +---+ |
||
| 438 | | | |
||
| 439 | | | |
||
| 440 | | | |
||
| 441 | +---+ Status interest +---+ |
||
| 442 | | | --------------------> | | |
||
| 443 | +---+ | | |
||
| 444 | | | | |
||
| 445 | +---+ Status response | | |
||
| 446 | | | <==================== | | |
||
| 447 | +---+ +---+ |
||
| 448 | | | |
||
| 449 | | | |
||
| 450 | | | |
||
| 451 | +---+ Confirm Deletion +---+ |
||
| 452 | | | <==================== | | |
||
| 453 | +---+ Reject command +---+ |
||
| 454 | | (with status code) | |
||
| 455 | 20 | Alex Afanasyev | | | |