Dev Perfects

Forwarded from a pessimistic researcher (Kc)

" پر Cite ترین مقاله لمپورت"
بخش اول
—————————————————

یادمه یه بار با Leslie Lamport مصاحبه کرده بودند و ازش پرسیده بودن چرا انقدر توی Concurrency Theory گولاخی و رو دستت نیست ؟ :))))
ایشونم اول شکسته نفسی میکرد و بعدش گفت به نظرم دلیل اصلیش اینه که مسائل حوزه Distributed Systems و Concurrency Theory که شاکله اصلیش مفهوم زمان هستش رو من به چشم یک مسئله فیزیک میبینم ولی دیگران به چشم یک مسئله ریاضی.

منم مثل شما اولش نفهمیدم که این چیه میگه و فازش چیه. تا اینکه رفتم سراغ پر Cite ترین مقاله ایشون. این مقاله تا این لحظه که من دارم براتون این پست رو مینویسم ۱۲۹۸۰ تا Cite خورده :))))))))))))

یادمه توی یه مصاحبه هم خودش گفته بود خودمم درک نمیکنم چرا انقدر این مقاله رو دانشمندا دوست دارن. شاید چیزی توش دیدن که من خودم ندیدم :)))

حالا داستان این مقاله که در انتهای این پست فایلش رو براتون قرار میدم چیه؟
ایده ای که باعث شد آقای لمپورت دست به قلم بشه و این مقاله رو بنویسه از اینجا ناشی میشه که :
دو تا از محققین IBM به نام های Paul Johnson و Robert Thomas میان که مشکل اصلی یکی از محصولات IBM رو حل کنن. داستان اینه که IBM یک محصول داشته به اسم TIP که مخفف این عبارته :
Tivoli Integrated Portal
شرکت IBM کلی محصول داشت و کاربر ها موقعی که میخواستن از هر کدوم استفاده کنن مجبور میشدن برای هر کدوم یک بار عمل Authentication رو انجام بدن. شرکت IBM گفت که چه کاریه من بیام یک سیستم یکپارچه برای Authentication بنویسم که کاربرا یک بار Authenticate بشن و بعد از اون بتونن از همه محصولات استفاده کنن. واسه همینم میاد TIP رو میسازه. مشکل اینجا بود که این TIP میومد از یک سری دیتابیس Replicate شده روی شبکه ARPA-like استفاده میکرد و دنبال ارائه یک الگوریتم بودن تا بتونن به شکل Consistent این دیتابیس ها رو Maintain کنن.
میان یک الگوریتم مبتنی بر مکانیزم Timestamp میسازن. یعنی هر Event یا هر Request که میومد به سمت این دیتابیس یک Timestamp میخورد و به نوعی فکر کردن میتونن بین این Event ها یا همون Request ها یک رابطه Totally Order برقرار کنن.

سخت شد ؟ :)))))
حالا این رابطه Totally Order چی هست اصلا؟ اگر وضع تون خیلی خرابه برید سکشن 9.1 و 9.6 کتاب ریاضی گسسته روزن رو بخونید. اما اگر اوضاع تون انقدر ها هم وخیم نیست توجه تون رو به ادامه مطلب جلب میکنم :)))

ما توی ریاضیات به رابطه ای که خواص Reflexivity و AntiSymetric و Transitive رو داشته باشه میگیم یک رابطه Partial Order . به طور مثال رابطه کوچک یا بزرگ تر بودن اعداد یک نوع رابطه Partial Order عه (البته ما دو نوع رابطه Partial Order داریم اینی که من تعریف کردم رو بهش میگن Weak Partial Order و اینی که من تعریف کردم اگر به جای Reflexivity از نوع Irreflexive باشه بهش میگن Strong Partial Order ولی حالا خیلی مهم نیست و به قول یکی از دوستانم Any way :))))) )

حالا اگر به ازای هر دو عضو از مجموعه ای ک درگیر رابطه Partial order هست ما بتونیم اون دو تا رو Compare کنیم یا به اصطلاح Comparable باشن میگیم اون رابطه Totally Order هستش.

زبونم مو در آورد تا بهتون بگم که اون دو نفر ای که مسئله Replicated Database رو میخواستن حل کنن دیدشون این بود که بین Request هایی که داره به سمت دیتابیس میرن این رابطه Totally Order برقراره و میشه تعیین کرد که هر Event ای قبل یا بعد از چه Event ای رخ داده.

از اونجایی که فکر میکردن خیلی کار گولاخی کردن گفتن این مسئله فقط محدود به محصول TIP نمیشه و هر نوع دیتابیس توزیع شده ای رو می تونیم اینطوری Maintain کنیم.

بعد اینکه کلی جشن گرفتن و خوشحالی کردن رفتن این مقاله رو در قالب یک RFC با شماره 677 منتشر کردن.(دلیلش این بود که این الگوریتم فقط بر روی شبکه های ARPA-Like جواب می داد)

آقای لمپورت که لیسانس فیزیک خونده بود و قضیه نسبیت آقای انیشتن رو بلد بود فهمید که این دو نفر Bullshit گفتن :)))))

حالا آقای لمپورت دید جامعه CS که نسبیت نمی فهمن چیه اومد توی این مقاله باهامون کامپیوتری صحبت کرد.

گفت که عزیزان شما وقتی میگید که یک رخداد مانند a قبل از یک رخداد مانند b اتفاق افتاده، در اصل دارید بر اساس پارامتر زمان فیزیکی این رو میگید. خب حالا ما باید برای هر کدم از این Process هایی که توی سیستم مون داریم یک Physical Timer بذاریم ولی خب چه تضمینی هست که اینا دقیق و هماهنگ با همدیگه کار کنن؟ ثانیا خیلی از سیستم های نرم افزاری از تایمر های دیجیتال استفاده میکنند که اون دیگه خیلی فاجعه تره.

2 views12:16