मुझे लगता है कि सिस्टम में घड़ी को सिंक्रोनाइज़ करना निश्चित रूप से ठीक नहीं है । उपयोगकर्ता आपको सिस्टम सेटिंग्स को छूने की उम्मीद नहीं करता है और कई सिस्टम आपको करने भी नहीं देंगे।
आपको केवल एक पक्ष की घड़ी से दूसरे पक्ष की घड़ी में टाइमस्टैम्प को परिवर्तित करने के लिए सहसंबंध होना चाहिए। दूसरी ओर, आपको इस सहसंबंध की आवश्यकता बल्कि सटीक होना चाहिए, कम से कम एक सैकेंड के सौवें हिस्से तक कहें, यदि आप खिलाड़ी के पदों की भविष्यवाणी के लिए इसका उपयोग करना चाहते हैं। सिस्टम घड़ी कभी भी यादृच्छिक मशीनों के बीच इस अच्छी तरह से सहसंबद्ध नहीं होगी । तो आपको एनटीपी विषय पर कुछ भिन्नता का उपयोग करते हुए, स्वयं को सहसंबंध स्थापित करना चाहिए , संभवतः नेटवर्क बैंडविड्थ के संरक्षण के लिए आपके अन्य संदेशों में एम्बेडेड है।
मूल विचार यह हो सकता है कि जब आप दूसरी तरफ से आखिरी पैकेट प्राप्त करते हैं, तो आपने जो पैकेट भेजा था, उस समय और आपके द्वारा भेजे गए टाइमस्टैम्प के प्रत्येक पैकेट के साथ। इससे आप राउंडट्रिप की गणना करते हैं: उदाहरण के लिए यदि पैकेट क्यू कहता है कि यह 1000 पर भेजा गया था और पैकेट पी 500 पर प्राप्त हुआ था, तो आपको दिए गए पैकेट पी को 0 पर भेजा गया था और 800 पर क्यू प्राप्त कर रहा है, राउंड-ट्रिप है (800 - 0 ) - (१००० - ५००) = ३००. अस्मिता जानने का कोई तरीका नहीं है, इसलिए आप बस मान लेते हैं कि पैकेट दोनों दिशा में आधा (१५०) टिक लेता है। और वह रिमोट टाइमस्टैम्प 1000 से स्थानीय से आगे है - (800 - 150) = 350 टिक। दौर-यात्रा अलग-अलग होगी। यदि आप मानते हैं कि घड़ी यथोचित रूप से सटीक है, तो आपको सह-संबंध के दीर्घकालिक औसत का उपयोग करना चाहिए।
ध्यान दें, कि आप घड़ी के लिए सिस्टम घड़ी का उपयोग नहीं करना चाहते हैं। वे आपको ट्रैक से हटाकर, बीच में पुन: सिंक्रनाइज़ किए जा सकते हैं। आपको clock(CLOCK_MONOTONIC)यूनिक्स या GetTickCountविंडोज पर उपयोग करना चाहिए (यह सुनिश्चित नहीं करना चाहिए कि उन एपीआई को अभी जावा या पायथन में कैसे लपेटा गया है)।
नोट: SO_TIMESTAMPसॉकेट विकल्प (देखें सॉकेट (7) ott-- द्वारा उल्लिखित प्रश्न पर टिप्पणी में) पैकेट प्राप्त करने वाले इवेंट लूप की विलंबता के प्रभाव को अलग करने के लिए उपयोगी होगा। क्या यह प्रयास के लायक है यह सिर्फ इस बात पर निर्भर करता है कि आपको कितनी अच्छी सटीकता की आवश्यकता है।