سوییچینگ!

سریع و بی‌مقدمه مثل همیشه :دی

برای انتقال داده‌ها چندتا روش موجود هست. این زیر معرفی می‌شن:

۱. س[ی]رکِت سوییچینگ یا Circuit Switching

اولین نوع مورد بررسیمون به این شکل صورت می‌گیره که داده‌هایی که قراره منتقل بشن رو در قالب یه چیز واحد (و نه تیکه تیکه. دلیل این اشاره چلوتر مشخص می‌شه.) فرستاده می‌شه روی خطوط انتقال (سرکت! مداری که تعبیه شده واسه این کار) و اونجا توسط سوییچ‌های موجود که عملکردشون شبیه مالتی‌پلکسرها هست، مسیرشون مشخص می‌شه. مثلا بین نقطه اول و نقطه آخر سه تا تصمیم‌گیر(مالتی‌پلکسر) داریم و داده‌ی ما اطلاعاتی رو شامل می‌شه که تصمیم‌گیرها بتونن کارشونو انجام بدن.

سناریوی فرضی: فرض کنین یه داده داریم که همراه خودش کد ۴۱۵ رو حمل می‌کنه. می‌فرستیمش روی خط انتقال (حالا سیم مسی، موج رادیویی، یا هر چی) و بعد از طی مقداری از مسیر می‌رسه به اولین تصمیم‌گیر. اولین تصمیم گیر یه ورودی و هشت خروجی داره. اولین رقم کدی که داشتیم ۴ هست. اولین تصمیم‌گیر داده‌امون رو به ۴ امین خروجی هدایت می‌کنه و داده مسیرشو ادامه می‌ده تا می‌رسه به دومین تصمیم‌گیر که اولین مسیر خروجی انتخاب می‌شه و همینجوری تا آخر که داده‌امون می‌رسه به خروجی ۴۱۵! دیتا استراکچرِ درخت رو تداعی می‌کنه :>

روش قدیمی‌ای هست و برای مثال روی خطوط تلفن استفاده می‌شه. مثلا وقتی شماره می‌گیریم ۰۰۹۸۲۱۱۲۳۴۵۶۷۸، خط تلفن از ۰۰۹۸ متوجه می‌شه که مال ایرانه پس وصلمون می‌کنه به اون تصمیم‌گیری که خروجیش می‌رسه به همه خطوط تلفن موجود تو ایران، بعد ۲۱ که متوجهش می‌کنه مقصدمون تو تهرانه و همینجوری ادامه می‌ده تا به اون نقطه‌ای برسه که شماره‌اش ۰۰۹۸۲۱۱۲۳۴۵۶۷۸ هست.

۲. مسِج سوییچینگ یا Message Switching

این روش نسبت به قبلی جدیدتره و یکم عجیب غریب به نظرم. پیاده‌سازیش اینجوریه که همه مبداها و مقصدها یه نود (گره) فرض می‌شن و همه‌اشون نقش اساسی‌ای دارن توی انتقال داده (که اینجا بهش می‌گیبم پیام!)

سناریوی فرضی: فرض کنین می‌خوایم یه پیام رو از مشهد به تبریز بفرستیم. پیام توی مشهد (مبدا) آماده ارسال می‌شه و اطلاعاتی مثل زمان انقضا، اطلاعات ارسال و دریافت، آدرس مبدا و مقصد، مقدار اهمیت و اینجور چیزها بهش الصاق می‌شن. پیام از مبدا فرستاده می‌شه به گره (شهر!) بعدی که حالا بگیم سمنانه. پیام توسط مرکز سمنان به طور کامل (و باز هم نه تیکه تیکه) دریافت می‌شه. گره بعدی تهرانه ولی یه مشکلی هست: مرکز تهران خیلی شلوغه. پیام‌هایی در حال مدیریت‌شدن هستن که زودتر رسیدن یا مهمترن. پیام نمی‌تونه به مرکز تهران منتقل بشه، خب پس نمی‌شه :دی صبر می‌کنیم تا سرش خلوت شه. هر وقت آماده دریافت بود به سمنان می‌گه و پیام بالاخره ارسال و توسط مرکز تهران دریافت می‌شه. همین داستان ادامه پیدا می‌کنه تا "گره بعدی" و "گره مقصد" یکی بشن. خیلی ضایع‌است ولی هر وقت که داشتیم:

(nxt == dst) = True #next node = destination node

اونوقته که متوجه می‌شیم داستان تمومه. با شرط آمادگی گره مقصد، پیام ارسال و دریافت می‌شه و کل پروسه انتقال حالا تموم شده :دی

در کل چیز عجیب غریب و ناکارآمدیه (هرچند از قبلی بهتر!) چون هم کُنده، هم هر گره باید کلی کار انجام بده (دریافت، ذخیره، بررسی گره بعد، ارسال،...) و هم فضای زیادی می‌خواییم (چون کل پیام ذخیره می‌شه. همه گره‌ها باید کلی جا داشته باشن تا یه وقت کم نیاد).

روش آخر، جدیدترین، بهینه‌ترین و (فعلا) بهترین:

۳. پَکِت سوییچینگ یا Packet Switching

داستان این شکلیه که اممم...

همون سناریوی فرضی رو بریم، بهتره فکر کنم :>

فرض کنین می‌خواین یه وویس واسه من توی واتس‌اپ بفرستین. ضبطش که تموم شد سیستم می‌بینه که ۸ ثانیه شده. فایل رو تقسیم می‌کنه (dissemble) و هر یک ثانیه می‌شه یه قسمت(هاها، دیگه تیکه تیکه نه. این بود قضیه :) ) هر قسمت هم شامل اطلاعاتی هست، از جمله مهم‌هاش اینکه:

الف. اون فایلِ بزرگی که این تیکه یه قسمتی ازشه، چند تیکه شده؟ (که اینجا ۸ تیکه شده) تعداد کل تیکه‌ها یعنی.

ب. این قسمتِ مذکور چندمین تیکه از اون فایل بزرگه‌اس؟ (معمولا متغیر #seq) (ترتیب قطعا مهمه. چون همونجوری که تو مبدا تیکه تیکه جدا شد، باید تو مقصد تیکه تیکه به هم وصل بشن)

سایر ابجد هم باشه واسه اطلاعات بدیهی دیگه مثل آدرس مبدا و مقصد و این چیزا :>

خلاصه همینطوری این قسمت‌ها (packet ها) می‌رن و می‌رسن به مقصد و وقتی رسیدن، با توجه به اطلاعاتی که همراه خودشون دارن باز-سرهم‌بندی (reassemble) می‌شن و من می‌تونم صداتونو بشنوم :دی

البته همیشه اینقدر گل و بلبل نیست و ممکنه packetها گم بشن، مسیر اشتباهی برن و کلی مشکل دیگه؛ ولی ایده‌آلش همینیه که بالا هست.

حسن ختام جلسه: 49 سال پیش -امروز- جیم موریسون رو بخاطر "کفر علنی و عورنمایی ناشایست" روی استیج دستگیر کردن.

تعطیلات خوش بگذره :دی