<em id="ri2my"></em>
  • <em id="ri2my"></em>
    <em id="ri2my"><label id="ri2my"><nav id="ri2my"></nav></label></em>
  • <em id="ri2my"><label id="ri2my"></label></em>
    <div id="ri2my"></div>
    1. <em id="ri2my"><label id="ri2my"></label></em>
    2. <em id="ri2my"><ol id="ri2my"></ol></em>
      <em id="ri2my"></em>

      1. 關于貝殼物聯的一個登陸狀態的問題。個人感覺非常別扭

        作者:eboxmaker | 更新時間:2016-10-22 | 瀏覽量:2009

        我在用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一下。
        大家可以討論是否需要將設備也改為,后來登錄的直接擠掉前者?
        返回頂部

        <em id="ri2my"></em>
      2. <em id="ri2my"></em>
        <em id="ri2my"><label id="ri2my"><nav id="ri2my"></nav></label></em>
      3. <em id="ri2my"><label id="ri2my"></label></em>
        <div id="ri2my"></div>
        1. <em id="ri2my"><label id="ri2my"></label></em>
        2. <em id="ri2my"><ol id="ri2my"></ol></em>
          <em id="ri2my"></em>

          1. 免费高清视频