Repo Deletion Protocol » History » Revision 5
Revision 4 (weijia yuan, 02/02/2018 04:03 PM) → Revision 5/13 (weijia yuan, 02/03/2018 04:58 PM)
Repo Deletion Protocol ====================== Repo deletion protocol uses [[Repo Command]]. Deletion of one content object or content objects under certain prefix are both supported in repo specification. Filters are used to select multiple content objects. These filters are different from conventional [selectors](http://named-data.net/doc/ndn-tlv/interest.html#filters) [filters](http://named-data.net/doc/ndn-tlv/interest.html#filters) of interest packet. The conventional selecors of interest would select one data packet of repo. Filters of delete command will return any data packets which applies for these filters. Deletion of segmented data is also supported. ## Basic operations ### Deletion command interest semantics Command verb: **delete** Deletion command interest follows the format of the repo command. For example: /ucla/cs/repo/delete/<RepoCommandParameter>/<timestamp>/<random-value>/<SignatureInfo>/<SignatureValue ## Formats ### Deletion Command RepoCommandParameter Format of deletion command RepoCommandParameter follows that of Repo Command. Name, Filter, StartBlockId, EndBlockId, ProcessId are used to construct RepoCommandParameter. Name is the name or the prefix of data repo will delete.Filter delete. Filter is used to select data. ChildFilter is **not** supported in deletion command. StartBlockId and EndBlockId are used to delete segment data. Data of segment id between StartBlockId and EndBlockId will be deleted by repo. ProcessId is a random number generated by client to indicate the deletion process. Repo will match this ProcessId with this deletion process. ### Deletion status check 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: /ucla/cs/repo/delete/<RepoCommandParameter>/<timestamp>/<random-value>/<SignatureInfo>/<SignatureValue> ### Deletion status check RepoCommandParameter Name and ProcessId are used to indicate certain deletion process. Repo uses Name and ProcessId to match certain deletion process. If it matches, repo will respond progress of deletion. If just one of Name or ProcessId matches, it fails. ### Deletion Check Command Filters Filters are not supported. Repo will ignore filters when processing deletion status check command. ### Deletion status response Deletion status response is used as response of repo deletion command and repo deletion check command. Name, StatusCode, Filter, StartBlockId, EndBlockId, ProcessId, DeletenNum are used in deletion status response. Name, ProcessId, Filter is the same as that of delete command. StatusCode indicates the status of deletion. DeleteNum indicates how many data packets have been deleted. In Repo Deletion Command, if just StartBlockId presents, EndBlockId may be the largest segment ID repo holds. If just EndBlockId presents, StartBlockId will be set 0 StatusCode Definition: ``StatusCode`` | Description -------------- | -------------------------------------- ``200`` | All the data has been deleted ``300`` | This deletion is in progress ``401`` | This deletion or deletion check is invalidated ``402`` | Filters and BlockId both present ``403`` | Malformed Command ``404`` | No such this deletion is in progress ## Protocol process 1. start to authorize the command; if authorization does not fail, go to step 3 2. send a negative response indicating authorization failure, and abort these steps, end deletion process. (StatusCode: 401) 3. check whether a deletion process of same RepoCommandParameter exists, waiting for deletion process ends. 4. If filters and one of StartBlockId and EndBlockId presents, send a negative response and abort these steps, end deletion process. (StatusCode: 402) 5. If filters present, go to step 8 6. check whether StartBlockId or EndBlockId presents. If both presents but StartBlockId is larger than EndBlockId, return negative response and end deletion process. (StatusCode: 403) Or go to step 9 7. If StartBlockId, EndBlockId and filters are all missing, go to step 10 8. delete all the data that conforms to the name and filters, go to step 11 9. delete all the data packets of segment id between StartBlockId and EndBlockId. If StartBlockId is missing, StartBlockId is set to be 0. If EndBlockId is missing, EndBlockId is set to be the largest segment id that repo holds. go to step 11 10. delete all the data with prefix same as name. got to step 11 11. If lifetime of interest does not expire, return status response of positive statuscode. If lifetime of interest has expired, wait for interest the same RepoCommandParameter and return this status response. End Deletion process. (StatusCode: 200) Client will set deletion command with big lifetime. If life time expires, client will re-express the command. Implementation MAY publish a notification of status regarding delete progress. The process of status check is as follows: 1. start to authorize the delete status command 2. send a negative response indicating authorization failure, and abort these steps (StatusCode: 401) 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. 4. reponse status with status code of 404 (StatusCode: 404) 5. ckeck te status of delete. return the status data content (StatusCode: 300) ### Protocol diagram: Requester Repo | | | | +---+ Delete command +---+ | | --------------------> | | +---+ +---+ | | | | | | +---+ Status interest +---+ | | --------------------> | | +---+ | | | | | +---+ Status response | | | | <==================== | | +---+ +---+ | | | | | | +---+ Confirm Deletion +---+ | | <==================== | | +---+ Reject command +---+ | (with status code) | | |