需要雙向縮小散列算法

-1

我們有32位全局id字符串，用於識別我們系統中的對象以及唯一標識我們手機客戶端的移動id字符串。目前手機號碼是手機號碼，但可能會生成任何內容。需要雙向縮小散列算法

爲了節省網絡流量，將這兩個字符串組合成另一個更小的字符串（我們稱之爲本地ID），並將該ID傳送到手機而不是全局ID對我們很有用。當電話將本地ID傳回給我們時，我們將本地ID轉換回全局ID並處理它。本地ID必須是手機唯一的，但不是全球唯一的。移動ID已經在客戶端和服務器之間共享，所以不需要傳輸它。

我們的第一個想法是在服務器上有一個巨大的表格陣列，每個表格都將全局ID映射到給定移動ID的本地ID。然而，如果有一個簡單的算法存在，我們可以做

algorithm(mobileid, globalid) = localid  -----> server sends localid to client 

client sends localid back to server 

algorithm(mobileid, localid) = globalid

這甚至可能嗎？如果是，最好的方法是什麼？請和謝謝。

來源

2012-06-29 Ring

爲什麼客戶端不使用全局ID？ – erickson

因爲這樣做的關鍵是通過讓localid小於globalid來節省網絡流量。 – Ring

鴿子的原理很快證明在一般情況下不存在這樣的算法。服務器上的某種動態查找表真的有問題嗎？ –

你需要一個本地ID，例如：

可以解碼全局ID從中
可以解碼便攜ID，從中

那麼瑣碎的辦法是查找表，但你已經說過你不想要那個。

你需要的不是一個hasing算法，而是一個壓縮算法，因爲你想再次提取相同的數據。由於您沒有太多數據（32位+電話號碼），因此我認爲傳統的壓縮算法不適合您。如果你有一個32位數的字符串表示，你需要10個字符（max unsigned int = 4294967295），但實際上你只需要一個32位的字符串表達式4字節。與電話號碼相同。如果由於您的協議，您需要將數字存儲爲ascii字符串，則可以使用base64編碼。

來源

2012-06-29 18:40:03 pmoleri

32位全局id字符串已經以base 64編碼。我不需要在本地id中編碼的移動id，因爲它已經在客戶端和服務器之間共享。經過對這個問題的更多思考之後，我不認爲沒有查找表就可以解決這個問題。 – Ring

我同意你的意見。我知道你不需要編碼，我建議它得到一個更小的字符串（小於十進制字符串），但你已經這樣做了。 – pmoleri

@Ring將32位值編碼到Base64中只會讓它們變長，所以我不知道你爲什麼這樣做。它們真的是32位，還是32位？如果前者，當然在截斷32位時不會有太多的節省？ – EJP

需要雙向縮小散列算法

回答

相關問題