Open foreso-GitHub opened 3 years ago
现在subscribe是,按client + topic(id之前用过,后来去掉了,可以讨论下加不要再加回来)来区分的,如果两者有一个不同就不同的
client指的是ws的实例吗?
unsubscribe的时候,需要提交相应的topic即可,因为client是websocket的client实例,如果连接没变的话,client实例不没有变化
另外还有一个问题,block及tx订阅,现在为了兼容老链,都是推送block及tx的所有信息,block还好,毕竟一般5秒一个(现在这个测试链),而tx如果tx交易很多的话,推着tx所有的信息,估计会影响节点运行及接收端(这个只是估计,需要评估下)
订阅token及account, 因为是后来实现,现在只推送相关的交易的hash, 所以数据量比较少
jt_unsubscribe ,如果第二个参数index不加,会是什么效果?
jt_unsubscribe第二个参数是topic, 如果不加的话,类似没调用。。。。可以返回个错误信息
之前订阅这一块,用的是client+id, 后来发现id经常记不住,或者重复使用已经有的id, 另外就是不鼓励同一个client,同一个topic订阅多个。。。所以后来就换成client + topic了
id现在还是跟其他一样,只用来区分不同订阅或者不同命令的返回信息,比如订阅的时候,用的id是1, 那么所有这个订阅的block信息在返回的时候,id都是1 (这地方需要补充下,因为订阅在block, tx的两个时,为兼容老链,所以没有id, 与以前老链返回的格式相同, token及account 新实现的符合所说的id要求, 后续要分成两套订阅,兼容以前的,新的,这样的话就不会有冲突了)
这里topic具体是什么含义?和id的区别是什么?
topic或者叫type, 现在支持四种,block, tx, token及account, 后边两个是新加的,有参数的,前边两个是兼容以前的没有参数
jt_unsubscribe第二个参数是topic, 如果不加的话,类似没调用。。。。可以返回个错误信息
那这里jt_unsubscribe第一个参数才是topic吧?第二个参数是id。文档里提到”- (可选) 取消订阅内容里某个订阅id, 与订阅时请求的id相同“。我的问题是,如果第二个参数id不加,jt_unsubscribe会怎么处理?
{"id":1,"method":"jt_unsubscribe","params":["block", 0]}
jt_unsubscribe第二个参数是topic, 如果不加的话,类似没调用。。。。可以返回个错误信息
那这里jt_unsubscribe第一个参数才是topic吧?第二个参数是id。文档里提到”- (可选) 取消订阅内容里某个订阅id, 与订阅时请求的id相同“。我的问题是,如果第二个参数id不加,jt_unsubscribe会怎么处理?
{"id":1,"method":"jt_unsubscribe","params":["block", 0]}
发上一个贴子的时候,我检查了一下文档,发现文档这一块有问题,已经更新。。。
Parameters 参数
STRING - 取消订阅内容,可为block, tx, token或者account四者之一
只有一个参数也有问题。比如同时订阅了不同帐号的多个account订阅,要取消订阅,该如何区分要取消的是哪一个呢?还是所有的account订阅都取消了?
jt_subscribe account account1 account2 ...
和维佳讨论后功能修改如下:
STRING
- 订阅内容,可为block, tx, token及account四者之一STRING
- 订阅参数,可选,当前为兼容以前,只有新的token及account有参数已经提交第一版本,见今天的版本
jt_subscribe, block, tx不用说了,因为没有参数,token及account, 通过client + topic作为唯一key, token及account的参数,多次提交jt_subscribe是叠加的,当然同样的token及account,只算一次
jt_unsubscribe, 参数与jt_subscribe相同,作用相反,有一个特例在token及account的时候,如果没有参数,会unsubscribe当前client + topic所有(参数)及本订阅
增加 jt_listSubscribe, 可以查看当前client所有订阅的topic(block, tx, token及account)及相关参数
相关文档也更新,具体见 jt_subscribe, jt_unsubscribe, jt_listSubscribe
@caivega jt_subscribe订阅token时,由于全局token和带issuer的token是可以重名的,所以订阅参数上需要有一个对它们加以区分的方法,请考虑一下,多谢。 {"id":0,"method":"jt_subscribe","params":["token", "TEST"]}
可以用/的方式,如果是全局的TEST就是TEST,如果是local的TEST,就是TEST/issuer
全局TEST:
{"id":0,"method":"jt_subscribe","params":["token", "TEST"]}
本地TEST:
{"id":0,"method":"jt_subscribe","params":["token", "TEST/jHb9CJAWyB4jr91VRWn96DkukG4bwdtyTh"]}
jt_unsubscribe,如果没有参数,是否能取消所有当前的订阅?
{"id":1,"method":"jt_unsubscribe","params":[]}
可以考虑通过参数"all"来取消当前所有订阅,不带参数这种我怕会有误操作引起所有的订阅被取消。
{"id":1,"method":"jt_unsubscribe","params":[“all”]}
可以考虑通过参数"all"来取消当前所有订阅,不带参数这种我怕会有误操作引起所有的订阅被取消。
{"id":1,"method":"jt_unsubscribe","params":[“all”]}
同意
可以考虑通过参数"all"来取消当前所有订阅,不带参数这种我怕会有误操作引起所有的订阅被取消。
{"id":1,"method":"jt_unsubscribe","params":[“all”]}
这样明确些
@caivega jt_subscribe订阅account时,如果这个account地址还没有过任何历史交易,应该是返回订阅成功还是订阅失败呢?
{"id":0,"method":"jt_subscribe","params":["account", "jHb9CJAWyB4jr91VRWn96DkukG4bwdtyTh"]}
现在是订阅成功,因为当不住一会就有这个account的交易来了呢。。。
all 及 TEST/jHb9CJAWyB4jr91VRWn96DkukG4bwdtyTh 功能已经加到今天的版本中
优秀
2个新问题:
2个新问题:
- jt_subscribe无论是否成功,都没有信息反馈。这个是by design吗?
- jt_subscribe订阅local coin现在需要加上issuer,但如果是global coin,不能加issuer,加上了就无法订阅。能否改成global coin,无论是否加issuer都可以订阅成功?这样有些场景,用户无论是否global还是local的coin,都用一种格式就全处理了。
第一个问题,特意思考过,因为订阅完了,一般就是开始等订阅的信息了,有时候刚订阅了,立马订阅的信息就回来,主要是担心如果再加返回的信息,用户需要分辨jt_subscribe的命令的返回信息与订阅的信息,当然不好的地方,就是用户没办法知道订阅成功还是失败,不过,这个已经处理了,失败会有返回信息的,成攻没有返回信息(当然只有订阅信息返回),另外订阅这个除非节点出问题了,基本上都会订阅成功的,另外也可以通过jt_listSubscribe(这个加的很有必要)
第二个问题,不理解啥意思,global coin本身就不需要issuer。。。,比如TEST,就是TEST, 如果是local的coin, 自然是需要加issuer的,比如TEST/root_issuer, 没有issuer的话,就是global的TEST的币
0011 订阅区块,带无效的订阅参数 订阅区块,订阅内容为block,订阅参数为任意值 订阅失败(因为订阅block时不支持带订阅参数)
这条case的设计是这样:参数可以这样,['block', 'abcd'],结果应该是订阅失败。 实际结果:上个版本(20201130)这样写应该是订阅失败,这个版本(20201205)这样写订阅成功,可能是subscribe只看第一个参数,不管其他的参数。这个是不是by design?
现在实现是这样的,就是参数都会传过去,当然现在只有token与account用了,因为这套api不用兼容之前版本的api,所以block也会使用参数(我现在想到的就是block hash, block number),包括tx也会使用参数(tx hash等)
如果是这样,['block', 'abcd']导致的结果应该是订阅失败,因为参数‘abcd’不符合block hash或者block number的格式。
鉴于目前还没有增加这样的功能,我建议暂时不要在subscribe上增加新的功能,因为block和tx增加参数可以考虑得很复杂(比如block是否能指定一个number的范围来订阅等),暂时没有必要。如果大家同意这个建议,block和tx的订阅暂时不允许2个以上参数,不然就报错。
subscribe目前我们只先满足基本功能就行。
如果是这样,['block', 'abcd']导致的结果应该是订阅失败,因为参数‘abcd’不符合block hash或者block number的格式。
鉴于目前还没有增加这样的功能,我建议暂时不要在subscribe上增加新的功能,因为block和tx增加参数可以考虑得很复杂(比如block是否能指定一个number的范围来订阅等),暂时没有必要。如果大家同意这个建议,block和tx的订阅暂时不允许2个以上参数,不然就报错。
同意
目前我操作subscribe和unsubscribe,观察到的行为如下: subscribe操作只会增加订阅。再次subscribe不会改变原先的subscribe,会同时存在2个订阅。同时,可以存在多个相同类型的subscribe,比如多个block的订阅,它们推送的信息一致。需要讨论确认一下这是否是正确的行为。
建议: