search

UCLA-IRL / ndn-python-repo

An NDN Repo implementation in Python
Apache License 2.0
16 stars 13 forks source link

illogical register_prefix design #77

Open yoursunny opened 9 months ago

yoursunny commented 9 months ago

Environment:

With the repo configured as register_root=False, when a client inserts some Data packets with the same register_prefix value and deletes a subset of them, the prefix is unregistered even if the repo still contains other Data packets with that register_prefix value.

Packet trace: 2.pcap.zip

In this packet trace:

  1. Client inserts /R/0, /R/1, /R/2 with register_prefix=/R. The repo sends a prefix registration command for /R as expected.
  2. Client inserts /R/3, /R/4, /R/5 with register_prefix=/R.
  3. Client deletes /R/0, /R/1, /R/2 with register_prefix=/R. The repo sends a prefix unregistration command for /R, despite that it still has /R/3, /R/4, /R/5 Data packets.

ndn-python-repo console logs:

{'repo_config': {'repo_name': '/8=myrepo', 'register_root': False}, 'db_config': {'db_type': 'sqlite3', 'sqlite3': {'path': '/tmp/tmp-433614-WFnXhTzbi9W8/sqlite3.db'}}, 'tcp_bulk_insert': {'addr': '127.162.63.127', 'port': 7376, 'register_prefix': False}, 'logging_config': {'level': 'INFO'}}
[2024-02-08 16:46:38,917]INFO:TCP insertion handle serving on ('127.162.63.127', 7376)
[2024-02-08 16:46:38,922]INFO:Subscribing to topic (with interest filter): /myrepo/insert
[2024-02-08 16:46:38,922]INFO:Subscribing to topic (with interest filter): /myrepo/delete
[2024-02-08 16:46:39,153]INFO:received subscribed msg: /localhost/seq=3540218072/msg/myrepo/insert/%8C%7CC%CF%23%8D%60%F8
[2024-02-08 16:46:39,169]INFO:Recved insert command: 78e0872aba89d076ac5aab8a6432201c6533120ba79250434c9392119e3d78db
[2024-02-08 16:46:39,180]INFO:Added new registered prefix to storage: /R
[2024-02-08 16:46:39,180]INFO:Read handle: listening to /R
[2024-02-08 16:46:39,191]INFO:Cache save: /R/0
[2024-02-08 16:46:39,191]INFO:Insertion 78e0872aba89d076ac5aab8a6432201c6533120ba79250434c9392119e3d78db name=/R/0 finish:1 inserted
[2024-02-08 16:46:39,251]INFO:Cache save: /R/1
[2024-02-08 16:46:39,251]INFO:Insertion 78e0872aba89d076ac5aab8a6432201c6533120ba79250434c9392119e3d78db name=/R/1 finish:1 inserted
[2024-02-08 16:46:39,268]INFO:Cache save: /R/2
[2024-02-08 16:46:39,268]INFO:Insertion 78e0872aba89d076ac5aab8a6432201c6533120ba79250434c9392119e3d78db name=/R/2 finish:1 inserted
[2024-02-08 16:46:39,268]INFO:Insertion 78e0872aba89d076ac5aab8a6432201c6533120ba79250434c9392119e3d78db done, total 3 inserted.
[2024-02-08 16:46:40,184]INFO:on_check_interest(): /myrepo/insert%20check/params-sha256=3f60aca3a806c184b1282464fde631586727fe4219655f8eea463b5e9533b1dd
[2024-02-08 16:46:40,184]INFO:Reply to command: /myrepo/insert%20check/params-sha256=3f60aca3a806c184b1282464fde631586727fe4219655f8eea463b5e9533b1dd w/ code=200
[2024-02-08 16:46:40,195]INFO:received subscribed msg: /localhost/seq=3540218072/msg/myrepo/insert/%A3%CE%0B%84%22%40%5B%F1
[2024-02-08 16:46:40,200]INFO:Recved insert command: a2937bc998dcc2f27d07e2d284036730fe220e2050e0218f323920d65e9686c0
[2024-02-08 16:46:40,213]INFO:Cache save: /R/3
[2024-02-08 16:46:40,213]INFO:Insertion a2937bc998dcc2f27d07e2d284036730fe220e2050e0218f323920d65e9686c0 name=/R/3 finish:1 inserted
[2024-02-08 16:46:40,221]INFO:Cache save: /R/4
[2024-02-08 16:46:40,221]INFO:Insertion a2937bc998dcc2f27d07e2d284036730fe220e2050e0218f323920d65e9686c0 name=/R/4 finish:1 inserted
[2024-02-08 16:46:40,232]INFO:Cache save: /R/5
[2024-02-08 16:46:40,232]INFO:Insertion a2937bc998dcc2f27d07e2d284036730fe220e2050e0218f323920d65e9686c0 name=/R/5 finish:1 inserted
[2024-02-08 16:46:40,232]INFO:Insertion a2937bc998dcc2f27d07e2d284036730fe220e2050e0218f323920d65e9686c0 done, total 3 inserted.
[2024-02-08 16:46:41,236]INFO:on_check_interest(): /myrepo/insert%20check/params-sha256=ddd942d2f922c1550c2bb9449b53513241d38b57e63a5e358ec3192ad1834d38
[2024-02-08 16:46:41,236]INFO:Reply to command: /myrepo/insert%20check/params-sha256=ddd942d2f922c1550c2bb9449b53513241d38b57e63a5e358ec3192ad1834d38 w/ code=200
[2024-02-08 16:46:41,249]INFO:received subscribed msg: /localhost/seq=3540218072/msg/myrepo/delete/%A4%22%08%26mo%CA%B6
[2024-02-08 16:46:41,254]INFO:Recved delete command: 78e0872aba89d076ac5aab8a6432201c6533120ba79250434c9392119e3d78db
[2024-02-08 16:46:41,275]INFO:Removed existing registered prefix from storage: /R
[2024-02-08 16:46:41,275]INFO:Read handle: stop listening to /R
[2024-02-08 16:46:41,280]INFO:Removed existing inserted filename from storage: /R/0
[2024-02-08 16:46:41,280]INFO:get from cache
[2024-02-08 16:46:41,281]INFO:Deletion 78e0872aba89d076ac5aab8a6432201c6533120ba79250434c9392119e3d78db name=/R/0 finish:1 deleted
[2024-02-08 16:46:41,286]INFO:Removed existing inserted filename from storage: /R/1
[2024-02-08 16:46:41,286]INFO:get from cache
[2024-02-08 16:46:41,286]INFO:Deletion 78e0872aba89d076ac5aab8a6432201c6533120ba79250434c9392119e3d78db name=/R/1 finish:1 deleted
[2024-02-08 16:46:41,291]INFO:Removed existing inserted filename from storage: /R/2
[2024-02-08 16:46:41,291]INFO:get from cache
[2024-02-08 16:46:41,291]INFO:Deletion 78e0872aba89d076ac5aab8a6432201c6533120ba79250434c9392119e3d78db name=/R/2 finish:1 deleted
[2024-02-08 16:46:41,291]INFO:Deletion 78e0872aba89d076ac5aab8a6432201c6533120ba79250434c9392119e3d78db done, total 3 deleted.
[2024-02-08 16:46:42,201]INFO:on_check_interest(): /myrepo/delete%20check/params-sha256=2e255d82bbf652845b51711c278f0e89cb738fcc7ba7cf769c33f7aafcfb95c3
[2024-02-08 16:46:42,201]INFO:Reply to command: /myrepo/delete%20check/params-sha256=2e255d82bbf652845b51711c278f0e89cb738fcc7ba7cf769c33f7aafcfb95c3 w/ code=200

The repo should remember how many inserted packets requested the same prefix registration, and only unregister the prefix when the last packet requesting this registration is deleted. It is unreasonable to require the client to remember every packet ever inserted to the repo and only include register_prefix field in the deletion command of the last packet, because many client applications would be short-lived or distributed. If the client would have to keep detailed and synchronized state of every packet ever inserted to the repo, the client application may as well serve the packets themselves instead of using a repo.