راه اندازی نرم افزار بلادرنگ(RealTime) و آشنایی با نحوه عملکرد سوکت

شاید تا به حال راه اندازی یک نرم افزار بلادرنگ(RealTime) ذهن شما را به خود مشغول کرده باشد. راه اندازی یک نرم افزار همانند پیامرسان و یا نرم افزاری که با وقوع رویدادهایی مشخص، به صورت آنی بتواند خود را به روز رسانی کند. برای درک بهتر یک نرم افزار بلادرنگ، میتوانید یک پیامرسان و یا داشبورد خدمات بازار سرمایه گذاری را تصور کنید.  زمانی که سهام در لحظه دچار تغییر قیمت میشود، باید داشبورد مربوطه در آن واحد به روز رسانی شود تا نیازمندی های مربوط به این حوزه به درستی ارائه شود. و یا یک پیامرسان که با ارسال پیام از یک مبدا به یک مقصد ، باید نرم افزار به صورت آنی در هر دو طرف به روزسانی شود. نه تنها با ارسال پیام، بلکه با مشاهده یک پیام توسط کاربر مقصد، باید ارسال کننده پیام از این موضوع مطلع شود که این عملیات با تغییر تعداد تیک های کنار پیام رخ میدهد. به این گونه نرم افزارها که در آن واحد و بر اساس رویدادهایی که به وقوع میپیوندد خود را به روز رسانی میکنند بلادرنگ گفته میشود.
در حالت عادی و از طریق پروتکل HTTP امکان پیاده سازی سیستم بلادرنگ وجود ندارد چرا که در این پروتکل هر درخواست تنها و تنها از طریق Client آغاز میشود و سپس با دریافت پاسخ درخواست از سرور پایان میابد.(برای مطالعه بیشتر با پروتکل HTTP اینجا کلیک کنید.)
فرض کنید در یک پیام رسان ، شخص A یک پیام به شخص B ارسال کند. در این سناریو در حالت ساده A و B کلاینت هستند و یک سرور اتصال میان این دو را برقرار میسازد. با ارسال پیام از شخص A، اطلاعات مربوط به پیام (به طور مثال متن و مشخصات گیرنده پیام)، به سرور ارسال میشود. تا به اینجای سناریو مشکلی وجود ندارد و از طریق پروتکل HTTP قابل کنترل است، چرا که Client در حال ارسال یک داده به سرور است. اما وقتی پیام به سرور رسید، حالا سرور باید به کلاینت B پیام دریافت شده را ارسال کند. با پروتکل HTTP نمیتوان از سرور به کلاینت پیامی ارسال کرد، بنابراین استفاده از این پروتکل در این سناریو ممکن نیست. در موارد این چنینی باید از سوکت استفاده نمود. 
 

سوکت چیست؟

آشنایی با وب سوکت

سوکت را میتوان یک روش برای برقراری ارتباط میان دو ماشین دانست و در لایه پایین تر از پروتکل های HTTP و ... قرار دارد. به زبان دیگر پروتکل HTTP مجموعه قراردادهایی است که بر روی ارتباط سوکت قرار میگیرد و ارتباط را مشروط به قواعد خود میکند. در واقع در پروتکل HTTP به زبان عامیانه چنین  قانونی مینشیند. "کلاینت باید از طریق سوکت، درخواستی به سرور بفرستد و سرور پاسخی به همراه سایر داده های کنترلی به او بازگرداند و ارتباط تمام شود." در واقع پروتکل HTTP از سوکت استفاده میکند و قوانین خود را به عنوان یک پروتکل استاندارد و جهانی بر آن مسلط میکند. حال برای این که بتوانیم یک ارتباط پایدار میان سرور و کلاینت ایجاد کنیم که هر دو بتوانند در زمان مناسب ارتباطی را با دیگری آغاز کنند، نیاز داریم تا از خود سوکت استفاده کنیم. 


سوکت چگونه کار میکند؟
در یک ارتباط سوکت ابتدا یک Handshake میان طرفین ارتباط اتفاق می افتد و سپس این دو به یک دیگر متصل باقی میمانند و ارتباط تا زمانی که هر یک از طرفین نخواهند و یا خطایی روی ندهند قطع نخواهد شد. در این ارتباط همیشه متصل، هر زمان که کلاینت نیاز داشته باشد، به سرور پیامی را ارسال میکند و همینطور هر زمان سرور بخواهد به کلاینت پیامی را ارسال (Push)میکند. 
حال سناریوی ارسال پیام را اگر بخواهیم با پروتکل سوکت مطرح کنیم، ابتدا A پیامی را به سرور با مقصد نهایی B ارسال میکند. سرور نیز که از قبل به B متصل است و ارتباط پایداری میان این دو برقرار است، اطلاعات لازم را به B میفرستد و آن را از پیام ارسالی آگاه میکند.در صورت قطع شدن ارتباط میان سرور و کلاینت به دلیل خطا قطع شود، کلاینت فورا Handshake را با سرور انجام داده و خود را متصل میکند.
 

Handshake چیست؟

Handshake با سرور

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

مشکل Performance و یک چالش عملیاتی

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

نظر خود را بنویسید.