اسان اندازو لڳائڻ جي دلچسپ دنيا ۾ اسان جي وسعت کي جاري رکون ٿا ... لاگز ذريعي مسئلا حل ڪرڻ. IN اسان بنيادي شرطن جي معنى تي اتفاق ڪيو ۽ ويم جي مجموعي ساخت کي هڪ اک سان هڪ واحد ايپليڪيشن طور ڏٺو. ان لاءِ ڪم اهو آهي ته اهو معلوم ڪرڻ آهي ته لاگ فائلون ڪيئن ٺهيون، انهن ۾ ڪهڙي قسم جي معلومات ڏيکاريل آهي ۽ اهي ڇو نظر اچن ٿا جيئن اهي نظر اچن ٿا.
توهان ڇا ٿا سوچيو اهي "لاگ" آهن؟ گهڻن جي مطابق، ڪنهن به ايپليڪيشن جي لاگز کي هڪ اهڙي قسم جي طاقتور اداري جو ڪردار مقرر ڪيو وڃي ٿو جيڪو گهڻو ڪري پوئين صحن ۾ ڀاڄي ٿو، پر صحيح وقت تي چمڪندڙ هٿيارن ۾ ڪٿي به نه ظاهر ٿئي ٿو ۽ سڀني کي بچائيندو آهي. اهو آهي، انهن کي هر شيء تي مشتمل هجڻ گهرجي، هر جزو ۾ معمولي غلطي کان انفرادي ڊيٽابيس ٽرانزيڪشن تائين. ۽ انهي ڪري ته غلطي کان پوء اهو فوري طور تي لکيو ويو ته ان کي ڪيئن درست ڪجي. ۽ اهو سڀ ڪجهه ميگا بائيٽ ۾ فٽ ٿيڻ گهرجي، وڌيڪ نه. اهو صرف متن آهي! ٽيڪسٽ فائلون ڏهه گيگا بائيٽ نٿا وٺي سگهن، مون اهو ڪٿي ٻڌو آهي!
تنهنڪري لاگز
حقيقي دنيا ۾، لاگ صرف تشخيصي معلومات جو هڪ ذخيرو آهن. ۽ اتي ڇا ذخيرو ڪجي، اسٽوريج لاءِ معلومات ڪٿي حاصل ڪجي ۽ ان کي ڪيترو تفصيلي هئڻ گهرجي، اهو فيصلو ڊولپرز تي ئي آهي. ڪو ON / OFF سطح جي رڪارڊ کي برقرار رکڻ سان minimalism جي رستي تي عمل ڪري ٿو، ۽ ڪو ماڻهو تمام گهڻي محنت ڪري ٿو جيڪو هو پهچي سگهي ٿو. جيتوڻيڪ اتي هڪ وچولي آپشن پڻ آهي جنهن کي چونڊڻ جي صلاحيت سان سڏيو ويندو آهي لاگنگ ليول، جڏهن توهان پاڻ اهو ظاهر ڪندا آهيو ته توهان ڪيتري تفصيلي معلومات کي ذخيرو ڪرڻ چاهيو ٿا ۽ توهان وٽ ڪيترو اضافي ڊسڪ اسپيس آهي =) وي بي آر ۾ ڇهه اهڙيون سطحون آهن. ۽، مون تي يقين ڪريو، توھان ڏسڻ نٿا چاھيو ته توھان جي ڊسڪ تي مفت جڳھ سان تمام تفصيلي لاگنگ سان ڇا ٿيندو.
ٺيڪ. اسان تقريبن سمجهي چڪا آهيون ته اسان ڇا بچائڻ چاهيون ٿا، پر هڪ جائز سوال پيدا ٿئي ٿو: اها معلومات ڪٿان حاصل ڪجي؟ يقينن، اسان اسان جي اندروني عملن جي ذريعي پاڻ کي لاگ ان ڪرڻ لاء واقعن جو حصو بڻائيندا آهيون. پر ڇا ڪجي جڏهن ٻاهرين ماحول سان رابطو هجي؟ ڪچين ۽ سائيڪلن جي جهنگ ۾ نه ڦاسڻ لاءِ، ويم ايجادون ايجاد نه ڪرڻ جو ارادو رکي ٿو جيڪي اڳ ۾ ئي ايجاد ٿي چڪيون آهن. جڏهن به هڪ تيار ڪيل API، بلٽ ان فنڪشن، لائبريري، وغيره آهي، اسان کي ترجيح ڏينداسين تيار ٿيل اختيارن کي ترجيح ڏينداسين اسان جي تضاد کي باهه ڏيڻ شروع ڪرڻ کان اڳ. جيتوڻيڪ پوئين به ڪافي آهي. تنهن ڪري، لاگز جو تجزيو ڪرڻ وقت، اهو سمجهڻ ضروري آهي ته غلطين جو وڏو حصو ٽئين پارٽي APIs، سسٽم ڪالز، ۽ ٻين لائبريرين جي پيغامن تي پوي ٿو. انهي حالت ۾، VBR جو ڪردار هيٺ اچي ٿو انهن غلطين کي اڳتي وڌائڻ لاءِ جيئن ته لاگ فائلون آهن. ۽ استعمال ڪندڙ جو بنيادي ڪم اهو سمجهڻ سکڻ آهي ته ڪهڙي لڪير ڪنهن کان آهي، ۽ هي "ڪير" ذميوار آهي. تنهن ڪري جيڪڏهن VBR لاگ مان هڪ غلطي ڪوڊ توهان کي MSDN صفحي ڏانهن وٺي وڃي ٿو، اهو ٺيڪ ۽ صحيح آهي.
جيئن ته اسان اڳ ۾ اتفاق ڪيو: Veeam هڪ نام نهاد SQL-based ايپليڪيشن آهي. هن جو مطلب اهو آهي ته سڀئي سيٽنگون، سڀ معلومات ۽ عام طور تي هر شيء جيڪا صرف عام ڪم ڪرڻ لاء ضروري آهي - هر شيء پنهنجي ڊيٽابيس ۾ ذخيرو ٿيل آهي. تنهن ڪري سادو سچ: جيڪو لاگس ۾ نه آهي اهو گهڻو ڪري ڊيٽابيس ۾ آهي. پر هي يا ته سلور بلٽ ناهي: ڪجهه شيون ويم اجزاء جي مقامي لاگن ۾ نه آهن، ۽ نه ئي ان جي ڊيٽابيس ۾. تنهن ڪري، توهان کي سکڻ جي ضرورت آهي ته ميزبان لاگز، لوڪل مشين جا لاگز ۽ هر شي جي لاگز جو مطالعو ڪيئن ڪجي جيڪو بيڪ اپ ۽ بحالي جي عمل ۾ شامل آهي. ۽ اهو به ٿئي ٿو ته ضروري معلومات ڪٿي به موجود نه آهي. اهو ئي طريقو آهي.
اهڙي APIs جا ڪجهه مثال
هي فهرست غير معمولي طور تي مڪمل ٿيڻ جو مقصد ناهي، تنهنڪري ان ۾ حتمي سچائي ڳولڻ جي ڪا ضرورت ناهي. ان جو مقصد صرف اسان جي پروڊڪٽس ۾ استعمال ٿيندڙ عام ٽئين پارٽي APIs ۽ ٽيڪنالاجيون ڏيکارڻ آهي.
اچو ته شروع ڪريون VMware.
فهرست ۾ پهريون نمبر هوندو vSphere API. تصديق لاءِ استعمال ڪيو ويو، درجه بندي پڙهڻ، سنيپ شاٽ ٺاهڻ ۽ حذف ڪرڻ، مشين بابت معلومات جي درخواست ڪرڻ، ۽ گهڻو ڪجهه (تمام گهڻو) وڌيڪ. حل جي ڪارڪردگي تمام وسيع آهي، تنهنڪري مان سفارش ڪري سگهان ٿو VMware vSphere API ريفرنس لاء نسخو и . وڌيڪ موجوده نسخن لاء، هر شيء صرف googled آهي.
VIX API. Hypervisor جو ڪارو جادو، جنهن لاء هڪ الڳ آهي . VMware API ميزبان تي فائلن سان ڪم ڪرڻ لاءِ انهن کي نيٽ ورڪ تي ڳنڍڻ کان سواءِ. هڪ آخري رزورٽ آپشن جڏهن توهان کي مشين ۾ فائل رکڻ جي ضرورت آهي جنهن ۾ ڪو به بهتر ڪميونيڪيشن چينل ناهي. اهو درد ۽ مصيبت آهي جيڪڏهن فائل وڏي آهي ۽ ميزبان لوڊ ٿيل آهي. پر هتي اهو اصول ڪم ڪري ٿو ته 56,6 Kb/s به 0 Kb/s کان بهتر آهي. Hyper-V ۾، هن شيء کي سڏيو ويندو آهي PowerShell Direct. پر اهو صرف اڳ هو
vSpehere ويب سروسز API vSphere 6.0 کان شروع ٿئي ٿو (تقريبن، ڇاڪاڻ ته هي API پهريون ڀيرو ورزن 5.5 تي متعارف ڪرايو ويو هو) اهو مهمان مشينن سان ڪم ڪرڻ لاءِ استعمال ڪيو ويندو آهي ۽ تقريبن هر هنڌ VIX کي اپلوڊ ڪيو آهي. حقيقت ۾، هي هڪ ٻيو API آهي vSphere کي منظم ڪرڻ لاء. انھن لاء جيڪي دلچسپي وٺندا آھن، مان پڙھڻ جي صلاح ڪريان ٿو دستور.
وي ڊي ڊي ڪي (ورچوئل ڊسڪ ڊولپمينٽ کٽ). لائبريري، جنهن ۾ جزوي طور تي بحث ڪيو ويو . ورچوئل ڊسڪ پڙهڻ لاءِ استعمال ڪيو ويو. هڪ دفعي اهو VIX جو حصو هو، پر وقت سان گڏ ان کي هڪ الڳ پيداوار ۾ منتقل ڪيو ويو. پر هڪ وارث جي طور تي، اهو ساڳيو غلطي ڪوڊ استعمال ڪري ٿو VIX. پر ڪجهه سببن لاء، SDK پاڻ ۾ انهن غلطين جي ڪا به وضاحت ناهي. تنهن ڪري، اهو محسوس ڪيو ويو ته تجرباتي طور تي VDDK غلطيون ٻين ڪوڊ سان گڏ صرف هڪ ترجمو آهي بائنري کان ڊيسيمل ڪوڊ تائين. اھو ٻن حصن تي مشتمل آھي - پھريون اڌ آھي غير دستاويزي معلومات جي حوالي سان، ۽ ٻيو حصو آھي روايتي VIX / VDDK غلطيون. مثال طور، جيڪڏهن اسان ڏسون ٿا:
VDDK error: 21036749815809.Unknown error
ان کان پوء اسان هن کي هيڪس ۾ تبديل ڪيو ۽ 132200000001 حاصل ڪيو. اسان صرف 132200 جي اڻ ڄاڻايل شروعات کي رد ڪريون ٿا، ۽ باقي اسان جي غلطي ڪوڊ (VDDK 1: اڻڄاتل غلطي). سڀ کان وڌيڪ بار بار VDDK غلطين جي باري ۾، اتي تازو ئي هڪ الڳ هو .
هاڻي اچو ته ڏسون ونڊوز.
هتي، هر شيء جيڪا اسان لاء تمام ضروري ۽ اهم آهي معيار ۾ ملي سگهي ٿي واقعي جي ڏي وٺ. پر اتي ھڪڙي پڪڙي آھي: ھڪڙي ڊگھي روايت موجب، ونڊوز غلطي جي مڪمل متن کي لاگ ان نٿو ڪري، پر صرف ان جو نمبر. مثال طور، غلطي 5 آهي "رسائي رد ڪئي وئي"، ۽ 1722 آهي "آر پي سي سرور دستياب ناهي"، ۽ 10060 آهي "ڪنيڪشن جو وقت ختم". يقينا، اهو تمام سٺو آهي جيڪڏهن توهان سڀ کان وڌيڪ مشهور ياد رکو ٿا، پر انهن بابت ڇا آهي جيڪي اڃا تائين غائب آهن؟
۽ انهي ڪري ته زندگي بلڪل ماکي وانگر نه لڳي، غلطيون پڻ هيڪساڊيڪل فارم ۾ ذخيرو ٿيل آهن، اڳيڪس 0x8007 سان. مثال طور، 0x8007000e اصل ۾ 14 آهي، ياداشت کان ٻاهر. اهو ڇو ۽ ڪنهن لاءِ ڪيو ويو اهو هڪ راز آهي اونداهي ۾ ڍڪيل آهي. بهرحال، غلطين جي مڪمل فهرست مفت ۾ ڊائون لوڊ ڪري سگھجي ٿو ۽ بغير ايس ايم ايس کان .
رستي جي ذريعي، ڪڏهن ڪڏهن ٻيون اڳڪٿيون آهن، نه رڳو 0x8007. اهڙي اداس صورتحال ۾، HRESULT (“نتيجو هينڊل”) کي سمجهڻ لاءِ، توهان کي اڃا به وڌيڪ اونهائي ۾ وڃڻو پوندو. ڊولپرز لاء. عام زندگي ۾، مان توهان کي اهو ڪرڻ جي صلاح نه ٿو ڏيان، پر جيڪڏهن توهان اوچتو ڀت جي خلاف دٻايو يا صرف مشغول آهيو، هاڻي توهان کي خبر آهي ته ڇا ڪجي.
پر Microsoft جي ڪامريڊن اسان تي ٿورو رحم ڪيو ۽ دنيا کي هڪ افاديت ڏيکاري . هي هڪ ننڍڙو ٽڪرو آهي ڪنسول خوشي جو جيڪو ترجمو ڪري سگهي ٿو غلطي ڪوڊس کي انسان ۾ گوگل استعمال ڪرڻ کان سواءِ. اهو هن طرح ڪم ڪري ٿو.
C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"هڪ جائز سوال پيدا ٿئي ٿو: اسان فوري طور تي لاگ ان کي ڊسڪشن ڇو نه لکون، پر اهي پراسرار ڪوڊ ڇڏي ڏيو؟ جواب ٽئين پارٽي جي ايپليڪيشنن ۾ آهي. جڏهن توهان ڪجهه WinAPI ڪال پاڻ کي ڇڪيندا آهيو، ان جي جواب کي سمجهڻ ڏکيو ناهي، ڇو ته هن لاء پڻ هڪ خاص WinAPI ڪال آهي. پر جيئن اڳ ۾ ئي ذڪر ڪيو ويو آهي، هر شي جيڪا صرف اسان جي جوابن ۾ اچي ٿي اسان جي لاگن ۾ اچي ٿي. ۽ هتي، ان کي ڊيڪرپٽ ڪرڻ لاءِ، ڪنهن کي مسلسل شعور جي هن وهڪري جي نگراني ڪرڻي پوندي، ان مان ونڊوز جي غلطين جا ٽڪرا ڪڍي، انهن کي ڊيڪرائٽ ڪري واپس پيسٽ ڪرڻو پوندو. اچو ته ايماندار ٿي، سڀ کان وڌيڪ دلچسپ سرگرمي نه.
ونڊوز فائل مئنيجمينٽ API هر ممڪن طريقي سان استعمال ڪيو ويندو آهي جڏهن فائلن سان ڪم ڪندي. فائلون ٺاهڻ، حذف ڪرڻ، لکڻ لاءِ کولڻ، خاصيتن سان ڪم ڪرڻ، وغيره وغيره.
مٿي ذڪر ڪيو ويو آهي پاور شيل سڌو Hyper-V دنيا ۾ VIX API جي اينالاگ جي طور تي. بدقسمتي سان، ايترو لچڪدار ناهي: ڪارڪردگي تي تمام گهڻيون پابنديون، اهو ڪم نه ڪندو آهي ميزبان جي هر نسخي سان ۽ نه سڀني مهمانن سان.
آر پي سي (Remote Procedure Call) مان نه ٿو سمجهان ته ڪو اهڙو ماڻهو آهي جنهن ونڊوز سان ڪم ڪيو هجي جنهن RPC سان لاڳاپيل غلطيون نه ڏٺيون هجن. مشهور غلط فڪر جي باوجود، هي هڪ واحد پروٽوڪول ناهي، پر ڪو به ڪلائنٽ-سرور پروٽوڪول آهي جيڪو ڪيترن ئي پيٽرولن کي پورو ڪري ٿو. تنهن هوندي، جيڪڏهن اسان جي لاگن ۾ هڪ RPC غلطي آهي، وقت جو 90٪ اهو Microsoft RPC کان هڪ غلطي هوندي، جيڪو DCOM جو حصو آهي (تقسيم ٿيل اجزاء اعتراض ماڊل). توھان نيٽ تي ھن موضوع تي وڏي تعداد ۾ دستاويز ڳولي سگھو ٿا، پر ان جو وڏو حصو ڪافي پراڻو آھي. پر جيڪڏهن موضوع جو مطالعو ڪرڻ جي شديد خواهش آهي، ته آئون مضمونن جي سفارش ڪري سگهان ٿو , ۽ ڊگهي لسٽ .
اسان جي لاگن ۾ RPC غلطين جا بنيادي سبب VBR اجزاء (سرور> پراکسي، مثال طور) جي وچ ۾ رابطي جي ناڪام ڪوششون آهن ۽ اڪثر ڪري مواصلاتي مسئلن جي ڪري.
سڀني مٿين جي وچ ۾ مٿين مٿين غلطي آهي RPC سرور دستياب ناهي (1722). سادي اصطلاحن ۾، ڪلائنٽ سرور سان ڪنيڪشن قائم نه ڪري سگهيو. ڪيئن ۽ ڇو - ڪو به واحد جواب ناهي، پر عام طور تي اهو مسئلو آهي تصديق ڪرڻ سان يا نيٽ ورڪ جي رسائي سان 135 تائين. بعد ۾ اهو عام آهي بنيادي اڏاوتن لاءِ متحرڪ پورٽ اسائنمينٽ سان. هن موضوع تي، اتي به آهي . ۽ Microsoft وٽ آهي ناڪامي جو سبب ڳولڻ لاء.
ٻيو سڀ کان وڌيڪ مشهور غلطي: آخري پوائنٽ ميپر (1753) کان وڌيڪ آخري پوائنٽ موجود نه آهن. RPC ڪلائنٽ يا سرور پاڻ کي هڪ پورٽ تفويض ڪرڻ ۾ ناڪام ٿيو. عام طور تي تڏهن ٿئي ٿو جڏهن سرور (اسان جي صورت ۾، مهمان مشين) کي ترتيب ڏنو ويو آهي متحرڪ طور تي مختص بندرگاهن کي هڪ تنگ حد کان جيڪو ختم ٿي چڪو آهي. ۽ جيڪڏهن توهان ڪلائنٽ جي پاسي کان لاگ ان ڪريو ٿا (اسان جي صورت ۾، VBR سرور)، ان جو مطلب آهي ته اسان جو VeeamVssAgent يا ته شروع نه ٿيو يا RPC انٽرفيس طور رجسٽر ٿيل نه هو. هن موضوع تي پڻ موجود آهي .
چڱو، مٿين 3 RPC غلطين کي مڪمل ڪرڻ لاء، اچو ته ياد رکون RPC فنڪشن ڪال ناڪام (1726). ظاهر ٿئي ٿو ته ڪنيڪشن قائم ڪيو ويو آهي، پر RPC درخواستن تي عمل نه ڪيو ويو آهي. مثال طور، اسان VSS جي حيثيت بابت معلومات جي درخواست ڪريون ٿا (اوچتو هاڻي اتي هڪ شيڊ مائن ٺاهيو پيو وڃي، ۽ اسان چڙهڻ جي ڪوشش ڪري رهيا آهيون)، ۽ اسان جي جواب ۾، خاموش ۽ نظر انداز.
ونڊوز ٽيپ بيڪ اپ API ٽيپ لائبريرين يا ڊرائيو سان ڪم ڪرڻ جي ضرورت آهي. جيئن ته مون شروع ۾ ذڪر ڪيو آهي: اسان کي اسان جي پنهنجي ڊرائيور لکڻ ۾ ڪا به خوشي ناهي ۽ پوء هر ڊوائيس جي حمايت سان مصيبت آهي. تنهن ڪري، ويم وٽ پنهنجو ڪو ڊرائيور ناهي. سڀ هڪ معياري API جي ذريعي، جنهن جي حمايت هارڊويئر وينڊرز طرفان لاڳو ڪئي وئي آهي. ايترو وڌيڪ منطقي، صحيح؟
ايس ايم ايس / سي ايف ايس عادت کان ٻاهر، هرڪو انهن کي پاسي سان لکندو آهي، جيتوڻيڪ هر ڪنهن کي ياد ناهي ته CIFS (عام انٽرنيٽ فائل سسٽم) صرف SMB (سرور ميسيج بلاڪ) جو هڪ خانگي نسخو آهي. تنهن ڪري انهن تصورن کي عام ڪرڻ ۾ ڪجھ به غلط ناهي. سامبا اڳ ۾ ئي هڪ لينڪس يونڪس تي عمل درآمد آهي، ۽ ان کي پنهنجون خاصيتون آهن، پر مان سمجهان ٿو. هتي ڇا اهم آهي: جڏهن ويم پڇي ٿو ڪجهه لکڻ لاءِ UNC رستي (serverdirectory)، سرور استعمال ڪري ٿو فائيل سسٽم ڊرائيورن جو درجو، بشمول mup ۽ mrxsmb، بال تي لکڻ لاءِ. ان مطابق، اهي ڊرائيور به غلطيون پيدا ڪندا.
بغير نٿو ڪري سگهان Winsock API. جيڪڏهن نيٽ ورڪ تي ڪجهه ڪرڻ جي ضرورت آهي، VBR ونڊوز ساکٽ API ذريعي ڪم ڪري ٿو، مشهور طور تي Winsock جي نالي سان مشهور آهي. تنهن ڪري جيڪڏهن اسان ڏسون ٿا IP جو هڪ گروپ: پورٽ لاگ ان ۾، اهو آهي. سرڪاري دستاويز ۾ ممڪن جي سٺي فهرست آهي .
مٿي ذڪر ڪيو ويو آهي WMI (Windows Management Instrumentation) ونڊوز جي دنيا ۾ هر شيءِ ۽ هر ڪنهن کي منظم ڪرڻ لاءِ هڪ قسم جو غالب API آهي. مثال طور، جڏهن Hyper-V سان ڪم ڪري رهيو آهي، ميزبان کي لڳ ڀڳ سڀئي درخواستون ان جي ذريعي وڃو. هڪ لفظ ۾، شيء بلڪل irreplaceable ۽ ان جي صلاحيتن ۾ تمام طاقتور آهي. ڳولڻ ۾ مدد ڪرڻ جي ڪوشش ۾ ڪٿي ۽ ڇا ڀڄي ويو آهي، تعمير ٿيل WBEMtest.exe اوزار تمام گهڻو مدد ڪري ٿو.
۽ لسٽ تي آخري، پر ڪنهن به لحاظ کان گهٽ ۾ گهٽ اهميت ۾ - VSS (حجم شيڊ اسٽوريج). اهو موضوع جيترو اڻپورو ۽ پراسرار آهي، اوترو ئي ان تي دستاويز لکيا ويا آهن. شيڊ ڪاپي کي تمام گهڻو سمجھيو ويندو آهي هڪ خاص قسم جي سنيپ شاٽ جي طور تي، جيڪو اصل ۾ اهو آهي. هن جي مهرباني، توهان ڪري سگهو ٿا ايپليڪيشن-مسلسل بيڪ اپ VMware ۾، ۽ تقريبا هر شيء Hyper-V ۾. مون کي VSS تي ڪجهه دٻاء سان هڪ الڳ مضمون ٺاهڻ جو منصوبو آهي، پر هاڻي توهان پڙهڻ جي ڪوشش ڪري سگهو ٿا . بس محتاط ٿي، ڇاڪاڻ ته. هڪ فليش ۾ VSS کي سمجهڻ جي ڪوشش ڪري سگھي ٿو دماغي زخم.
هن تي، شايد، اسان روڪي سگهون ٿا. مان سمجهان ٿو ته سڀ کان وڌيڪ بنيادي شين جي وضاحت ڪرڻ جو ڪم مڪمل ڪيو ويو آهي، تنهنڪري ايندڙ باب ۾ اسين اڳ ۾ ئي لاگ ان کي ڏسنداسين. پر جيڪڏهن توهان وٽ ڪي سوال آهن، انهن کان پڇڻ لاء آزاد محسوس ڪريو تبصرن ۾.
جو ذريعو: www.habr.com