Hantao Sun

这个实时刷新应该是每秒从服务器获取到真实的报名人数吧？也就是每秒变化一次。 可以规定每秒显示的人数增加10级别，如果服务器给的数量超过当前秒数量级则显示真实的。 > 比如： > 第一秒从0-10随即一个数，假设 rand() % 10 = 6。 > 第二秒应该显示10-20之间的数，假设 rand() % 10 + 4 = 12。 > 第二秒应该显示20-30之间的数，假设 rand() % 10 + 8 = 28。 >...

报道跟上！

方案一还有个问题就是硬编码太多，不容易扩展API。迭代开发工作量大。 方案二比较好的优势是可以完全把控，扩展性好，新增API代码量少。缺点是需要持续的优化及修改bug

## 过滤器的方案 - 在CBlockIndex中增加一个过滤器字段，将该块中所有交易涉及的地址集合放到过滤器上。根据交易的大小该字段的大小范围约为`0 - 5k` - 在检索时遍历CBlockIndex并判断地址是否有可能在这个块中，如在将块读出来筛选交易 ### 优点 - 效率比原方案快的多 - 代码容易编写，改动量小 - 处理简单，不用考虑回滚 ### 缺点 - 占用内存大，需要考虑blockindex无法在内存全放下的情况（原代码随着时间推移也有blockindex不能全放内存的时候，只是该方案加快了这个临界点的到来） - 有误报率，且过滤器的容量和误报率成反比，这个误报率的数值需要考虑 - blockindexdb数据库数据比较大可能有读取速度问题

## 全局过滤器方案 - 对于每一个fork有一个全局过滤器 - 过滤器hash的内容是addr + blockhash - 通过内存中计算该地址是否可能在某个block中有交易，读取block数据，筛选其中的交易 ### 优点 - 效率高 - 支持多地址索引 ### 缺点 - 占用内存大，未来可能考虑将过滤器部分放在文件中 - 有误报率

可以考虑这个办法： 1. 在一个分叉上块的打包与验证过程中，保证fork不重名，要么有A、要么有B 2. 在长短链切换时，可以切换A、B订阅关系

测试链存在两个重名分支： ``` "fork" : "00003841577cb3b48afe04eceb328bad1a697cf86619b87b7df8f74fcb942a1f", "name" : "BigBangCoreCamera" ``` 和 ``` "fork" : "00001195d2d0771094ec8459f0b375bab1e0dd75f179cf6f93e678ac86e8bd32", "name" : "BigBangCoreCamera", ``` forkdb将两个分支都存起来了，导致forkmanager有两个分支。但AddNewOrigin判断了重名分支，所以blockbase实际存在的分支只有一个。 在RPC listfork的时候，有`-a`参数从forkmanager获取数据，没有`-a`参数从blockbase获取数据导致了不一致的情况。 临时修复办法是都从forkmanager获取数据，在返回RPC结果时去重。 彻底修复应在`fork抵押赎回PR` #572 中考虑db中不存重名分支

- fork的joint必须是最长链30个高度以前。这样可以避免回滚导致joint失效，进而fork失效的情况。一旦出现该情况，代码并未处理。 - forkmanager和forkdb的数据一一对应。forkdb新增一个inactive开头的数据，用于记录由于回滚导致的失效fork - 发送到fork模板的交易强校验，交易必须在当前能创建合法fork - fork的赎回不检查fork地址上的余额，只检查当前交易的vin >= amount + lock + txfee。相应的wallet对于赎回交易组织合法的input - 对于fork的回滚，不删除既有数据。在forkdb和CForkContextEx中记录其有效性，并做相应处理和判断。 - txpool处理fork交易回滚的情况 - service处理fork交易回滚。wallet不处理，由wallet的调用上层service来控制。 - blockbase对于失效fork做标记，blockview可以提取fork交易