在一個網上農場類遊戲我需要驗證的服務器的客戶端的漫長過程就像蓋房子。說房子需要10分鐘才能建成。客戶端在開始建造房屋時通過TCP連接異步發送「開始建造」消息，當它認爲建造房屋時發送「完成建造」消息。在服務器上，我需要驗證該房屋是否至少在10分鐘內建成。問題是服務器不知道客戶端何時發送「開始構建」和「完成構建」消息。它知道什麼時候接收到消息，但是網絡滯後，可能的網絡故障和消息可能足夠長以接收幾個tcp段。據我瞭解，客戶端發送消息的時間可能長達幾分鐘，取決於客戶端的TCP配置。問題是：有沒有辦法知道什麼時候在客戶端發佈消息？如果沒有，我如何保證該消息的發送時間，可能是一些服務器的TCP配置？該服務器中的某個超時會收到該消息，否則就會失敗。對於我可能沒有想到的主要任務的任何其他解決方案也是受歡迎的。如何知道當一個TCP消息發送
在此先感謝！
如果我理解正確的話，你的主要問題不是TCP本身（因爲所描述的情形也可能發生使用UDP）相關的，但你的消息的年表和固定的時間表還沒有被僞造。
所以，你要避免的唯一情況是：
STARTED send at 09:00:00 and received at 09:00:30 (higher latency)
FINISHED send at 09:10:00 and received at 09:10:01 (lower latency)
，因爲它看起來到服務器，就好像有隻花了9.5構建虛擬建築分鐘。但客戶端沒有作弊，只是第一條消息比第二條消息有更高的延遲。
其他的方式就沒有問題：
STARTED send at 09:00:00 and received at 09:00:01 (lower latency)
FINISHED send at 09:10:00 and received at 09:10:30 (higher latency)
或
STARTED send at 09:00:00 and received at 09:00:10 (equal latency)
FINISHED send at 09:10:00 and received at 09:10:10 (equal latency)
如至少10分鐘的兩個消息的接收之間經過。
不幸的是沒有辦法，以確保客戶不使用時間戳或欺騙等。如果您的客戶端在消息中寫入時間戳或者協議爲您執行了它，則無關緊要。有兩個原因：
所以唯一可以肯定的是服務器收到消息的時間。一個簡單的解決方案是，如果服務器認爲接收到FINISHED消息時沒有足夠的時間，則發送包含留給客戶端的時間的某種重試消息。所以客戶可以調整施工動畫，然後再發送FINISHED消息，這取決於剩下多少時間。
問題與您所描述的完全相同 - 感謝我沒有提供的漂亮插圖。服務器只能看到收到消息的時間，並且可能小於或大於客戶端發送的消息之間的時間。是的，服務器只能驗證這個接收時間，任何時間戳都可能是僞造的。 – 2014-09-01 14:43:47
我想到了RETRY解決方案，它需要一些客戶端邏輯和回滾用戶可以看到我們試圖避免的。我會更好地原諒有點作弊的客戶端，而不是強迫普通客戶端重新繪製遊戲或回滾進度。 – 2014-09-01 14:44:25
問題是什麼時候我必須原諒。在你的例子中，它只有30秒，但看到http://www.pcvr.nl/tcpip/tcp_time.htm#21_2這本書說9分鐘！所以問題是我該如何管理這個時間，並把它減少到1分鐘？據我所知套接字超時將無法工作，因爲客戶端可以每1分鐘發送一小塊消息塊，整個消息仍然需要幾分鐘才能發送。 – 2014-09-01 14:45:50
爲什麼還在乎呢？你知道房子什麼時候開始建造，讓服務器在10分鐘後向客戶端發送消息。 – serakfalcon 2014-09-01 14:05:00
房屋建造可以被打斷，並且/或者具有不同工作速度的其他工人可以在之後開始建造。對於用戶來說，它應該看起來儘可能平滑，不需要修改服務器的構建時間，所以服務器只會樂觀地進行驗證，而不是懲罰誠實的客戶端，從而更好地讓客戶端進行欺騙。另一個原因是我不希望服務器運行單獨的任務來確定何時將「完成構建」發送給可能未連接的客戶端。如果沒有其他選擇，我可能不得不這樣做，但我想尋找一種方法來首先限制客戶滯後模糊。 – 2014-09-01 14:18:30
如果你只是想減少滯後和不打擾客戶作弊。比我推薦使用UDP，因爲它在大多數情況下是真正的異步和比TCP更快的。由於你不想傳輸文件，但是很短的信息，它可能是你的遊戲的最佳選擇（就像大多數其他多人遊戲一樣）。 – 2014-09-01 14:27:27