[已回復] 求教同一賬號、不同設備、同時登陸強制下線的優化方法

安卓和IOS存在：同一賬號，在多臺設備同時登陸的問題，想要改成同一賬號只能同時在唯一一臺設備上登陸，其他設備強制下線？

這個需求，可以在MobileIMSDK這一層來優化，方法就是在第二個設備上登陸時，服務端發現該賬號的會話已存在時，就先踢出之前的會話（先發一個踢出指令，后斷開會話），然后再繼續正常流程。

這里面有一個難點，就是因為是udp協議，所以最壞的情況下，萬一踢出前一個賬號時，踢出指令丟了，那就有點麻煩。這個可以建議加一個時間戳，當前一個會話沒有收到被踢指令，嘗試重連時，帶上這個時間戳，服務端比對出這個時間戳比第2個設備上的時間戳早，就意味著這是個已被廢棄的會話，再重發給他被踢指令即可。

以上大致的思路就是這樣，僅供參考。這個優化可以直接在mobileimsdk的demo里優化好，測試沒問題后打jar使用即可，這樣方便測試。

重連的時候帶上時間戳，確實能解決這個問題，下一個版本里面能不能帶上時間戳，我怕我去改源碼，反而改爛了，，因為我現在重連的代碼在哪兒實現的，都不知道，，，，

會不會有這種情況：
A設備已登錄
B設備請求登錄
服務端向A設備發送下線指令
A網絡很爛，沒有收到指令，也沒有在預期時間內向服務端送達重連請求
B設備登錄成功
此時A設備帶著時間戳向服務端發送重連請求
此時A的時間戳晚于B，所以A又成功重連了

引用：dahai2070 發表于 2019-06-17 11:32
重連的時候帶上時間戳，確實能解決這個問題，下一個版本里面能不能帶上時間戳，我怕我去改源碼，反而改爛了 ...

多端互踢很多人的定義不一樣，有的人希望多端直接互踢，而且的人可能希望移動端互踢，pc端互踢，但pc端和移動端可以并存。  這些具體的邏輯如果只選一種做到sdk里就顯的很局限。所以，眾口難調，就沒有武斷地去考慮這個實現。

我在2樓的回復，其實是考慮的最簡單的那種，就是只要在別的端登陸就被踢。這個時間戳就是在你MobileIMSDK這一層，連接/登陸到服務端時，由服務端把當前的系統時間戳給你就是了，你去讀一讀代碼，沒有看源碼的話，具體有點記不太清了

引用：freeman 發表于 2019-08-05 11:06
會不會有這種情況：
A設備已登錄
B設備請求登錄

不可能，因為有你的“A設備已登錄”這個前提在，所以它拿著登陸時服務端給的時間戳是不可能晚于后面的時間。

引用：JackJiang 發表于 2019-08-05 11:28
不可能，因為有你的“A設備已登錄”這個前提在，所以它拿著登陸時服務端給的時間戳是不可能晚于后面的時 ...

明白了，時間戳是上一次成功連接的時間戳，剛才理解錯了，以為是當前請求的時間

引用：freeman 發表于 2019-08-05 11:30
明白了，時間戳是上一次成功連接的時間戳，剛才理解錯了，以為是當前請求的時間

嗯嗯

我做的多端登錄互踢現在還存在一個偶爾發生的問題：客戶端在沒有多端登錄的情況下收到下線指令。
我懷疑這種情況導致，你看看有沒有可能：
客戶端斷線，帶著時間戳發送重連請求，服務端收到后更新時間戳，將新的結果返回給客戶端，
因為重連請求是每隔3秒鐘就發送，3秒之內服務端返回的新的結果尚未到達客戶端，此時客戶端再次發出一條重連請求，而此時服務端保存的時間戳已經更新了，而客戶端發來的請求還是舊的時間戳，于是判斷為失效連接，發出下線指令，于是...客戶端被自己踢下線了

引用：freeman 發表于 2019-08-28 23:15
我做的多端登錄互踢現在還存在一個偶爾發生的問題：客戶端在沒有多端登錄的情況下收到下線指令。
我懷疑這 ...

應該不存在你說的這種可能，因為你重連時是會帶上時間戳的，換句話說，服務端看到有時間戳帶過來，就可以判定為這是這是重連，重連是不應更新時間戳的。

也就是第二條返回結果（下線）先于第一條（重連成功）到達客戶端，導致客戶端下線

引用：JackJiang 發表于 2019-08-28 23:21
應該不存在你說的這種可能，因為你重連時是會帶上時間戳的，換句話說，服務端看到有時間戳帶過來，就可以 ...

哦，是了，重連不更新時間，這個邏輯有點亂，我再理一理

引用：freeman 發表于 2019-08-28 23:25
哦，是了，重連不更新時間，這個邏輯有點亂，我再理一理

最好畫個圖，先把邏輯理順了再去看代碼就很清晰了。事情看起來很簡單，但邏輯其實很繞的

原因找到了
if(a)
{
        if(b)
        {
                ...
        }
}
else
{
        ...
}
簡寫成
if(a && b)
{
        ...
}
else
{
        ...
}
邏輯錯了。
重連更新時間戳目前看倒沒問題，不過不更新更安全點。先不改了，有問題再取消更新