ایپلیکیشنز میں گھڑی کی مطابقت پذیری — جوہر، پروٹوکول اور نفاذ

گھڑی کی مطابقت پذیری کیا ہے؟

گھڑی کی مطابقت پذیری (Clock Sync) کسی آلے کی اندرونی گھڑی کو حوالہ UTC وقت (عالمی مربوط وقت) کے ساتھ ہم آہنگ کرنے کا ایک طریقہ کار ہے۔ مطابقت پذیری کے بغیر، موبائل آلے میں کوارٹز کرسٹل آسیلیٹر آہستہ آہستہ بہہ جاتا ہے — درجہ حرارت اور اجزاء کے معیار پر منحصر ہے، روزانہ 1–10 سیکنڈ کا بہاؤ ہوتا ہے۔ مطابقت پذیری بیرونی ذرائع: انٹرنیٹ پر NTP سرورز، GPS سیٹلائٹس یا سیل ٹاورز سے درست وقت حاصل کرکے اس بہاؤ کی تلافی کرتی ہے۔ مثالی طور پر، ایک آلے کو 1 سیکنڈ کے اندر درستگی برقرار رکھنے کے لیے ہر 4–6 گھنٹے بعد مطابقت پذیر ہونا چاہیے۔

ہارڈویئر اور سافٹ ویئر گھڑیاں

موبائل آلے میں دو قسم کی گھڑیاں ہوتی ہیں: ہارڈویئر (RTC، ریئل ٹائم کلاک) ایک علیحدہ بیٹری بیک اپ کے ساتھ — یہ آلہ بند ہونے پر بھی چلتی رہتی ہے، اور سافٹ ویئر (سسٹم ٹائم)، جو آپریٹنگ سسٹم کے زیر انتظام ہوتا ہے۔ بوٹ ہونے پر، سسٹم ٹائم RTC سے شروع ہوتا ہے اور پھر کلاک جنریٹر انٹرپٹس کے ذریعے برقرار رکھا جاتا ہے۔ NTP مطابقت پذیری سسٹم ٹائم کو درست کرتی ہے، اور بعض صورتوں میں، RTC میں بھی تصحیح لکھتی ہے۔ Android پر، ہارڈویئر RTC تک رسائی محدود ہے — ایپلیکیشنز روٹ رسائی کے بغیر اسے تبدیل نہیں کر سکتیں۔

موبائل ایپس میں وقت کی مطابقت پذیری کیوں ضروری ہے

موبائل ایپلیکیشن کے آپریشن کے بہت سے پہلوؤں کا انحصار درست سسٹم ٹائم پر ہوتا ہے۔ SSL سرٹیفکیٹس کی میعاد کی مدت ہوتی ہے: اگر آلے کا وقت سرٹیفکیٹ جاری ہونے کی تاریخ سے پہلے یا اس کی میعاد ختم ہونے کی تاریخ کے بعد مقرر کیا گیا ہے، تو HTTPS کنکشن بلاک ہو جائے گا۔ OAuth ٹوکنز اور JWT تصدیق میعاد ختم ہونے کی جانچ کے لیے ٹائم اسٹیمپ استعمال کرتے ہیں — غیر مطابقت پذیری غلط اجازت کی ناکامیوں کا باعث بنتی ہے۔ پش نوٹیفیکیشنز وقت کے مطابق طے ہوتے ہیں، اور اگر گھڑی بہہ جائے تو صارف کو غلط وقت پر اطلاعات ملتی ہیں یا بالکل نہیں ملتیں۔

غیر مطابقت پذیری کے نتائج

ایپلیکیشن سیکورٹی بھی غلط وقت سے متاثر ہوتی ہے: وقت پر مبنی خفیہ کاری (ٹائم پر مبنی OTP)، غلط ٹائم اسٹیمپ کے ساتھ ایونٹ لاگز، سرور سائیڈ پر غلط ریٹ لمیٹنگ (سرور «مستقبل» کی درخواستوں کو بلاک کرتا ہے)۔ OWASP Mobile Top 10 (2024) کے مطابق، سسٹم ٹائم پر عدم اعتماد ناکافی پلیٹ فارم سیکورٹی کے زمرے میں آتا ہے۔ ڈویلپرز کو مشورہ دیا جاتا ہے کہ وہ صرف کلائنٹ گھڑیوں پر انحصار کرنے کے بجائے ہمیشہ سرور پر وقت چیک کریں۔ اگر فرق ایک حد (5 سیکنڈ تجویز کردہ) سے تجاوز کر جائے تو ایپلیکیشن کو مطابقت پذیری تک اہم کارروائیاں بلاک کرنی چاہئیں۔

مطابقت پذیری کے پروٹوکول: NTP اور SNTP

گھڑی کی مطابقت پذیری کے اہم پروٹوکول NTP اور اس کا آسان ورژن SNTP ہیں۔ NTP (RFC 5905) سرور فلٹرنگ، بہاؤ تجزیہ اور PLL تصحیح کے ساتھ ایک مکمل پروٹوکول ہے۔ یہ سرورز اور نیٹ ورک کے آلات پر استعمال ہوتا ہے۔ SNTP (RFC 4330) کلائنٹ آلات کے لیے ہلکا پھلکا ورژن ہے جسے مسلسل مطابقت پذیری کی ضرورت نہیں ہوتی۔ SNTP کلائنٹ درخواست بھیجتا ہے، جواب وصول کرتا ہے اور تاریخ کے تجزیہ کے بغیر وقت مقرر کرتا ہے۔ موبائل آلات پر خاص طور پر SNTP استعمال ہوتا ہے — Android کا بلٹ ان Google Time Service (GTS) time.google.com سرورز کے ساتھ SNTP کے ذریعے مطابقت پذیر ہوتا ہے۔

اضافی مطابقت پذیری کے طریقے

NTP/SNTP کے علاوہ، موبائل آلات پر وقت کی مطابقت پذیری GPS وصول کنندہ (مثالی حالات میں 10 ns تک درستگی) اور سیلولر نیٹ ورک (NITZ — نیٹ ورک شناخت اور ٹائم زون کے ذریعے) ممکن ہے۔ GPS زیادہ سے زیادہ درستگی فراہم کرتا ہے لیکن صرف باہر کام کرتا ہے اور بہت زیادہ توانائی استعمال کرتا ہے۔ NITZ نیٹ ورک میں رجسٹریشن پر خود بخود سیلولر آپریٹر کے ذریعے فراہم کیا جاتا ہے، لیکن تمام آپریٹر اس کی حمایت نہیں کرتے۔ Android تمام طریقوں کا مجموعہ استعمال کرتا ہے: GTS (SNTP) ترجیح کے طور پر، NITZ بیک اپ کے طور پر، اور اعلی درستگی کی ضرورت والی ایپلیکیشنز کے لیے GPS۔

تقسیم شدہ نظاموں میں مطابقت پذیری کے مسائل

تقسیم شدہ نظاموں میں — جب سرور اور کلائنٹ مختلف آلات پر ہوں — گھڑی کی مطابقت پذیری کو بنیادی حدود کا سامنا کرنا پڑتا ہے۔ نیٹ ورک لیٹنسی کلائنٹ پر صحیح وقت کا تعین کرنا ناممکن بنا دیتی ہے: اگر ایک پیکٹ کو 200 ms لگے تو درخواست اور جواب کے وقت سرور پر وقت پہلے ہی مختلف ہوتا ہے۔ NTP RTT پیمائش اور شماریاتی پروسیسنگ کے ذریعے اس مسئلے کو حل کرتا ہے، لیکن تقسیم شدہ لین دین (مثلاً، بینک ٹرانسفر) کے لیے یہ ناکافی ہے — منطقی گھڑیاں (Lamport ٹائم اسٹیمپ) یا ویکٹر گھڑیاں استعمال کی جاتی ہیں۔

طبعی بمقابلہ منطقی گھڑیاں

طبعی گھڑیاں (وال کلاک) — اصل UTC وقت، NTP کے ذریعے مطابقت پذیر ہوتا ہے۔ منطقی گھڑیاں — نظام میں واقعات کی ترتیبی تعداد، طبعی وقت سے منسلک نہیں ہوتیں۔ تقسیم شدہ نظاموں میں، واقعات کی ترتیب کے لیے اکثر ویکٹر گھڑیاں استعمال ہوتی ہیں: ہر نوڈ تمام کلسٹر نوڈس کے لیے ایک کاؤنٹر ویکٹر ذخیرہ کرتا ہے۔ موبائل ایپلیکیشنز کے لیے، 1–5 سیکنڈ کی درستگی کے ساتھ طبعی مطابقت پذیری کافی ہے — یہ OAuth، SSL اور پش نوٹیفیکیشنز کے درست کام کو یقینی بناتی ہے۔ اگر سخت واقعہ ترتیب کی ضرورت ہو (مثلاً، ریئل ٹائم چیٹ میں)، تو سرور کی سطح پر منطقی مطابقت پذیری شامل کی جاتی ہے۔

Android میں Clock Sync کا نفاذ

Android ایپلیکیشن میں گھڑی کی مطابقت پذیری کا نفاذ کئی طریقوں سے کیا جا سکتا ہے۔ سب سے آسان ہے REST API کے ذریعے سرور کا وقت حاصل کرنا: سرور جواب کے باڈی میں یا HTTP Date ہیڈر میں Unix ٹائم اسٹیمپ واپس کرتا ہے۔ اس طریقہ میں اضافی لائبریری کی ضرورت نہیں ہوتی اور یہ ضمانت دیتا ہے کہ وقت سرور سے مماثل ہے۔ دوسرا طریقہ NTP سرور سے براہ راست استفسار کے لیے SNTP کلائنٹ استعمال کرنا ہے۔ تیسرا Android Google Time Service پر انحصار کرنا ہے، جو انٹرنیٹ سے منسلک ہونے پر خود بخود سسٹم ٹائم کو مطابقت پذیر کرتا ہے۔

Android کے لیے طریقوں کا موازنہ

اختیار اور مالی لین دین والی Android ایپلیکیشنز میں، ایک مشترکہ طریقہ تجویز کیا جاتا ہے: ہر API درخواست کے ساتھ، سرور کے وقت اور System.currentTimeMillis() کے درمیان فرق محفوظ کیا جاتا ہے۔ یہ فرق کلائنٹ پر تمام وقت کے حسابات پر لاگو ہوتا ہے، خواہ سسٹم کلاک مطابقت پذیر ہو یا نہ ہو۔ اس طریقہ کو گھڑی کے انحراف کی اصلاح (clock skew correction) کہا جاتا ہے اور اسے ایک کلاس کے ذریعے نافذ کیا جاتا ہے جو سرور کے ساتھ آخری معروف فرق کو ذخیرہ کرتی ہے۔ مزید برآں، WorkManager کے ذریعے ہر 4–6 گھنٹے میں پس منظر میں NTP مطابقت پذیری چلائی جا سکتی ہے۔

// گھڑی کے انحراف کی اصلاح
class ClockSyncManager {
    private var serverTimeDiff: Long = 0 // serverTime - deviceTime (ms)

    fun updateServerTime(serverTimestampMs: Long) {
        serverTimeDiff = serverTimestampMs - System.currentTimeMillis()
    }

    fun getCorrectedTime(): Long {
        return System.currentTimeMillis() + serverTimeDiff
    }

    fun isSyncValid(maxDiffMs: Long = 5000): Boolean {
        return Math.abs(serverTimeDiff) < maxDiffMs
    }
}

WorkManager کے ذریعے پس منظر میں مطابقت پذیری

Android پر وقتی پس منظر میں وقت کی مطابقت پذیری کے لیے، PeriodicWorkRequest کے ساتھ WorkManager استعمال کریں۔ مطابقت پذیری کا کام SNTP درخواست یا REST API کال کرتا ہے، سرور کا وقت حاصل کرتا ہے اور ClockSyncManager کو اپ ڈیٹ کرتا ہے۔ PeriodicWorkRequest کے لیے کم از کم وقفہ 15 منٹ ہے، لیکن وقت کی مطابقت پذیری کے لیے 4–6 گھنٹے کافی ہیں۔ مطابقت پذیری کرتے وقت، نیٹ ورک کی حالت پر غور کریں — رومنگ کے دوران غیر ضروری درخواستوں کو روکنے کے لیے NetworkType.CONNECTED استعمال کریں۔ اگر مطابقت پذیری ناکام ہو جائے تو پچھلی تصحیح محفوظ کریں — یہ آہستہ آہستہ کم ہوتی درستگی کے ساتھ درست رہتی ہے۔

آلات پر خودکار وقت کی مطابقت پذیری

جدید موبائل آلات بلٹ ان سروسز کے ذریعے خود بخود وقت کو مطابقت پذیر کرتے ہیں۔ Android پر — Google Time Service (GTS)، Google Play Services کا حصہ۔ iOS پر — آپریٹنگ سسٹم میں بنایا ہوا NTP کلائنٹ۔ یہ خدمات ایپلیکیشنز سے آزادانہ طور پر کام کرتی ہیں اور کسی اضافی ترتیب کی ضرورت نہیں ہوتی۔ صارف ترتیبات میں خودکار مطابقت پذیری کو غیر فعال کر سکتا ہے، جس سے ایپلیکیشنز کو خطرہ لاحق ہوتا ہے — یہی وہ وقت ہے جب ڈویلپر کو اپنی مطابقت پذیری نافذ کرنے کی ضرورت ہوتی ہے۔ Settings.Global.getInt(AUTO_TIME) کے ذریعے خودکار مطابقت پذیری کی حیثیت چیک کرنے اور غیر فعال ہونے پر صارف کو خبردار کرنے کی سفارش کی جاتی ہے۔

ڈویلپرز کے لیے سفارشات

صرف خودکار مطابقت پذیری پر انحصار کرنا خطرناک ہے — صارف اسے غیر فعال کر سکتا ہے یا انٹرنیٹ کے بغیر علاقے میں ہو سکتا ہے۔ بہترین عمل ہر API درخواست کے ساتھ سرور سے وقت حاصل کرنا اور SharedPreferences یا DataStore میں غیر مطابقت پذیری کو ذخیرہ کرنا ہے۔ اہم کارروائیوں (ادائیگی، اختیار، دستاویزات پر دستخط) کے لیے، عمل درآمد سے پہلے ہمیشہ isSyncValid() چیک کریں۔ اگر غیر مطابقت پذیری حد سے تجاوز کر جائے — صارف کو ایک اسکرین دکھائیں جو خودکار مطابقت پذیری کو فعال کرنے یا مطابقت پذیری کا انتظار کرنے کا مشورہ دے۔ گیمنگ اور تفریحی ایپلیکیشنز کے لیے، شروع ہونے پر سرور سے وقت حاصل کرنا اور ہر گھنٹے میں ایک بار اپ ڈیٹ کرنا کافی ہے۔