[NKP-0012] Limit subscribe metadata size

Currently subscribe metadata size is unlimited, and it is possible to send huge subscribe txn with ~1MB metadata and consume quite a lot spaces (in terms of both RAM and disk space), and we’ve already seen people doing it. It’s probably better to limit the size of a single subscribe txn by limiting the metadata size.

Since the metadata is used to store application specific data, it’s better to discuss the appropriate metadata size limit. Welcome to vote and leave your thoughts below :slight_smile:

  • Yes
  • No

0 voters

To me something around 1k might be a good starting value.

希望这次更新可以让矿工自主决定是否跑CDN,读取账本中CDN内容非常占用IO,现在2G就非常占IO了,如果储存的内容再增长几倍,恐怕连高端VPS都要跑不动。

想象下 大量CDN内容上传到账本,同时又大量读取CDN内容进行分发,这IO。。。直接不用挖了。

  1. CDN 和 nkn 节点是分离的,除非你是内测 N1 用户,否则是不会运行 CDN 的……
  2. CDN 和账本是完全分离的,不会有任何的账本读写……

:grinning:能不能优化下,把读写速度降低下

现在的数据库用的是 Google 的 leveldb,已经是非常优化的了,并且系统的负载已经非常低了,如果现在 io 都跟不上的话以后只会更吃力……

This NKP has been implemented