EnKamran
دوشنبه 11 اردیبهشت 1391, 19:00 عصر
سلام دوستان من یه پروژه ای داشتم انجام میدادن مه نیاز بود اطلاعات هر چند ثانه واکشی بشه اونم فقط واسه خاطر یک فیلد که تغییر میکرد خلاصه خیلی زورم میومد که به خاطر یک فیلد کل دیتالیستم رو دوباره بایند کنم گشتم و به این کامیت و پوش رسیدم، دوستان تو StackOverFlow امر فرمودن از این تکنولوژی استفاده کنیم که خوب دقیقا همونی هیت که میخوام، حالااااا اصل مطلب اینه که هرکی هرچی داره رو کنه لطفا ببینیم چیزی از توش در میاد یا نه.
تو تالار PHP که یه دوستمون آموزش داده بودن.
اولشم خودم میگم.
یا بذارین همونو کپی کنم خوب توضیح داده بود :
خب حالا این کامیت اصلا برای چی بوجود آمد.
ببینید، ما در وب استاندارد و مرورگرها یک روش و امکانات محدود و ساده ای داریم به این صورت که اگر ما/مرورگر به چیزی/اطلاعاتی نیاز داره، درخواستی (Request) برای اون چیز به سرور سایت مورد نظر ارسال میکنه و بعد اگر جواب (Response) درست وجود داشته باشه (منبع داده ای موجود باشه و ما اجازهء دسترسی بهش رو داشته باشیم) یک پاسخ حاوی دیتای مورد نظر به مرورگر فرستاده میشه و اگر هم جواب درست وجود نداشته باشه، یک کد و پیام خطا برمیگرده و ارتباط HTTP جاری در همین نقطه پایان یافته تلقی میشه.
اگر اون اطلاعات ممکنه در هر زمانی بر روی سرور قرار بگیره که پیشبینی دقیق اون ممکن نیست (بطور مثال پیغامهای طرف مقابل در یک چت)، پس ما مجبوریم مدام در فواصل زمانی معین این کار رو انجام بدیم؛ یعنی درخواست بفرستیم تا ببینیم اطلاعاتی برای ما ارسال شده یا نه و پاسخ موفق یا ناموفق دریافت کنیم.
این عملیات شبیه این هست که مدام منتظر دریافت نامه یا نامه های مهم و فوری از ادارهء پست باشیم و مجبور باشیم برای چک کردن دریافت اون نامه ها مدام در فواصل زمانی کوتاه به ادارهء پست مراجعه کنیم یا باهاشون تماس بگیریم و بگیم «اگر برای من نامه ای اومده لطفا اونو بهم بدید/بگید».
این عملیات ارسال درخواست و دریافت پاسخی که فقط گاهی پاسخ موفق هست، موجب اتلاف منابع سخت افزاری سرور و کلاینت و مصرف پهنای باند بیشتر و نیز تاخیر زمانی بیشتر میشه. یعنی این وسط کلی کار تکراری و بیهوده انجام شده. ضمنا اگر ما بخوایم از ایجاد یا تغییر اطلاعات مورد نظر در روی سرور خیلی سریع مطلع بشیم، نیاز داریم تا این عملیات رو در فواصل زمانی کوتاه انجام بدیم که این میتونه این وضعیت رو بدتر کنه و حتی مشکلات فنی در هر دو سمت کلاینت و سرور ایجاد کنه. فرضا ما هر یک ثانیه بخوایم یک درخواست بفرستیم و پاسخ بگیریم، این هم مصرف منابع و فشار پردازشی روی کلاینت داره و هم روی سرور و هم سرورهای استاندارد وب برای چنین درخواست و پاسخهای سریع و دائمی با یک کلاینت درنظر گرفته نشدن و اولویت بندی خودشون رو دارن و ممکنه درخواست ما رو توی صف انتظار بذارن و با تاخیر خیلی بیشتری از اون چیزی که مد نظر ما بوده بهش جواب بدن، و شاید حتی ممکن باشه بعضی نرم افزارهای امنیتی و فایروالها نسبت به این ارتباطهای دائمی و سریع مشکوک بشن و مشکلی پیش بیاد (این مورد بنظر خودم رسید). خلاصه این روش بخصوص وقتی هدف مطلع شدن از هر تغییر در هر زمان نامعین در سرور با حداکثر سرعت ممکن باشه، مناسب بنظر نمیاد.
خب مثال رفتن یا تماس با ادارهء پست چیز خوبی بود.
ما میتونیم بجای اینکه خودمون مدام با ادارهء پست تماس بگیریم به اونا بگیم که به محض اینکه نامه ای برای ما دریافت کردن بهمون اطلاع بدن (البته برای این کار احتمالا باید آشنایی چیزی در ادارهء پست داشته باشید یا سر کیسه رو شل کنید!!).
روش Comet هم چنین چیزی رو با ترفند پیاده سازی میکنه. با ترفند این کار رو میکنه، چون در وب سرورهای معمولی و مرورگرها امکانات سر راست و استانداردی برای اینطور کارها پیشبینی نشدن.
در روش Comet ما یک درخواست برای شروع ارتباط، به سرور ارسال میکنیم، چون بعلت محدودیت های مرورگرها و سرورها و پروتکل HTTP در این زمینه امکان شروع ارتباط از سمت سرور با کلاینت وجود نداره (البته ظاهرا در آیندهء نه چندان دور شاهد استانداردها و امکانات جدیدی در این زمینه خواهیم بود).
وقتی ما درخواست رو به سرور ارسال کردیم، سرور به ما پاسخ فوری نمیده (مگر اینکه اطلاعات مورد نظر همون لحظه در دسترس باشن). سرور بجای اینکه به ما پیام عدم وجود اطلاعات رو بده، ما رو منتظر میذاره و تکلیف ارتباط HTTP رو مشخص نمیکنه. سرور و مرورگر تا هر وقت بتونن و چیزهایی مثل Timeout و غیره جلوشون رو نگیرن این ارتباط رو باز و بلاتکلیف نگه میدارن، مثلا ممکنه چند دقیقه یا حتی بصورت نامحدود این ارتباط باز بمونه و مرورگر همچنان در انتظار پاسخ از جانب سرور. اما سرور در این اثناء در پشت صحنه داره مدام ورود اطلاعات مورد نظر به سرور یا رخ دادن شرایط لازم رو چک میکنه و به محض اینکه شرایط لازم مهیا شد، اطلاعات مورد نظر رو بعنوان پاسخ درخواست ما از طریق کانکشن باز مونده بهمون ارسال میکنه.
این حالت احتمالا مثل اینه که شما زنگ بزنید به ادارهء پست و اونا بهتون جوابی ندن ولی گوشی رو هم قطع نکنن، و بعد هر دو طرف منتظر بمونن و به محض اینکه متصدی ادارهء پست نامهء ای برای شما دریافت کرد به شما اعلام بکنه (البته شما هم باید پای گوشی منتظر باشید).
این سناریویی که بنده گفتم البته یکی از روشهای پیاده سازی کامیت هست که معمولا با استفاده از AJAX در پشت صحنهء صفحه اجرا میشه و بهش Long polling گفته میشه.
روشهای دیگری هم هست و روشهایی که میشه از طریق یک ارتباط تعداد نامحدودی پاسخ رو در زمانهای مختلف دریافت کرد، ولی اونا مشکلات پیاده سازی یا مشکل ساپورت مرورگر و اینها رو دارن اکثرا.
بنابراین ما در این تاپیک به روش Long polling میپردازیم و از شرح بقیهء روشها بخاطر پرهیز از حجم و پیچیدگی و انحراف تاپیک اجتناب میکنیم.
خب در روش Long polling از هر ارتباط باز تنها برای یک پاسخ میشه استفاده کرد، چون مرورگر بلافاصله بعد از دریافت یک پاسخ کامل، ارتباط HTTP رو خاتمه میده.
در روش کامیت Long polling ما میایم و به محض اینکه یک پاسخ دریافت شد و ارتباط جاری خاتمه پیدا کرد، یک درخواست جدید میفرستیم که نتیجتا یک ارتباط جدید باز شده و دوباره دو طرف منتظر میمونن تا شرایط لازم در سرور رخ بده و پاسخ درخواست HTTP به کلاینت ارسال بشه.
امیدوارم توضیحات خوب بوده باشن.
در پستهای بعدی پیاده سازی عملی این روش رو با کد نشون میدیم.
راستی به این روش که سرور هروقت خواست اطلاعاتی رو به کلاینت ارسال میکنه (بدون اینکه نیاز به درخواست قبلی کلاینت بوده باشه) فناوری push گفته میشه. البته ما در روش کامیت یک درخواست اولیه ارسال میکنیم، اما این درخواست فقط بخاطر تاسیس کانکشن اولیه هست که باید از جانب کلاینت شروع بشه.
میشه گفت کامیت، ترفندی برای ایجاد روش push در مرورگرها و وب سرورها هست که برای این کار پیشبینی نشدن و امکانات سرراست و استانداردی برای این کار ندارن.
ولی مثلا بدیهی هست که در برنامه نویسی شبکه با سوکت که تحت مرورگر و وب سرور نیست، پیاده سازی روش push خیلی ساده و سرراست هست و ترفند و محدودیت خاصی نداره.
عین مطلب ایشون هست با نام کاربری eshpilen اینم کپی رایت.
(من نمیخوام آموزش بدم ها من خودم میخوام یاد بگیرم)
دوستان بفرمایند ادامه ...
تو تالار PHP که یه دوستمون آموزش داده بودن.
اولشم خودم میگم.
یا بذارین همونو کپی کنم خوب توضیح داده بود :
خب حالا این کامیت اصلا برای چی بوجود آمد.
ببینید، ما در وب استاندارد و مرورگرها یک روش و امکانات محدود و ساده ای داریم به این صورت که اگر ما/مرورگر به چیزی/اطلاعاتی نیاز داره، درخواستی (Request) برای اون چیز به سرور سایت مورد نظر ارسال میکنه و بعد اگر جواب (Response) درست وجود داشته باشه (منبع داده ای موجود باشه و ما اجازهء دسترسی بهش رو داشته باشیم) یک پاسخ حاوی دیتای مورد نظر به مرورگر فرستاده میشه و اگر هم جواب درست وجود نداشته باشه، یک کد و پیام خطا برمیگرده و ارتباط HTTP جاری در همین نقطه پایان یافته تلقی میشه.
اگر اون اطلاعات ممکنه در هر زمانی بر روی سرور قرار بگیره که پیشبینی دقیق اون ممکن نیست (بطور مثال پیغامهای طرف مقابل در یک چت)، پس ما مجبوریم مدام در فواصل زمانی معین این کار رو انجام بدیم؛ یعنی درخواست بفرستیم تا ببینیم اطلاعاتی برای ما ارسال شده یا نه و پاسخ موفق یا ناموفق دریافت کنیم.
این عملیات شبیه این هست که مدام منتظر دریافت نامه یا نامه های مهم و فوری از ادارهء پست باشیم و مجبور باشیم برای چک کردن دریافت اون نامه ها مدام در فواصل زمانی کوتاه به ادارهء پست مراجعه کنیم یا باهاشون تماس بگیریم و بگیم «اگر برای من نامه ای اومده لطفا اونو بهم بدید/بگید».
این عملیات ارسال درخواست و دریافت پاسخی که فقط گاهی پاسخ موفق هست، موجب اتلاف منابع سخت افزاری سرور و کلاینت و مصرف پهنای باند بیشتر و نیز تاخیر زمانی بیشتر میشه. یعنی این وسط کلی کار تکراری و بیهوده انجام شده. ضمنا اگر ما بخوایم از ایجاد یا تغییر اطلاعات مورد نظر در روی سرور خیلی سریع مطلع بشیم، نیاز داریم تا این عملیات رو در فواصل زمانی کوتاه انجام بدیم که این میتونه این وضعیت رو بدتر کنه و حتی مشکلات فنی در هر دو سمت کلاینت و سرور ایجاد کنه. فرضا ما هر یک ثانیه بخوایم یک درخواست بفرستیم و پاسخ بگیریم، این هم مصرف منابع و فشار پردازشی روی کلاینت داره و هم روی سرور و هم سرورهای استاندارد وب برای چنین درخواست و پاسخهای سریع و دائمی با یک کلاینت درنظر گرفته نشدن و اولویت بندی خودشون رو دارن و ممکنه درخواست ما رو توی صف انتظار بذارن و با تاخیر خیلی بیشتری از اون چیزی که مد نظر ما بوده بهش جواب بدن، و شاید حتی ممکن باشه بعضی نرم افزارهای امنیتی و فایروالها نسبت به این ارتباطهای دائمی و سریع مشکوک بشن و مشکلی پیش بیاد (این مورد بنظر خودم رسید). خلاصه این روش بخصوص وقتی هدف مطلع شدن از هر تغییر در هر زمان نامعین در سرور با حداکثر سرعت ممکن باشه، مناسب بنظر نمیاد.
خب مثال رفتن یا تماس با ادارهء پست چیز خوبی بود.
ما میتونیم بجای اینکه خودمون مدام با ادارهء پست تماس بگیریم به اونا بگیم که به محض اینکه نامه ای برای ما دریافت کردن بهمون اطلاع بدن (البته برای این کار احتمالا باید آشنایی چیزی در ادارهء پست داشته باشید یا سر کیسه رو شل کنید!!).
روش Comet هم چنین چیزی رو با ترفند پیاده سازی میکنه. با ترفند این کار رو میکنه، چون در وب سرورهای معمولی و مرورگرها امکانات سر راست و استانداردی برای اینطور کارها پیشبینی نشدن.
در روش Comet ما یک درخواست برای شروع ارتباط، به سرور ارسال میکنیم، چون بعلت محدودیت های مرورگرها و سرورها و پروتکل HTTP در این زمینه امکان شروع ارتباط از سمت سرور با کلاینت وجود نداره (البته ظاهرا در آیندهء نه چندان دور شاهد استانداردها و امکانات جدیدی در این زمینه خواهیم بود).
وقتی ما درخواست رو به سرور ارسال کردیم، سرور به ما پاسخ فوری نمیده (مگر اینکه اطلاعات مورد نظر همون لحظه در دسترس باشن). سرور بجای اینکه به ما پیام عدم وجود اطلاعات رو بده، ما رو منتظر میذاره و تکلیف ارتباط HTTP رو مشخص نمیکنه. سرور و مرورگر تا هر وقت بتونن و چیزهایی مثل Timeout و غیره جلوشون رو نگیرن این ارتباط رو باز و بلاتکلیف نگه میدارن، مثلا ممکنه چند دقیقه یا حتی بصورت نامحدود این ارتباط باز بمونه و مرورگر همچنان در انتظار پاسخ از جانب سرور. اما سرور در این اثناء در پشت صحنه داره مدام ورود اطلاعات مورد نظر به سرور یا رخ دادن شرایط لازم رو چک میکنه و به محض اینکه شرایط لازم مهیا شد، اطلاعات مورد نظر رو بعنوان پاسخ درخواست ما از طریق کانکشن باز مونده بهمون ارسال میکنه.
این حالت احتمالا مثل اینه که شما زنگ بزنید به ادارهء پست و اونا بهتون جوابی ندن ولی گوشی رو هم قطع نکنن، و بعد هر دو طرف منتظر بمونن و به محض اینکه متصدی ادارهء پست نامهء ای برای شما دریافت کرد به شما اعلام بکنه (البته شما هم باید پای گوشی منتظر باشید).
این سناریویی که بنده گفتم البته یکی از روشهای پیاده سازی کامیت هست که معمولا با استفاده از AJAX در پشت صحنهء صفحه اجرا میشه و بهش Long polling گفته میشه.
روشهای دیگری هم هست و روشهایی که میشه از طریق یک ارتباط تعداد نامحدودی پاسخ رو در زمانهای مختلف دریافت کرد، ولی اونا مشکلات پیاده سازی یا مشکل ساپورت مرورگر و اینها رو دارن اکثرا.
بنابراین ما در این تاپیک به روش Long polling میپردازیم و از شرح بقیهء روشها بخاطر پرهیز از حجم و پیچیدگی و انحراف تاپیک اجتناب میکنیم.
خب در روش Long polling از هر ارتباط باز تنها برای یک پاسخ میشه استفاده کرد، چون مرورگر بلافاصله بعد از دریافت یک پاسخ کامل، ارتباط HTTP رو خاتمه میده.
در روش کامیت Long polling ما میایم و به محض اینکه یک پاسخ دریافت شد و ارتباط جاری خاتمه پیدا کرد، یک درخواست جدید میفرستیم که نتیجتا یک ارتباط جدید باز شده و دوباره دو طرف منتظر میمونن تا شرایط لازم در سرور رخ بده و پاسخ درخواست HTTP به کلاینت ارسال بشه.
امیدوارم توضیحات خوب بوده باشن.
در پستهای بعدی پیاده سازی عملی این روش رو با کد نشون میدیم.
راستی به این روش که سرور هروقت خواست اطلاعاتی رو به کلاینت ارسال میکنه (بدون اینکه نیاز به درخواست قبلی کلاینت بوده باشه) فناوری push گفته میشه. البته ما در روش کامیت یک درخواست اولیه ارسال میکنیم، اما این درخواست فقط بخاطر تاسیس کانکشن اولیه هست که باید از جانب کلاینت شروع بشه.
میشه گفت کامیت، ترفندی برای ایجاد روش push در مرورگرها و وب سرورها هست که برای این کار پیشبینی نشدن و امکانات سرراست و استانداردی برای این کار ندارن.
ولی مثلا بدیهی هست که در برنامه نویسی شبکه با سوکت که تحت مرورگر و وب سرور نیست، پیاده سازی روش push خیلی ساده و سرراست هست و ترفند و محدودیت خاصی نداره.
عین مطلب ایشون هست با نام کاربری eshpilen اینم کپی رایت.
(من نمیخوام آموزش بدم ها من خودم میخوام یاد بگیرم)
دوستان بفرمایند ادامه ...