关于贝壳物联的一个登陆状态的问题。个人感觉非常别扭

作者:eboxmaker | 更新时间:2016-10-22 | 浏览量:2370

我在用eBox做贝壳物联的API,结果发现一个很别扭的问题,描述如下

出现问题的过程描述:

1、设备登陆服务器

2、设备由于某种原因掉线等异常无法和服务器通信

3、设备重启,重新连接、登陆服务器

4、结果无法登录!必须等待服务器刷新成离线模式才能再次登陆!

不知道能不能解决这个问题!我试着checkout一下,倒是能解决,总觉别扭!


评论:共5条

贝壳物联 评论于:2016-10-22 19:39:07
非常感谢你的建议,目前贝壳机制是这样的:
用户登录是后来在挤掉先登录者,方便用户在别的地方登录;
设备登录是,先登录者不下线,后来者无法登录,为了保证设备稳定在线,不被随意或无意挤掉线。
正常掉线服务器会很快做出反应。未及时反应的还需自己checkout一下。
大家可以讨论是否需要将设备也改为,后来登录的直接挤掉前者?
eboxmaker 评论于:2016-10-22 20:31:42
这个设计肯定有问题的,
1、最直接的一个问题,现在这种机制无法保证设备不被挤掉线;所以这种做法直接降低了本身的易用性,同时也无法达到想要的目标。
2、如果ID和key被别人知道了,那肯定已经不能用了。必须更换key。
3、为什么掉线了别的命令都不回复,只有一个checkout能通信。
贝壳物联 回复于:2016-10-22 23:05:48
回复 @eboxmaker:如果不刻意checkout,可以保证不被挤掉的。如果不是这种机制,就要checkin一次踢掉一次的上一次的连接。
checkout的前提不必checkin,其他指令前提是要checkin的。
a386554965 评论于:2018-06-16 18:35:38
谢谢,学习一下
18616042026 评论于:2021-05-04 17:00:51
非常感谢你的建议,目前贝壳机制是这样的:
用户登录是后来在挤掉先登录者,方便用户在别的地方登录;
设备登录是,先登录者不下线,后来者无法登录,为了保证设备稳定在线,不被随意或无意挤掉线。
正常掉线服务器会很快做出反应。未及时反应的还需自己checkout一下。
大家可以讨论是否需要将设备也改为,后来登录的直接挤掉前者?
返回顶部