PDA

View Full Version : Comet چیست - به چه دردی میخوره! - چگونه پیاده سازی میشود.



eshpilen
چهارشنبه 02 شهریور 1390, 10:27 صبح
یکی از کاربران تقاضای آموزش Comet (http://en.wikipedia.org/wiki/Comet_%28programming%29) داشت.
البته منکه خودم عددی نیستم و فروتنی و اینا!!
ولی نه جدی میگم من خودم در این زمینه نوآموز هستم و فقط مقالهء ویکیپدیا رو خوندم و یه نمونه آزمایشی چت کامیت پیاده کردم که بنظرم درسته و خوب کار میکنه، ولی خیلی هم مطمئن نیستم (البته تعریف ها واضح و ساده بنظر میرسن).
بنابراین ممکنه مطالب نقص و اشتباه یا بی دقتی داشته باشن. شما میتونید این موارد رو تذکر بدید و اگر خودتون اطلاعات و تجربه ای در زمینهء Comet دارید در این تاپیک مطرح کنید.

راستی تلفظ کامیت رو هم همون کاربر بکار میبره که بنده هم بنابراین از همون استفاده میکنم (به جهت راحتتر و سریعتر بودن تایپ فارسی)؛ ولی نمیدونم منبع درستی داشته یا نه.

راستی شاید بپرسید Comet مخفف چیه.

باید بگم اسمش تقریبا معنی نداره و یک شوخی و بازی با کلماته.
چون دوتا کالای شوینده وجود داشته/داره بنام Ajax (http://en.wikipedia.org/wiki/Ajax_%28cleanser%29) و Comet (http://en.wikipedia.org/wiki/Comet_%28cleanser%29) که هیچ ربطی به کامپیوتر و برنامه نویسی ندارن. ظاهرا طرف دیده چون اسم یکی از این تمیزکننده ها شبیه اسم متد AJAX (http://en.wikipedia.org/wiki/Ajax_%28programming%29) در برنامه نویسی هست، گفته اسم این چیزی رو که اختراع کردم و یه چیزی مکمل یا در سطح AJAX هست میذارم Comet!

eshpilen
چهارشنبه 02 شهریور 1390, 11:06 صبح
خب حالا این کامیت اصلا برای چی بوجود آمد.
ببینید، ما در وب استاندارد و مرورگرها یک روش و امکانات محدود و ساده ای داریم به این صورت که اگر ما/مرورگر به چیزی/اطلاعاتی نیاز داره، درخواستی (Request) برای اون چیز به سرور سایت مورد نظر ارسال میکنه و بعد اگر جواب (Response) درست وجود داشته باشه (منبع داده ای موجود باشه و ما اجازهء دسترسی بهش رو داشته باشیم) یک پاسخ حاوی دیتای مورد نظر به مرورگر فرستاده میشه و اگر هم جواب درست وجود نداشته باشه، یک کد و پیام خطا برمیگرده و ارتباط HTTP جاری در همین نقطه پایان یافته تلقی میشه.
اگر اون اطلاعات ممکنه در هر زمانی بر روی سرور قرار بگیره که پیشبینی دقیق اون ممکن نیست (بطور مثال پیغامهای طرف مقابل در یک چت)، پس ما مجبوریم مدام در فواصل زمانی معین این کار رو انجام بدیم؛ یعنی درخواست بفرستیم تا ببینیم اطلاعاتی برای ما ارسال شده یا نه و پاسخ موفق یا ناموفق دریافت کنیم.

این عملیات شبیه این هست که مدام منتظر دریافت نامه یا نامه های مهم و فوری از ادارهء پست باشیم و مجبور باشیم برای چک کردن دریافت اون نامه ها مدام در فواصل زمانی کوتاه به ادارهء پست مراجعه کنیم یا باهاشون تماس بگیریم و بگیم «اگر برای من نامه ای اومده لطفا اونو بهم بدید/بگید».

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

خب مثال رفتن یا تماس با ادارهء پست چیز خوبی بود.
ما میتونیم بجای اینکه خودمون مدام با ادارهء پست تماس بگیریم به اونا بگیم که به محض اینکه نامه ای برای ما دریافت کردن بهمون اطلاع بدن (البته برای این کار احتمالا باید آشنایی چیزی در ادارهء پست داشته باشید یا سر کیسه رو شل کنید!!).
روش Comet هم چنین چیزی رو با ترفند پیاده سازی میکنه. با ترفند این کار رو میکنه، چون در وب سرورهای معمولی و مرورگرها امکانات سر راست و استانداردی برای اینطور کارها پیشبینی نشدن.
در روش Comet ما یک درخواست برای شروع ارتباط، به سرور ارسال میکنیم، چون بعلت محدودیت های مرورگرها و سرورها و پروتکل HTTP در این زمینه امکان شروع ارتباط از سمت سرور با کلاینت وجود نداره (البته ظاهرا در آیندهء نه چندان دور شاهد استانداردها و امکانات جدیدی در این زمینه خواهیم بود).

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

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

این سناریویی که بنده گفتم البته یکی از روشهای پیاده سازی کامیت هست که معمولا با استفاده از AJAX در پشت صحنهء صفحه اجرا میشه و بهش Long polling گفته میشه.
روشهای دیگری هم هست و روشهایی که میشه از طریق یک ارتباط تعداد نامحدودی پاسخ رو در زمانهای مختلف دریافت کرد، ولی اونا مشکلات پیاده سازی یا مشکل ساپورت مرورگر و اینها رو دارن اکثرا.

بنابراین ما در این تاپیک به روش Long polling میپردازیم و از شرح بقیهء روشها بخاطر پرهیز از حجم و پیچیدگی و انحراف تاپیک اجتناب میکنیم.

خب در روش Long polling از هر ارتباط باز تنها برای یک پاسخ میشه استفاده کرد، چون مرورگر بلافاصله بعد از دریافت یک پاسخ کامل، ارتباط HTTP رو خاتمه میده.
در روش کامیت Long polling ما میایم و به محض اینکه یک پاسخ دریافت شد و ارتباط جاری خاتمه پیدا کرد، یک درخواست جدید میفرستیم که نتیجتا یک ارتباط جدید باز شده و دوباره دو طرف منتظر میمونن تا شرایط لازم در سرور رخ بده و پاسخ درخواست HTTP به کلاینت ارسال بشه.

امیدوارم توضیحات خوب بوده باشن.
در پستهای بعدی پیاده سازی عملی این روش رو با کد نشون میدیم.

راستی به این روش که سرور هروقت خواست اطلاعاتی رو به کلاینت ارسال میکنه (بدون اینکه نیاز به درخواست قبلی کلاینت بوده باشه) فناوری push (http://en.wikipedia.org/wiki/Push_technology) گفته میشه. البته ما در روش کامیت یک درخواست اولیه ارسال میکنیم، اما این درخواست فقط بخاطر تاسیس کانکشن اولیه هست که باید از جانب کلاینت شروع بشه.
میشه گفت کامیت، ترفندی برای ایجاد روش push در مرورگرها و وب سرورها هست که برای این کار پیشبینی نشدن و امکانات سرراست و استانداردی برای این کار ندارن.
ولی مثلا بدیهی هست که در برنامه نویسی شبکه با سوکت که تحت مرورگر و وب سرور نیست، پیاده سازی روش push خیلی ساده و سرراست هست و ترفند و محدودیت خاصی نداره.

idocsidocs
چهارشنبه 02 شهریور 1390, 12:32 عصر
یکی از کاربران تقاضای آموزش Comet (http://en.wikipedia.org/wiki/Comet_%28programming%29) داشت.
منظور من هستم :چشمک:


راستی تلفظ کامیت رو هم همون کاربر بکار میبره که بنده هم بنابراین از همون استفاده میکنم (به جهت راحتتر و سریعتر بودن تایپ فارسی)؛ ولی نمیدونم منبع درستی داشته یا نه.
من دنبال تلفظ این کلمه نرفتم و شاید این تلفظ درست نباشه.

منتظر مباحث اصلی این تاپک هستم :متفکر:

eshpilen
چهارشنبه 02 شهریور 1390, 21:22 عصر
در این پست و پست بعدی پیاده سازی کامیت به شکل Long polling و با کمک AJAX رو نشون میدیم.

برای این منظور از یک مثال خیلی ساده شده و نمونه برنامه ای که میتونه بخشی از یک برنامهء چت باشه استفاده میکنیم. البته مثال ما برای سادگی یک طرفه هست و تنها این بخش یک برنامهء چت رو بررسی میکنیم که یک طرف پیغامی برای طرف دیگر به سرور ارسال میکنه و طرف دیگر میخواد با حداکثر سرعت و بهینگی ممکن این پیغام رو از سرور دریافت بکنه.

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

بخش در سرور ما برای ذخیرهء پیغامهای دریافتی از سمت دیگر، از یک فایل بنام msg.txt استفاده میکنیم.
البته گفتم که ما برای سادگی مثال، تا اینجا به کدش کاری نداریم و فرض میکنیم این عملیات انجام میشه و ما فقط الگوریتم و کدهای دریافت اطلاعات رو که به روش کامیت هستن نشون میدیم. یعنی شما برای تست عملی این برنامه باید پیغامهای فرضی رو خودتون بصورت دستی در فایل msg.txt وارد و Save کنید و بعد مشاهده میکنید که چطور برنامهء ما بلافاصله اون پیغامها رو از فایل بیرون میکشه و نمایش میده.

فایل msg.txt باید از قبل توسط خودتون ایجاد شده باشه و توش چیزی نباشه. ضمنا PHP باید امکان نوشتن و خواندن این فایل رو در دایرکتوری مورد نظر داشته باشه. البته اگر روی لوکال ویندوز تست میکنید از این جهت مشکل و نیاز به تنظیم خاصی نیست.

خب کد سمت سرور ما فایلی بنام get_msg.php هست با چنین محتویاتی:

<?php

header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Cache-Control: private, no-cache, must-revalidate, post-check=0, pre-check=0, max-age=0");
header('Pragma: private');
header("Pragma: no-cache");

header('Content-Type: text/html; charset=utf-8');

$msg_file='msg.txt';

clearstatcache();
while(filesize($msg_file)==0) {
usleep(500000);
clearstatcache();
}

$fp=fopen($msg_file, "r+");
flock($fp, LOCK_EX);
$msg=fread($fp, filesize($msg_file));
ftruncate($fp, 0);
fclose($fp);

echo '_-_', $msg;

?>
توضیح کد:
خطوط اول که صرفا ارسال هدرهای جلوگیری کننده از Cache و همچنین هدر اعلام انکدینگ UTF-8 هستن. البته هدرهای ضدکش ممکنه نیاز نباشن ولی از جهت اطمینان ارسال میکنیم، چون قرار نیست پاسخ درخواست ها به این اسکریپت در جایی کش بشن و کش شدن اون موجب اختلال در برنامه میشه.

دستور مهم بعدی در خط 13 فراخوانی تابع clearstatcache است.
چون ما میخوایم در فواصل زمانی کوتاه با استفاده از تابع filesize اندازهء فایل پیغامها (msg.txt) رو چک کنیم تا بفهمیم آیا پیغامی درش ذخیره شده (که در اینصورت حجمش صفر نخواهد بود) یا نه، و چون PHP اطلاعات مربوط به فایلها منجمله حجم فایل رو برای مدتی Cache میکنه و در نتیجه فراخوانی های بعدی تابع filesize همون نتایج قبلی رو که آپدیت نیستن برمیگردونه، ما با استفاده از تابع clearstatcache هربار قبل از فراخوانی تابع filesiz، اطلاعات موجود در کش داخلی PHP در ارتباط با فایلها رو پاک میکنیم یا میتونیم طور دیگه بگیم که به PHP اعلان میکنیم که وضعیت فایل رو دوباره مستقیما از سیستم عامل بگیره تا آپدیت باشه.

خب ما در یک حلقهء while با شرط filesize($msg_file)==0 مدام دور میزنیم و بین هر دور بوسیلهء دستور usleep(500000) مدت نیم ثانیه تاخیر ایجاد میکنیم. این تاخیر لازمه، وگرنه CPU دائما مشغول میشه و بار زیادی به سرور تحمیل شده و اصلا ممکنه درست کار نکنه (روی سیستم بنده که CPU usage بدون این دستور میره روی 100% و آپاچی تقریبا هنگ میکنه).
بنابراین عملا اجرای برنامهء PHP ما تا زمانی که پیغامی در فایل پیغامها ذخیره نشه و نتیجتا حجمش از صفر بیشتر نشه، داخل این حلقه دور میزنه و هیچ پاسخی هم به درخواست مرورگر داده نمیشه و بنابراین مرورگر در پشت صحنه منتظر دریافت نتایج درخواست AJAX باقی میمونه. البته این انتظار بصورت معمول تا حدود 30 ثانیه بیشتر طول نمیکشه چون بعد از اون خود PHP بر اساس محدودیت زمانی اجرای اسکریپت ها که بصورت پیشفرض 30 ثانیه هست اجرای برنامه رو خاتمه میده و یک پیام خطا رو بعنوان پاسخ به مرورگر ارسال میکنه. البته ما میتونیم بوسیله قرار دادن دستور set_time_limit(0) در ابتدای این برنامه، از این محدودیت زمانی و Timeout جلوگیری بکنیم، ولی شاید این کار از بعضی نظرها جالب نباشه و ضمنا برای کاربرد ما ضروری و دارای فایدهء قابل توجهی بنظر نمیرسه و از طرف دیگه باید برای تست کامل برنامه و ثابت شدن قدرت و انعطاف اون در مدیریت خطاها، این Timeout رو بحال خودش باقی بگذاریم.

سرانجام وقتی پیغامی در فایل ذخیره شد و ما از حلقهء while خارج شدیم، در خط 19 فایل رو برای خواندن و نوشتن باز میکنیم. از اونجایی که نمیخوایم موقع خوندن ما از فایل، پیغام جدیدی همزمان در اون نوشته بشه، بنابراین فایل رو بوسیلهء تابع flock قفل میکنیم. از فلگ LOCK_EX هم که معرف قفل انحصاری است استفاده میکنیم چون هم نمیخوایم کس دیگری همزمان محتویات فایل رو بخونه و هم خودمون میخوایم بعد از خواندن، محتویات فایل رو پاک کنیم، و این یه جور نوشتن (تغییر محتویات) در فایل محسوب میشه و بنابراین کس دیگه ای نباید در مدت نوشتن در فایل بتونه فایل رو بخونه (یا بنویسه) وگرنه ممکنه دیتای خراب دریافت کنه. البته ما در این برنامه خوانندهء دیگری هم نداریم و بنابراین این فلگ عملا مهم نیست، ولی بهتره از نظر اصول برنامه نویسی و توسعهء برنامه در آینده، از این فلگ استفاده کنیم.
ضمنا توجه کنید که قفل های تابع flock اجباری نیستن (به اصطلاح advisory هستن) و بنابراین تمام برنامه هایی که به فایل مورد نظر دسترسی پیدا میکنن باید قبل از عملیات خواندن و نوشتن، این تابع رو خودشون با فلگ مناسب اجرا کنن، وگرنه چیزی جلوی دسترسی همزمان اونها به فایل رو نمیگیره.
نکته: البته در داکیومنت آمده که این تابع در ویندوز mandatory هستن. یعنی بنظرم قفل اجباری ایجاد میکنه.

خب ما محتویات فایل رو با تابع fread خونده و در متغییر msg قرار میدیم تا بعد بعنوان پاسخ به مرورگر توسط دستور echo ارسال کنیم.
بعد از خواندن پیغام، در خط 22 هم با تابع ftruncate محتویات فایل رو پاک میکنیم که این کار حجم فایل رو به صفر میرسونه و برنامه در درخواست بعدی از جانب مرورگر دوباره تا وقتی چیزی در این فایل ذخیره بشه و حجمش بیشتر از صفر بشه در حلقهء while دور خواهد زد.

سرانجام با دستور fclose فایل رو میبندیم و البته این باعث میشه قفل flock روی فایل هم آزاد بشه. هرچند برای آزاد کردن قفل و از نظر روش برنامه نویسی اصولی تر میتونید از تابع flock با فلگ LOCK_UN هم استفاده کنید.

در خط آخر، پیام رو با دستور echo '_-_', $msg با اضافه کردن سه کاراکتر دیگه به ابتدای اون به نحوی که میبینید، به مرورگر ارسال میکنیم.
علت اضافه کردن این رشتهء خاص به ابتدای پیام طرف دیگر اینه که بعد در سمت مرورگر بتونیم پیامهای خطا مثلا ناشی از خطای Timeout رو از پیامهای طرف دیگه تشخیص بدیم. بنظرم این یه روش ساده اما در عین حال بقدر کافی مطمئن و بهینه برای کاربرد ما باشه. بخصوص که Resposne status پیام خطای Timeout ای که PHP تولید میکنه هم 200 هست و فرقی با پاسخهای عادی نداره و بنابراین نمیشه از روی کد وضعیت پاسخ HTTP تشخیص بدیم که پاسخ حاوی متن یک پیام خطا هست یا پیام طرف دیگر.

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

eshpilen
چهارشنبه 02 شهریور 1390, 22:31 عصر
خب میرسیم به بخش کلاینت و تحت مرورگر.

کد زیر رو در فایلی با نام client.php ذخیره میکنیم و همین فایل هست که در مرورگر باز میکنیم:

<?php
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Cache-Control: private, no-cache, must-revalidate, post-check=0, pre-check=0, max-age=0");
header('Pragma: private');
header("Pragma: no-cache");

header('Content-Type: text/html; charset=utf-8');
?>
<html>
<head>
<script>
var comet_xhr;

function create_xhr() {
var xhr;
if(window.XMLHttpRequest) xhr = new XMLHttpRequest();
else if (window.ActiveXObject) xhr = new ActiveXObject("Microsoft.XMLHTTP");
return xhr;
}

function receive_state() {
if(comet_xhr.readyState!=4) return;
msg=comet_xhr.responseText;
if(msg.indexOf('_-_')==0) {
msg=msg.substring(msg.indexOf('_-_')+3);
txt.value=txt.value+"\n"+'received message: '+msg;
}
comet_xhr.open("GET", 'get_msg.php');
comet_xhr.send(null);
}

function load() {
txt=document.getElementById('txt');
txt.value='';
comet_xhr=create_xhr();
comet_xhr.onreadystatechange=receive_state;
comet_xhr.open("GET", 'get_msg.php');
comet_xhr.send(null);
}

</script>
</head>
<body onload="load();">
<center>
<span style="vertical-align: top">Messages:</span>
<textarea id="txt" style="width: 300; height: 300;"></textarea>
</center>
</body>
</html>

یک سر میریم سراغ بخش جاوااسکریپت چون تقریبا همه چیز همونه.
متغییر comet_xhr قراره شیء XMLHttpRequest ای رو که برای درخواست های comet بصورت AJAX استفاده میکنیم در خودش نگه داره.
اساسا کار ما همون AJAX هست اما با درخواست و پاسخها به روش Comet.
تابع create_xhr که مشخص هست برای ایجاد یک شیء XMLHttpRequest بکار میره.
تابع receive_state تقریبا تمام الگوریتم اصلی ما رو در خودش داره.
این تابع هنگام لود کامل صفحهء HTML، پس از ایجاد شیء XMLHttpRequest، بعنوان تابعی برای هندل کردن رویدادهای onreadystatechange اون بکار میره. یعنی هروقت وضعیت درخواست ارسال شده تغییری کرد این تابع فراخوانی میشه تا با توجه به وضعیت درخواست عمل مناسب رو انجام بده و نهایتا پاسخ رو دریافت کرده و اعمال کنه.
در خط اول این تابع ما با عبارت if(comet_xhr.readyState!=4) return بررسی میکنیم اگر وضعیت شیء XMLHttpRequest عدد 4 نبود که این عدد به معنای دریافت کامل Response هست، هیچ کاری انجام نشه و با دستور return که باعث خروج از تابع میشه از اجرای بقیهء دستورات تابع جلوگیری میکنیم.
اگر به دستورات بعدی برسیم به معنی اینه که پاسخ کامل از جانب سرور دریافت شده.
با عبارت msg=comet_xhr.responseText، متن پاسخ دریافت شده را در متغییری با نام msg ذخیره میکنیم تا بعدا اون رو بررسی و روش کار کنیم.
با عبارت if(msg.indexOf('_-_')==0) چک میکنیم که آیا پاسخ دریافت شده با کاراکترهای خاصی که ما در اسکریپت سمت سرور برای تشخیص پاسخهای صحیح از پیامهای خطا به ابتدای پیام اضافه کرده بودیم شروع میشه یا نه. وقتی پیام با این کاراکترها شروع میشه ما با عبارت msg=msg.substring(msg.indexOf('_-_')+3) اون کاراکترهای اضافی رو از ابتدای پیام حذف کرده و بعد با دستور txt.value=txt.value+"\n"+'received message: '+msg پیام دریافت شده رو به یک کادر متنی چند خطی که متغییر txt بهش ارجاع میکنه به انتهای پیامهای قبلی در یک خط جدید اضافه میکنیم.
در خطوط بعدی با دو دستور زیر:

comet_xhr.open("GET", 'get_msg.php');
comet_xhr.send(null);
چون ارتباط HTTP قبلی با دریافت پاسخش خاتمه یافته، درخواست کامیت جدیدی رو به بخش سمت سرور ارسال میکنیم و دوباره منتظر دریافت پاسخ میمونیم.

تابع load هم که مشخص هست در رویداد onload صفحه اجرا شده و این سیستم رو شروع میکنه.
این کار رو با قرار دادن ارجاع به شیء معرف کادر متن پیامهای دریافتی در متغییر txt،
پاک کردن محتویات کادر متن پیامها،
ایجاد شیء XMLHttpRequest و قرار دادن اون در متغییر comet_xhr،
تعیین تابع receive_state بعنوان هندلر رویداد onreadystatechange شیء XMLHttpReques،
باز کردن کانکشن به get_msg.php که بخش سمت سرور برنامهء ماست،
و ارسال درخواست HTTP به سمت سرور،
انجام میده.

به همین سادگی - به همین خوشمزگی!!
خب اگر سوال و مشکلی هست بفرمایید و لطفا بگید کیفیت آموزش چطور بود.
ضمنا بازم تاکید میکنم این کدها فقط یک بخش کوچک از یک نوع الگوریتم یک برنامهء چت به روش کامیت هستن و به هیچ وجه کد کامل، عملیاتی، و اصولی ای بحساب نمیان. اما در این حد هست که بشه تستش کرد و کارکرد عملی این الگوریتم و سیستمها رو مشاهده کرده.

ضمنا توجه داشته باشید که درخواست کامیت ما حتی درصورتیکه مرورگر بسته بشه در سمت سرور درحال اجرا باقی میمونه تا وقتی که پیامی دریافت بشه یا بر اثر Timeout اجرای اون خاتمه پیدا کنه. در طول این مدت آپاچی بصورت عادی Stop یا ریستارت نمیشه. بنده تست کردم و دیدم که حتی اجرای متد abort شیء XMLHttpRequest در این وضعیت تاثیری نداشت.
بخاطر همین گفتم بهتره Timeout رو برنداریم. وگرنه ممکنه مجبور بشید با Task manager ویندوز پراسسهای آپاچی رو Kill کنید.
اینها نظیر مسائلی هست که باید بدونیم و در یک برنامهء کامل نتایج اونها رو بررسی و مدیریت کنیم و مثلا کدهایی به برنامه اضافه کنیم که حتی الامکان هرچه زودتر یا موقع خارج شدن از صفحه یا از دست رفتن یک اتصال، به اجرای برنامه در سمت سرور هم خاتمه بدن.

یادتون نره برای تست برنامه باید بعد از اجرای client.php در مرورگر، پیامهای فرضی از طرف مقابل رو خودتون بصورت دستی در فایل msg.txt وارد و Save کنید و اونوقت اونها به سرعت توسط مرورگر دریافت و نمایش داده میشن. ضمنا PHP باید امکان خواندن و نوشتن در این فایل رو داشته باشه.

eshpilen
چهارشنبه 02 شهریور 1390, 22:35 عصر
ضمنا در این تاپیک (http://barnamenevis.org/showthread.php?301496-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D8%A2%D8%B2%D9%85%D8%A7%DB%8C%D8%B4%DB%8C-%D8%A7%D9%84%DA%AF%D9%88%D8%B1%DB%8C%D8%AA%D9%85-%DA%86%D8%AA-Comet) هم برنامهء کاملتر و مجهزتر چت کامیت که الگوریتم بخش دریافت اون در کل به همین شکل کار میکنه قابل دانلود هست. البته اونم یه برنامهء آزمایشی و برای تست و نمایش الگوریتم هست ولی کاملتره و دو کلاینت واقعی میتونن با هم چت دو طرفه داشته باشن.
بخش ارسال پیامها از کلاینت ها به سرور، توسط ارتباطهای معمولی (غیر کامیت) AJAX اجرا میشه.
تنها بخش دریافت هر کلاینت هست که از روش کامیت استفاده میکنه چون روش کامیت در این بخش هست که مزیت قابل توجه داره و ضمنا برای ارسال از سمت سرور به کلاینت عملی است.

idocsidocs
پنج شنبه 03 شهریور 1390, 01:32 صبح
خب تا اینجا بخش سمت سرور کد دریافت کنندهء پیامها به روش کامیت تموم شد.
کد مربوط به سمت کلاینت رو انشالا اگر زنده بودم در پست بعدی درج کرده و توضیح میدم.
شما گفتید که :

خب ما در یک حلقهء while با شرط filesize($msg_file)==0 مدام دور میزنیم و بین هر دور بوسیلهء دستور usleep(500000) مدت نیم ثانیه تاخیر ایجاد میکنیم.
و

بنابراین عملا اجرای برنامهء PHP ما تا زمانی که پیغامی در فایل پیغامها ذخیره نشه و نتیجتا حجمش از صفر بیشتر نشه، داخل این حلقه دور میزنه و هیچ پاسخی هم به درخواست مرورگر داده نمیشه
می شه گفت که این مطلب نکته اصلی برای راه اندازی کامیت هست و بقیه کدها هم ملزومات یه برنامه کامل هستن. درسته؟

اگر این مطلب درسته، سه تا سوال برام پیش می یاد.
1- وقتیکه برنامه رو به مدت 0.5 ثانیه متوقف می کنیم، آیا حلقه while هم همراه با اسکریپت متوقف می شه یا اینکه حلقه while به کار خودش ادامه می ده؟

2- اگر پیامی در فایل وجود داشت، باید از حلقه while خارج بشیم و پیامها رو به مرورگر بفرستیم. در این صورت باید برای فراخوانی مجدد اسکریپت و حلقه مربوط به راه انداز کامیت از مرورگر یه درخواست به اسکریپت ارسال کنیم یا اینکه خود اسکریپت مجددا باید به کارش ادامه بده؟ لطفا توضیح بدید.

3- اگر نمایش خطاها رو به کمک error_reporting غیرفعال کرده باشیم و 30 ثانیه از اجرای حلقه گذشت، چطور باید این موضوع رو به مررگر اعلام کنیم؟

iranme
پنج شنبه 03 شهریور 1390, 12:59 عصر
خیلی ممنون از آموزشتون. خیلی مفید بود.
یک سوال (البته بیش تر از یکیه) برام پیش اومده!
شما اطلاعات را از یک فایل میخوانید حالا اگر بخوایم از دیتابیس بخونیم چه اتفاقی میافته!؟ روی سرعت دریافت اطلاعات تاثیر نمیذاره!؟

A B C D
جمعه 04 شهریور 1390, 13:47 عصر
می شه گفت که این مطلب نکته اصلی برای راه اندازی کامیت هست و بقیه کدها هم ملزومات یه برنامه کامل هستن. درسته؟

بله گفته شما درسته.
البته توجه دارید که این بخش سمت سرور هست و بدون هماهنگی کدهای سمت کلاینت و بکار گرفتن روش ویژه در اون سمت قابل استفاده نیست.


1- وقتیکه برنامه رو به مدت 0.5 ثانیه متوقف می کنیم، آیا حلقه while هم همراه با اسکریپت متوقف می شه یا اینکه حلقه while به کار خودش ادامه می ده؟ تاجایکه میدونم توابعی مثل sleep باعث میشن اصولا برنامه از حالت اجرا خارج بشه و به حالت تعلیق دربیاد.
یعنی این دستور به سیستم عامل منتقل میشه و نتیجتا scheduler سیستم عامل که وظیفهء اجرای پردازشها بر اساس نوبت و اولویت بر روی CPU رو بر عهده داره، پردازش جاری رو موقتا بحالت تعلیق درآورده و از صف اجرا خارج میکنه تا اینکه مدت زمان تعیین شده سپری بشه. هیچ چیزی در این مدت اجرا نمیشه. برنامه بعد از اجرای دستور sleep در همونجا به حالت تعلیق کامل درمیاد. بخاطر همینه که برنامه دیگه هیچ پردازشی از CPU مصرف نمیکنه.



2- اگر پیامی در فایل وجود داشت، باید از حلقه while خارج بشیم و پیامها رو به مرورگر بفرستیم. در این صورت باید برای فراخوانی مجدد اسکریپت و حلقه مربوط به راه انداز کامیت از مرورگر یه درخواست به اسکریپت ارسال کنیم یا اینکه خود اسکریپت مجددا باید به کارش ادامه بده؟ لطفا توضیح بدید.در روش Long polling نیاز به درخواست مجدد داریم. ولی این درخواست مجدد بخاطر این نیست که اسکریپت سمت سرور نیاز به درخواست کلاینت داره تا بتونه دوباره این فرایند رو شروع کنه، بلکه بخاطر محدودیت های مرورگر در AJAX است که نمیتونیم بیش از یک پاسخ رو برای یک درخواست دریافت کنیم.

ولی در روش Streaming بعکس اسکریپت میتونه برای چند پاسخ استفاده بشه و نیازی نیست تا از مرورگر درخواستهای مجدد بفرستیم. البته این پاسخهای چندگانه در یک روش پیاده سازی Streaming از دو یا چند روش پیاده سازی اون، بیشتر حالت ترفند رو داره تا اینکه واقعا از نظر پروتکل HTTP چند پاسخ مجزا بحساب بیاد. بهرصورت ما میتونیم اون رو از نظر کاربرد خودمون بصورت پاسخهای مجزا درنظر بگیریم.


3- اگر نمایش خطاها رو به کمک error_reporting غیرفعال کرده باشیم و 30 ثانیه از اجرای حلقه گذشت، چطور باید این موضوع رو به مررگر اعلام کنیم؟بهرحال اگر پیام خطایی هم تولید نشه اجرای اسکریپت خاتمه پیدا کرده و یک پاسخ خالی به مرورگر ارسال میشه و بطور مثال کدهایی که ما در این تاپیک داریم چک میکنن که آیا رشتهء خاصی که پیامهای واقعی با اون علامتگذاری میشن در ابتدای پاسخ وجود داره یا نه، و طبیعتا چون این رشتهء خاص در پاسخ خالی وجود نداره اون پاسخ بعنوان یک حالت خطا درنظر گرفته میشه.

A B C D
جمعه 04 شهریور 1390, 13:53 عصر
شما اطلاعات را از یک فایل میخوانید حالا اگر بخوایم از دیتابیس بخونیم چه اتفاقی میافته!؟ روی سرعت دریافت اطلاعات تاثیر نمیذاره!؟ نه. مگه خواندن و نوشتن دیتابیس چقدر زمان میبره؟
طرفهایی که چت میکنن انسانند و خیلی کندتر از این هستن که تاخیر دیتابیس در برابر کندی تایپ و حواس اونها مشهود باشه.
برنامهء ما هم خودش در هر دور نیم ثانیه میخوابه و در این مدت حتی اگر پیامی باشه پردازش نمیکنه. البته میتونیم این زمان رو از این خیلی کمتر کنیم.
مگر در شرایطی که سرور چت ترافیک سنگین داره، یعنی تعداد زیادی کاربر بصورت همزمان درحال چت هستن، باشه که تفاوت سرعت میان دیتابیس و فایل مشهود بشه. اینکه در این برنامه ها از فایل استفاده شده بخاطر این بوده که این یک سیستم ساده و نمایشی هست و هیچ نیازی به دیتابیس و پیچیدگی کار با اون نداره و میخوایم مثال هم ساده و قابل درک و براحتی قابل نصب و تست باشه.

alismith
جمعه 04 شهریور 1390, 14:20 عصر
تلفظ درست comet : کامت :چشمک:

idocsidocs
جمعه 04 شهریور 1390, 14:27 عصر
بله گفته شما درسته.
البته توجه دارید که این بخش سمت سرور هست و بدون هماهنگی کدهای سمت کلاینت و بکار گرفتن روش ویژه در اون سمت قابل استفاده نیست.

تاجایکه میدونم توابعی مثل sleep باعث میشن اصولا برنامه از حالت اجرا خارج بشه و به حالت تعلیق دربیاد.
یعنی این دستور به سیستم عامل منتقل میشه و نتیجتا scheduler سیستم عامل که وظیفهء اجرای پردازشها بر اساس نوبت و اولویت بر روی CPU رو بر عهده داره، پردازش جاری رو موقتا بحالت تعلیق درآورده و از صف اجرا خارج میکنه تا اینکه مدت زمان تعیین شده سپری بشه. هیچ چیزی در این مدت اجرا نمیشه. برنامه بعد از اجرای دستور sleep در همونجا به حالت تعلیق کامل درمیاد. بخاطر همینه که برنامه دیگه هیچ پردازشی از CPU مصرف نمیکنه.

در روش Long polling نیاز به درخواست مجدد داریم. ولی این درخواست مجدد بخاطر این نیست که اسکریپت سمت سرور نیاز به درخواست کلاینت داره تا بتونه دوباره این فرایند رو شروع کنه، بلکه بخاطر محدودیت های مرورگر در AJAX است که نمیتونیم بیش از یک پاسخ رو برای یک درخواست دریافت کنیم.

ولی در روش Streaming بعکس اسکریپت میتونه برای چند پاسخ استفاده بشه و نیازی نیست تا از مرورگر درخواستهای مجدد بفرستیم. البته این پاسخهای چندگانه در یک روش پیاده سازی Streaming از دو یا چند روش پیاده سازی اون، بیشتر حالت ترفند رو داره تا اینکه واقعا از نظر پروتکل HTTP چند پاسخ مجزا بحساب بیاد. بهرصورت ما میتونیم اون رو از نظر کاربرد خودمون بصورت پاسخهای مجزا درنظر بگیریم.

بهرحال اگر پیام خطایی هم تولید نشه اجرای اسکریپت خاتمه پیدا کرده و یک پاسخ خالی به مرورگر ارسال میشه و بطور مثال کدهایی که ما در این تاپیک داریم چک میکنن که آیا رشتهء خاصی که پیامهای واقعی با اون علامتگذاری میشن در ابتدای پاسخ وجود داره یا نه، و طبیعتا چون این رشتهء خاص در پاسخ خالی وجود نداره اون پاسخ بعنوان یک حالت خطا درنظر گرفته میشه.
می شه بگید تفاوت روش های Long polling و Streaming چیه؟

در روش Long polling نیاز به درخواست مجدد داریم. ولی این درخواست مجدد بخاطر این نیست که اسکریپت سمت سرور نیاز به درخواست کلاینت داره تا بتونه دوباره این فرایند رو شروع کنه
طبق اصول یه اسکریپت از بالا شروع به خوندن کدها می کنه و بعد از اجرای همه کدها اسکریپت به پایان می رسه. توی جاوا اسکریپت می شه با استفاده از settimeout مجددا یه تابع رو فعال کرد ولی توی پی اچ پی این امکان وجود نداره و بعد از خارج شدن از حلقه و پایان یافتن کدها، اجرا اسکریپت هم متوقف می شه.

می شه در این مورد بیشتر توضیح بدید و بگید روی چه اصولی می گید که اسکریپت به پایان نمی رسه؟

idocsidocs
جمعه 04 شهریور 1390, 14:33 عصر
بهرحال اگر پیام خطایی هم تولید نشه اجرای اسکریپت خاتمه پیدا کرده و یک پاسخ خالی به مرورگر ارسال میشه و بطور مثال کدهایی که ما در این تاپیک داریم چک میکنن که آیا رشتهء خاصی که پیامهای واقعی با اون علامتگذاری میشن در ابتدای پاسخ وجود داره یا نه، و طبیعتا چون این رشتهء خاص در پاسخ خالی وجود نداره اون پاسخ بعنوان یک حالت خطا درنظر گرفته میشه. سوال دیگه اینکه ایا تابعی ارائه شده که اگه زمان اجرای اسکریپت به پایان رسید به صورت اتوماتیک یه پیام هشدار تولید کنه؟

A B C D
جمعه 04 شهریور 1390, 17:52 عصر
طبق اصول یه اسکریپت از بالا شروع به خوندن کدها می کنه و بعد از اجرای همه کدهای اسکریپت به پایان می رسه. توی جاوا اسکریپت می شه با استفاده از settimeout مجددا یه تابع رو فعال کرد ولی توی پی اچ پی این امکان وجود نداره و بعد از خارج شدن از حلقه و پایان یافتن کدها، اجرا اسکریپت هم متوقف می شه.
می شه در این مورد بیشتر توضیح بدید و بگید روی چه اصولی می گید که اسکریپت به پایان نمی رسه؟
خب کل کد برنامه رو میذاریم توی یه حلقهء while خارجی دیگه با شرط true.
اینطور اسکریپت اگر Timeout خارجی موجب پایانش نشه هیچوقت خاتمه پیدا نمیکنه.


سوال دیگه اینکه ایا تابعی ارائه شده که اگه زمان اجرای اسکریپت به پایان رسید به صورت اتوماتیک یه پیام هشدار تولید کنه؟
منظورت تابع PHP سمت سرور هست؟
ضمنا چرا فکر میکنی به چنین تابعی نیاز داری؟ PHP که خودش برای Timeout پیام خطا تولید میکنه.

A B C D
جمعه 04 شهریور 1390, 17:54 عصر
تلفظ درست comet : کامت :چشمک:
مطمئنی؟ منبعت چی بوده؟ تلفظ دیکشنری بابیلون؟

idocsidocs
جمعه 04 شهریور 1390, 18:39 عصر
خب کل کد برنامه رو میذاریم توی یه حلقهء while خارجی دیگه با شرط true.
اینطور اسکریپت اگر Timeout خارجی موجب پایانش نشه هیچوقت خاتمه پیدا نمیکنه.


منظورت تابع PHP سمت سرور هست؟
ضمنا چرا فکر میکنی به چنین تابعی نیاز داری؟ PHP که خودش برای Timeout پیام خطا تولید میکنه.

خب کل کد برنامه رو میذاریم توی یه حلقهء while خارجی دیگه با شرط true.
اینطوریکه دیگه برنامه به پایان نمی رسه و مرتبا ادامه پیدا می کنه ! البته به مدت 30 ثانیه ادامه پیدا می کنه و بعد متوقف می شه.


ضمنا چرا فکر میکنی به چنین تابعی نیاز داری؟ PHP که خودش برای Timeout پیام خطا تولید میکنه.اگر با استفاده از error_reporting امکان نمایش خطا ها رو غیر فعال کنیم، این خطا نمایش داده نمی شه.

البته اگر این خطا از نوع خطاهای فتال باشه، تابع error_reporting نمی تونه جلوی نمایش خطا رو بگیره. شما نمی دونیداین خطا جز کدوم یکی از انواع خطاها و هشدارهاست؟

A B C D
جمعه 04 شهریور 1390, 20:41 عصر
اینم کامیت به شکل Streaming

کد سمت سرور در فایلی بنام get_msg.php ذخیره شود:


<?php

header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Cache-Control: private, no-cache, must-revalidate, post-check=0, pre-check=0, max-age=0");
header('Pragma: private');
header("Pragma: no-cache");

header('Content-Type: text/html; charset=utf-8');

set_time_limit(0);

$msg_file='msg.txt';

for($i=0; $i<1024; $i++) echo ' ';

while(true) {

clearstatcache();
while(filesize($msg_file)==0) {
usleep(500000);
clearstatcache();
}

$fp=fopen($msg_file, "r+");
flock($fp, LOCK_EX);
$msg=fread($fp, filesize($msg_file));
ftruncate($fp, 0);
fclose($fp);

$msg=addslashes($msg);
$msg=str_replace("\n", '\n', $msg);
$msg=str_replace("\r", '', $msg);

echo '<script>parent.add_msg("', $msg, '");</script>';
@ ob_flush();
flush();

}

?>
چون ساختار کلی بخش سمت سرور برنامه خیلی شبیه به فایل روش Long polling هست فقط جاهایی رو توضیح میدم که با اون تفاوت دارن.
اولا که ما کل برنامه رو در یک while با شرط true گذاشتیم که الگوریتم برنامه پس از ارسال هر پیام دوباره از اول تکرار بشه.
ضمنا set_time_limit(0) باعث میشه تا زمان اجرای برنامه نامحدود باشه و دچار خطای Timeout نشه.

بوسیله خط for($i=0; $i<1024; $i++) echo ' ' تعداد کافی کاراکتر رو به مرورگرهایی مثل IE که برای شروع اجرا و نمایش محتویات نیاز به یک حداقل اولیه از کاراکترهای دریافت شده دارن ارسال میکنیم.

فرق دیگه اینه که بجای ارسال پیام خام به سمت کلاینت، که در مرورگر بوسیلهء ایجکس اون پیام رو میگرفتیم و به کادر متنی اضافه میکردیم، اینجا ما پیام رو بصورت آرگومان فراخوانی یک تابع جاوااسکریپت که در صفحهء اصلی سمت کلاینت تعریف شده ارسال میکنم تا اون تابع با این پیام بعنوان آرگومان اجرا بشه و پیام رو به textarea اضافه کنه. ما با این سه خط کد جاوااسکریپت لازم برای این کار رو به فریم داخلی صفحهء سمت کلاینت ارسال میکنیم:


echo '<script>parent.add_msg("', $msg, '");</script>';
ob_flush();
flush();

دو خط آخر این کد بخاطر این هستن که PHP و آپاچی خروجی ما رو بافر نکنن (که در اینصورت به مرورگر نمیرسه) و هرچی در بافر هست رو سریعا به مرورگر ارسال کنن تا در اونجا اجرا بشه.

کد صفحهء سمت کلاینت که صفحه ای است که در مرورگر اجرا میکنید:

<?php
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Cache-Control: private, no-cache, must-revalidate, post-check=0, pre-check=0, max-age=0");
header('Pragma: private');
header("Pragma: no-cache");

header('Content-Type: text/html; charset=utf-8');
?>
<html>
<head>
<script>

var txt;

function add_msg(msg) {
txt.value=parent.txt.value+"\n"+'received message: '+msg;
}

function load() {
txt=document.getElementById('txt');
txt.value='';
document.getElementById('comet_frame').src='get_ms g.php';
}

</script>
</head>
<body onload="load();">
<center>
<span style="vertical-align: top">Messages:</span>
<textarea id="txt" style="width: 300; height: 300;"></textarea>
<iframe id="comet_frame" src="about:blank" style="display: none" />
</center>
</body>
</html>
فکر نمیکنم این کد ساده و کوتاه نیازی به توضیح خاصی داشته باشه.
تنها کار مهمی که میکنیم اینه که با تنظیم آدرس فریم داخلی به get_msg.php در سمت سرور، اجرای نامحدود get_msg.php رو موجب میشیم که هر بار که پیامی دریافت میکنه یک تگ و دستور جاوااسکریپت رو برای اجرا به مرورگر ارسال میکنه که باعث فراخوانی تابع add_msg که در صفحهء اصلی تعریف شده با پیام ارسال شده بعنوان آرگومان میگردد.

خب ظاهرا پیاده سازی روش Streaming ساده تر و کوتاهتر از روش Long polling بود، اما این فقط یک مثال ساده و ناقص هست برای نشان دادن الگوریتم کلی.
ضمنا توجه کنید که get_msg.php در پشت صحنهء وب سرور بصورت نامحدود اجرا میشه و بنابراین صفحهء سمت کلاینت رو برای هر بار تست بیش از یک بار اجرا نکنید چون باعث میشه علاوه بر پردازش get_msg.php قبلی یک پردازش جدید هم اضافه بشه و این دوتا در کار هم اختلال ایجاد میکنن.
ضمنا برای توقف یا ریستارت آپاچی راهی ندارید جز اینکه با استفاده از Task manager ویندوز پراسسهای آپاچی رو kill کنید.

یادتون نره باید پیامها رو بصورت دستی در فایل msg.txt وارد و سیو کنید (این فایل باید از قبل موجود باشه).

راستی این کدها:

$msg=addslashes($msg);
$msg=str_replace("\n", '\n', $msg);
$msg=str_replace("\r", '', $msg);

بخاطر این هستن که اگر پیام حاوی کاراکترهایی مثل کوتیشن و New line بود چون اینها موقعی که در رشته ای بعنوان آرگومان تابع جاوااسکریپت add_msg بصورت خام درج میشن باعث خطای سینتاکس در جاوااسکریپت میشن، ما اونها رو Escape میکنیم.

--------------

ویرایش:
چون نرم افزار فروم گاهی کدهای نمایش داده شده رو خراب میکنه فایلهای برنامه رو ضمیمه کردم.
عجب گیری افتادیم از دست این نرم افزار نمایش کدهای فروم. یجا تگ br رو حذف میکنه، یجا بین کاراکترها فاصله میندازه، ... .

A B C D
جمعه 04 شهریور 1390, 21:00 عصر
اگر با استفاده از error_reporting امکان نمایش خطا ها رو غیر فعال کنیم، این خطا نمایش داده نمی شه.

البته اگر این خطا از نوع خطاهای فتال باشه، تابع error_reporting نمی تونه جلوی نمایش خطا رو بگیره. شما نمی دونیداین خطا جز کدوم یکی از انواع خطاها و هشدارهاست؟
اونطور که دیدم تابع error_reporting با آرگومان صفر جلوی همهء پیامها رو میگیره. حتی پیام خطای فیتال رو.
Timeout هم خطای Fatal است.

بنده تلاش کردم از تابع register_shutdown_function و connection_status برای آشکار سازی Timeout و ارسال پیام به مرورگر استفاده کنم، اما این روش یک بار درست کار میکنه و یک بار درست کار نمیکنه! انگار باگی چیزی داشته باشه!

بهرحال ما اگر بخوایم در مرورگر از خطای سمت سرور مطلع بشیم بنظرم همون راهکارهای غیرمستقیم کارمون رو بحد کافی راه میندازن. مثلا اضافه کردن رشتهء خاصی به ابتدای پیامهای درست که قبلا مطرح و استفاده شده. یا ایدهء دیگری که بنظرم میرسه اینه که در آخرین خط اسکریپت PHP یک دستور echo بذاریم که رشتهء خاصی رو به مرورگر ارسال میکنه. اگر این رشته رو در مرورگر دریافت کنیم میتونیم فرض کنیم که خطای Timeout رخ نداده چون برنامه تا آخرین خط اجرا شده.

idocsidocs
شنبه 05 شهریور 1390, 01:05 صبح
اونطور که دیدم تابع error_reporting با آرگومان صفر جلوی همهء پیامها رو میگیره. حتی پیام خطای فیتال رو.
Timeout هم خطای Fatal است.

بنده تلاش کردم از تابع register_shutdown_function و connection_status برای آشکار سازی Timeout و ارسال پیام به مرورگر استفاده کنم، اما این روش یک بار درست کار میکنه و یک بار درست کار نمیکنه! انگار باگی چیزی داشته باشه!

بهرحال ما اگر بخوایم در مرورگر از خطای سمت سرور مطلع بشیم بنظرم همون راهکارهای غیرمستقیم کارمون رو بحد کافی راه میندازن. مثلا اضافه کردن رشتهء خاصی به ابتدای پیامهای درست که قبلا مطرح و استفاده شده. یا ایدهء دیگری که بنظرم میرسه اینه که در آخرین خط اسکریپت PHP یک دستور echo بذاریم که رشتهء خاصی رو به مرورگر ارسال میکنه. اگر این رشته رو در مرورگر دریافت کنیم میتونیم فرض کنیم که خطای Timeout رخ نداده چون برنامه تا آخرین خط اجرا شده.
باید روی روش Streaming دقیق تر بشم. چون ظاهرا علاوه بر مرورگر باعث اخلال در سرور هم می شه.


اونطور که دیدم تابع error_reporting با آرگومان صفر جلوی همهء پیامها رو میگیره. حتی پیام خطای فیتال رو.
Timeout هم خطای Fatal است.
تابع error_reportingروی خطاهای مهلک اثر نمی کنه و نمی تونه جلوی نمایش این خطاها رو بگیره. مطمئن هستید که مطلبی که گفتید درست هست؟
اگر این تابع روی خطاهای مهلک اثر نذاره دیگه نیازی به ترفند زدن نیست.

idocsidocs
شنبه 05 شهریور 1390, 12:44 عصر
اینم کامیت به شکل Streaming

چندتا سوال در مورد این روش:
1- چه مرورگرهایی به حلقه زیر احتیاج دارن؟ اگر بجای این حلقه یه رشته با طول 1024 کاراکتر ارسال کنیم مشکلی پیش می یاد؟

بوسیله خط for($i=0; $i<1024; $i++) echo ' ' تعداد کافی کاراکتر رو به مرورگرهایی مثل IE که برای شروع اجرا و نمایش محتویات نیاز به یک حداقل اولیه از کاراکترهای دریافت شده دارن ارسال میکنیم.
2- در اصل می شه گفت که نکته اصلی این روش استفاده از فریم هست. سوالی که در این مورد دارم اینه که چرا خصوصیت src مربوط به فریم رو به کمک تابع load تعیین می کنید؟
3- سوال اصلی که برام گنگ هست اینه که اسکریپت پی اچ پی با استفاده از فریم فراخوانی می شه و پیامها باید به فریم ارسال بشن، ولی تکست آریا توی فریم نیست، آیا استفاده از parent توی کد جاوا اسکریپت باعث می شه که پیامها بجای فریم، توی صفحه دربرگیرنده تکست آریا نمایش داده بشن؟
4- چه مرورگرهایی روش Streaming رو بخوبی اجرا نمی کنن؟ تا اونجا که از این کدها مشخصه نکته اصلی این روش استفاده از فریم و parent هست، بنظرم همه مروگرها به راحتی این روش رو پیاده می کنن و نباید مشکلی با این روش داشته باشن. لطفا در این مورد توضیح بدید.

A B C D
شنبه 05 شهریور 1390, 13:42 عصر
1- چه مرورگرهایی به حلقه زیر احتیاج دارن؟

IE فکر کنم به کمتر نیاز داره ولی خونده بودم بعضی مرورگرها بیشتر میخوان.
حالا ما همینطوری یه چیزی ارسال کردیم. شاید باید بیشتر هم باشه یا کمتر.


اگر بجای این حلقه یه رشته با طول 1024 کاراکتر ارسال کنیم مشکلی پیش می یاد؟
2*2=4


2- در اصل می شه گفت که نکته اصلی این روش استفاده از فریم هست.
آره فکر کنم.


سوالی که در این مورد دارم اینه که چرا خصوصیت src مربوط به فریم رو به کمک تابع load تعیین می کنید؟
واسه اینکه اونوقت صفحهء اصلی هم در حالت لودینگ باقی میمونه.
ضمنا صفحهء اصلی باید اول لود بشه تا از امکان دسترسی به textarea مطمئن باشیم.


آیا استفاده از parent توی کد جاوا اسکریپت باعث می شه که پیامها بجای فریم، توی صفحه دربرگیرنده تکست آریا نمایش داده بشن؟
بله.


4- چه مرورگرهایی روش Streaming رو بخوبی اجرا نمی کنن؟ تا اونجا که از این کدها مشخصه نکته اصلی این روش استفاده از فریم و parent هست، بنظرم همه مروگرها به راحتی این روش رو پیاده می کنن و نباید مشکلی با این روش داشته باشن. لطفا در این مورد توضیح بدید.
نمیدونم تست نکردم. بهرحال مقالهء ویکیپدیا اینطور گفته که مشکلاتی داره.
بعدش بهرحال این کد خیلی ناقصه.
اول باید تمام حالات رو هندل کنیم بعد ببینیم چطوریه. خیلی محدودیت ها و مشکلات وقتی برنامهء کاملی بنویسی و تست کنی خودشون رو نشون میدن.
مثلا موقعی که کاربر صفحه رو رفرش میکنه باید اجرای برنامهء سمت سرور رو متوقف کنی.
موقعی که برنامه سمت سرور دچار خطا میشه باید چکار کرد؟ یعنی چطوری متوجه بشیم و چطوری هندل کنیم.
و غیره و غیره.

idocsidocs
شنبه 05 شهریور 1390, 14:23 عصر
IE فکر کنم به کمتر نیاز داره ولی خونده بودم بعضی مرورگرها بیشتر میخوان.
حالا ما همینطوری یه چیزی ارسال کردیم. شاید باید بیشتر هم باشه یا کمتر.


2*2=4


آره فکر کنم.


واسه اینکه اونوقت صفحهء اصلی هم در حالت لودینگ باقی میمونه.
ضمنا صفحهء اصلی باید اول لود بشه تا از امکان دسترسی به textarea مطمئن باشیم.


بله.


نمیدونم تست نکردم. بهرحال مقالهء ویکیپدیا اینطور گفته که مشکلاتی داره.
بعدش بهرحال این کد خیلی ناقصه.
اول باید تمام حالات رو هندل کنیم بعد ببینیم چطوریه. خیلی محدودیت ها و مشکلات وقتی برنامهء کاملی بنویسی و تست کنی خودشون رو نشون میدن.
مثلا موقعی که کاربر صفحه رو رفرش میکنه باید اجرای برنامهء سمت سرور رو متوقف کنی.
موقعی که برنامه سمت سرور دچار خطا میشه باید چکار کرد؟ یعنی چطوری متوجه بشیم و چطوری هندل کنیم.
و غیره و غیره.

منظور از "2*2=4" چی هست؟ در مورد ایجاد خطا توی اسکریپت سمت سرور باید بگم که می تونیم از بلاک try و throw برای مدیریت خطاهای ایجاد شده استفاده کنیم. می تونیم کدها رو توی بلاک try قرار بدید تا اگر خطایی توی کدها ایجاد شد، اجرا به بلاک throw منتقل بشه و اونجا یه پیام نمایش بدیم و با تابع exit اجرای برنامه رو به پایان برسونیم. البته اگر پی اچ پی با استفاده از این روش بتونه بر روی همه خطاها تاثیر بذاره و اونها رو مدیریت کنه. نظر شما چیه؟

A B C D
شنبه 05 شهریور 1390, 14:59 عصر
منظور از "2*2=4" چی هست؟
یعنی چیزی که پرسیدی مثل اینه که بگی آیا 2*2 برابر 4 است یا نه.


در مورد ایجاد خطا توی اسکریپت سمت سرور باید بگم که می تونیم از بلاک try و throw برای مدیریت خطاهای ایجاد شده استفاده کنیم. می تونیم کدها رو توی بلاک try قرار بدید تا اگر خطایی توی کدها ایجاد شد، اجرا به بلاک throw منتقل بشه و اونجا یه پیام نمایش بدیم و با تابع exit اجرای برنامه رو به پایان برسونیم. البته اگر پی اچ پی با استفاده از این روش بتونه بر روی همه خطاها تاثیر بذاره و اونها رو مدیریت کنه. نظر شما چیه؟
بعضی چیزها با این روش قابل مدیریت نیست یا حداقل بسادگی ممکن نیست.
مثلا من یه عملیات تقسیم بر صفر در بخش try گذاشتم که ظاهرا در PHP اصلا خطا محسوب نمیشه و فقط یک پیام هشدار چاپ شد.
یا مثلا این روش قادر به هندل کردن خطای Timeout نیست.
بعد تازه خطاها فقط بر اثر PHP نیستن. مثلا آپاچی ممکنه دچار مشکل بشه یا سرور به هر علتی دچار اختلال بشه یا ارتباط گسیخته بشه و غیره.
مدیریت خطا در سمت سرور در PHP به کنار، اما این کافی نیست. شما باید در سمت کلاینت هم تمام حالات خطا و حداقل حالات خطای متداول رو چک و هندل کنید و درصورت لزوم برنامه راه اندازی مجدد بشه.
و خب حالا باید ببینیم با استفاده از فریم چطور باید این کار رو انجام بدیم.
البته این بحثی هست که بنده الان ندارم؛ هدف از این تاپیک فقط نشان دادن روش کلی کامیت بود که انجام شد. درمورد جزییاتش جز اینکه مطالعه کنم و کلی نظر بدم و تستهای دم دستی محدودی انجام بدم کار دیگری نیست.

idocsidocs
شنبه 05 شهریور 1390, 16:09 عصر
یعنی چیزی که پرسیدی مثل اینه که بگی آیا 2*2 برابر 4 است یا نه.


بعضی چیزها با این روش قابل مدیریت نیست یا حداقل بسادگی ممکن نیست.
مثلا من یه عملیات تقسیم بر صفر در بخش try گذاشتم که ظاهرا در PHP اصلا خطا محسوب نمیشه و فقط یک پیام هشدار چاپ شد.
یا مثلا این روش قادر به هندل کردن خطای Timeout نیست.
بعد تازه خطاها فقط بر اثر PHP نیستن. مثلا آپاچی ممکنه دچار مشکل بشه یا سرور به هر علتی دچار اختلال بشه یا ارتباط گسیخته بشه و غیره.
مدیریت خطا در سمت سرور در PHP به کنار، اما این کافی نیست. شما باید در سمت کلاینت هم تمام حالات خطا و حداقل حالات خطای متداول رو چک و هندل کنید و درصورت لزوم برنامه راه اندازی مجدد بشه.
و خب حالا باید ببینیم با استفاده از فریم چطور باید این کار رو انجام بدیم.
البته این بحثی هست که بنده الان ندارم؛ هدف از این تاپیک فقط نشان دادن روش کلی کامیت بود که انجام شد. درمورد جزییاتش جز اینکه مطالعه کنم و کلی نظر بدم و تستهای دم دستی محدودی انجام بدم کار دیگری نیست.

این روش بهتره. این مشکلاتی که می گید برای این هست که زمان اجرای اسکریپت رو به صورت نامحدود تعیین کردید. برای مشکلاتی که گفتید بنظرم باید یه حالت میانی بین هر دو روشی که توضیح دادید ایجاد کنیم. مثلا زمان اجرای اسکریپت سمت سرور رو 10 دقیقه (البته 20 یا 30 دقیقه و بیشتر هم می شه) در نظر بگیریم، بعد از اینکه 10 دقیقه تمام شد اسکریپت سمت سرور متوقف می شه و کلاینت هم باید مجددا اتصال رو برقرار کنه. اینطوری از مزایای روش streaming بهره می بریم و خطاهای تحت سرور هم از بین می رن و نسبت به روش long poll هر 10 دقیقه فقط یه درخواست ارسال می شه. نظرتون چیه؟

A B C D
شنبه 05 شهریور 1390, 16:46 عصر
این روش بهتره.
کدوم روش؟


این مشکلاتی که می گید برای این هست که زمان اجرای اسکریپت رو به صورت نامحدود تعیین کردید.
کدوم مشکلات؟


مثلا زمان اجرای اسکریپت سمت سرور رو 10 دقیقه (البته 20 یا 30 دقیقه و بیشتر هم می شه) در نظر بگیریم، بعد از اینکه 10 دقیقه تمام شد اسکریپت سمت سرور متوقف می شه و کلاینت هم باید مجددا اتصال رو برقرار کنه. اینطوری از مزایای روش streaming بهره می بریم و خطاهای تحت سرور هم از بین می رن و نسبت به روش long poll هر 10 دقیقه فقط یه درخواست ارسال می شه. نظرتون چیه؟
بهرحال تا نری توی کار و پیاده سازی و تست نکنی معلوم نمیشه.
همه چیز رو نمیشه پیشبینی کرد. حتی اگر خیلی حرفه ای باشی.
شما میخوای streaming استفاده کنی استفاده کن. بسم ا... . منکه نگفتم استفاده نکن.
این تاپیک قصدش نشون دادن الگوریتم کلی بود، که انجام شد. و چیزهایی هم که گفتیم بر اساس منابع بود.
بقیش دیگه داره میشه حرف زدن بیخودی و کم ارزش. بقول یارو میگه show me your code
اون موقع که کد بنویسی و تست کنی هست که همهء داستان مشخص میشه.
تازه بعضی چیزا هرچی هم تست میکنی معلوم نمیشه ولی بعدا توی کار و در شرایط طبیعی تر یا بعکس شرایط خاص تر مشخص میشه.

راستی من فکر کردم به اینکه آیا روش کامیت مثلا اگر برای یه چت عمومی پیاده بشه باعث تسهیل حمله های DOS نمیشه؟ چون بنظر میرسه اگر هر درخواست برای مدت طولانی در حال اجرا و در حافظه بمونه خیلی سریعتر و راحتتر میشه با درخواستهای جعلی زیاد سرور رو از پا درآورد.

خلاصه هرچیزی جنبه های زیادی داره. یکسری رو میشه تئوریک پیشبینی کرد و تست کرد و راهکار داد، یکسری رو نمیشه. بعکس یکسری رو هم بصورت عملی نمیشه یا خیلی مشکله فهمید و تست کرد و باید بصورت تئوریک تحلیلشون کرد. این رشته وسعت و پیچیدگی و تنوع زیادی داره و خب واقعا هم جالب و جذاب و قدرتمنده.

amin1softco
شنبه 05 شهریور 1390, 17:20 عصر
میگم نکنه کاربر A B C D همون
eshpilen (http://barnamenevis.org/member.php?148005-eshpilen)

محروم شده باشه نکنه با این دوستمون دعواش شده هکش کرد؟! آخه دلیل محرومیتش چیه؟!

idocsidocs
شنبه 05 شهریور 1390, 17:27 عصر
کدوم روش؟


کدوم مشکلات؟

بهرحال تا نری توی کار و پیاده سازی و تست نکنی معلوم نمیشه.
همه چیز رو نمیشه پیشبینی کرد. حتی اگر خیلی حرفه ای باشی.
شما میخوای streaming استفاده کنی استفاده کن. بسم ا... . منکه نگفتم استفاده نکن.
این تاپیک قصدش نشون دادن الگوریتم کلی بود، که انجام شد. و چیزهایی هم که گفتیم بر اساس منابع بود.
بقیش دیگه داره میشه حرف زدن بیخودی و کم ارزش. بقول یارو میگه show me your code
اون موقع که کد بنویسی و تست کنی هست که همهء داستان مشخص میشه.
تازه بعضی چیزا هرچی هم تست میکنی معلوم نمیشه ولی بعدا توی کار و در شرایط طبیعی تر یا بعکس شرایط خاص تر مشخص میشه.

راستی من فکر کردم به اینکه آیا روش کامیت مثلا اگر برای یه چت عمومی پیاده بشه باعث تسهیل حمله های DOS نمیشه؟ چون بنظر میرسه اگر هر درخواست برای مدت طولانی در حال اجرا و در حافظه بمونه خیلی سریعتر و راحتتر میشه با درخواستهای جعلی زیاد سرور رو از پا درآورد.

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

حتی اگه از درخواستهای آژاکس که با تاخیر 1 ثانیه ای ارسال می شن هم استفاده کنیم، باز هم امکان کارهای مخرب و پایین کشیدن سیستم، زیاد پیش می یاد.

به هر حال آموزش خوبی بود، من اگه خواستم از کامیت استفاده کنم، از یه روش که مخلوطی از long poll و streaming هست استفاده می کنم.

به غیر از کایمت روش دیگه ای هم برای طراحی سیستم چت وجود داره؟

A B C D
شنبه 05 شهریور 1390, 18:45 عصر
به راههای هک کردن از طریق پنجره های چت عمومی قبلا فکر کرده بودم.یعنی چطوری مثلا؟


حتی اگه از درخواستهای آژاکس که با تاخیر 1 ثانیه ای ارسال می شن هم استفاده کنیم، باز هم امکان کارهای مخرب و پایین کشیدن سیستم، زیاد پیش می یاد.هان فکر کنم شما یطور دیگه فکر کردی.
نه قربونت هکر نیازی نداره از برنامهء شما و پنجرهء مرورگر برای پایین کشیدن سایت شما استفاده کنه.
یعنی شما فکر میکنی هکر میاد 100 تا از پنجرهء شما رو باز میکنه تا سایت رو بکشه پایین؟
البته این کار رو ممکنه افراد دیگه ای بکنن، اما یه هکر حرفه ای ابزارها و راههای پیشرفته تری داره.


به هر حال آموزش خوبی بود، من اگه خواستم از کامیت استفاده کنم، از یه روش که مخلوطی از long poll و streaming هست استفاده می کنم.تاحالا مخلوطش رو ندیدم :متفکر:


به غیر از کایمت روش دیگه ای هم برای طراحی سیستم چت وجود داره؟ روش غیرکامیت رو پیاده سازی و در شرایط واقعی تست نکردم و بنابراین نمیتونم بگم غیرقابل استفاده است. شاید اونقدرها هم بد نباشه.
ضمنا ابزارهایی مثل فلش هم هست. قدیما از جاوا هم زیاد استفاده میشد. به مرور کاربرد جاوا و فلش کمتر شد. بخصوص جاوا که تقریبا منقرض شد.

idocsidocs
شنبه 05 شهریور 1390, 19:34 عصر
یعنی چطوری مثلا؟

هان فکر کنم شما یطور دیگه فکر کردی.
نه قربونت هکر نیازی نداره از برنامهء شما و پنجرهء مرورگر برای پایین کشیدن سایت شما استفاده کنه.
یعنی شما فکر میکنی هکر میاد 100 تا از پنجرهء شما رو باز میکنه تا سایت رو بکشه پایین؟
البته این کار رو ممکنه افراد دیگه ای بکنن، اما یه هکر حرفه ای ابزارها و راههای پیشرفته تری داره.

تاحالا مخلوطش رو ندیدم :متفکر:

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

نه قربونت هکر نیازی نداره از برنامهء شما و پنجرهء مرورگر برای پایین کشیدن سایت شما استفاده کنه.اگه با یه نرم افزار درخواستهای اچ تی تی پی رو راه اندازی کنه، سرور برای هر درخواست یه پردازش ایجاد می کنه و دیگه نیازی به مرورگر نیست، در ضمن قرار نیست که حتما یه هکر حرفه ای سایت رو هک کنه !

الان سایت کلوب از فلش استفاده می کنه، فلش بدیش اینه که حتما باید فلش پلیر نصب باشه.

من سیستم چت تحت وب یاهو رو خیلی سبک و سریع می دونم. بنظرتون یاهو چطور و بر اساس چه سیستمی، سیستم چتش رو طراحی کرده؟

بنظر خودم بهترین راه اینه که پیامهای چت از سرور عبور نکنن و کاربرها مستقیما پیامها رو برای همدیگه بفرستن. در این مورد چیزی می دونید؟

A B C D
شنبه 05 شهریور 1390, 19:59 عصر
من سیستم چت تحت وب یاهو رو خیلی سبک و سریع می دونم. بنظرتون یاهو چطور و بر اساس چه سیستمی، سیستم چتش رو طراحی کرده؟ مگه فلش نیست؟

بنظر خودم بهترین راه اینه که پیامهای چت از سرور عبور نکنن و کاربرها مستقیما پیامها رو برای همدیگه بفرستن. در این مورد چیزی می دونید؟ خب اینطور هم میشه. ولی اونوقت چطور میشه به هویت طرف مقابل اعتماد کرد؟ حتما یه سرور و منبع مشترکی برای احراز هویت اولیه وجود داره.
ضمنا برای مراحل اولیهء برقراری ارتباط P2P هم بهرصورت یه سرور واسطه نیاز هست. اما بعد از برقراری ارتباط اولیه بقیهء ماجرا میتونه کاملا P2P باشه.
ضمنا P2P فکر نمیکنم از طریق PHP ممکن باشه، مگر اینکه هر کاربر روی سیستم خودش عملا یه وب سرور راه اندازی کنه. یعنی مثلا EasyPHP باید نصب باشه. یا اینکه برنامه بهش بدیم که توش PHP هم باشه. یا نمیدونم از فلش شاید بشه استفاده کرد و غیره.

idocsidocs
شنبه 05 شهریور 1390, 20:07 عصر
مگه فلش نیست؟
خب اینطور هم میشه. ولی اونوقت چطور میشه به هویت طرف مقابل اعتماد کرد؟ حتما یه سرور و منبع مشترکی برای احراز هویت اولیه وجود داره.
ضمنا برای مراحل اولیهء برقراری ارتباط P2P هم بهرصورت یه سرور واسطه نیاز هست. اما بعد از برقراری ارتباط اولیه بقیهء ماجرا میتونه کاملا P2P باشه.
ضمنا P2P فکر نمیکنم از طریق PHP ممکن باشه، مگر اینکه هر کاربر روی سیستم خودش عملا یه وب سرور راه اندازی کنه. یعنی مثلا EasyPHP باید نصب باشه. یا اینکه برنامه بهش بدیم که توش PHP هم باشه. یا نمیدونم از فلش شاید بشه استفاده کرد و غیره.

مگه فلش نیست؟نمی دونم منکه فکر کردم از جاوااسکریپت استفاده کرده.

خب اینطور هم میشه. ولی اونوقت چطور میشه به هویت طرف مقابل اعتماد کرد؟ حتما یه سرور و منبع مشترکی برای احراز هویت اولیه وجود داره.یعنی نرم افزار لایو زیلا کاربرهایی که درخواست چت با پشتیبان سایت رو تعیین هویت می کنه؟ برای سیستم چت عمومی چطور می خواید تعیین هویت کنید؟

A B C D
شنبه 05 شهریور 1390, 22:35 عصر
یعنی نرم افزار لایو زیلا کاربرهایی که درخواست چت با پشتیبان سایت رو تعیین هویت می کنه؟ برای سیستم چت عمومی چطور می خواید تعیین هویت کنید؟
نه برای چت عمومی که فکر نمیکنم نیازی به احراز هویت باشه.

ضمنا برای احراز هویت فکر میکنم بشه از Digital certificate سایت مرکزی هم استفاده کرد و لزوما نیازی به برقراری ارتباط اولیه با سرور مرکزی برای احراز هویت نباشه.
اما همونطور که گفتم بهرصورت برای برقراری ارتباط اولیه از نظر فنی نیاز به یک سرور واسطه هست. چون دو طرف باید به طریقی IP و پورت همدیگر رو بدست بیارن.

idocsidocs
جمعه 11 شهریور 1390, 07:00 صبح
نه برای چت عمومی که فکر نمیکنم نیازی به احراز هویت باشه.

ضمنا برای احراز هویت فکر میکنم بشه از Digital certificate سایت مرکزی هم استفاده کرد و لزوما نیازی به برقراری ارتباط اولیه با سرور مرکزی برای احراز هویت نباشه.
اما همونطور که گفتم بهرصورت برای برقراری ارتباط اولیه از نظر فنی نیاز به یک سرور واسطه هست. چون دو طرف باید به طریقی IP و پورت همدیگر رو بدست بیارن.
الان داشتم تاپک رو دوباره می خوندم و دیدم که شما گفتید:

باید بگم اسمش تقریبا معنی نداره و یک شوخی و بازی با کلماته.
چون دوتا کالای شوینده وجود داشته/داره بنام Ajax (http://en.wikipedia.org/wiki/Ajax_%28cleanser%29) و Comet (http://en.wikipedia.org/wiki/Comet_%28cleanser%29) که هیچ ربطی به کامپیوتر و برنامه نویسی ندارن. ظاهرا طرف دیده چون اسم یکی از این تمیزکننده ها شبیه اسم متد AJAX (http://en.wikipedia.org/wiki/Ajax_%28programming%29) در برنامه نویسی هست، گفته اسم این چیزی رو که اختراع کردم و یه چیزی مکمل یا در سطح AJAX هست میذارم Comet! سوالی که دارم اینه که آیا این روش دارای پتنت ثب شده هست یا اینکه مطلب بالا رو به طنز نوشتید؟

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

A B C D
جمعه 11 شهریور 1390, 09:25 صبح
چیزایی میگی خدایی!
طرف یه دستگاه جدید درست میکنه، با یه ایدهء جدید، بعد خب مسلمه توش از چرخ دنده و موتور الکتریکی و هرچی استفاده میکنه که توسط دیگران قبلا اختراع شدن. اونوقت چیزی که طرف ساخته اختراع نیست به این خاطر؟
درمورد اینکه کامیت Patent شده باشه یا نه اطلاعی ندارم، و اینکه دقیقا اختراع باشه یا نه، ولی بهرحال مهم اون ایدهء باز نگه داشتن کانکشن هست و استفاده از اون در زمان آینده/زمانی که شرایط/پاسخ لازم مهیا میشه، یا استفاده از اون برای چند پاسخ بجای یکی. اون ایده هست که باید بررسی کرد آیا کس دیگری قبلا ارائه کرده یا نه.
بهرحال شاید هم درحد اختراع نباشه، اما بهرحال یه ابتکار که هست.

A B C D
جمعه 11 شهریور 1390, 12:44 عصر
چیزی که بعنوان اختراع ثبت میشه یه ایده هست، نه شکل و ابزار پیاده سازی اون.
و اون ایده ممکنه فقط روی کاغذ بوده باشه و اصلا نمونهء واقعی ساخته شده هم نداره و بنابراین حتی ممکنه کسی مطمئن نباشه که در شرایط واقعی عملی هست یا نیست.
اون ایده ای که Patent شد، دیگه شما به هیچ صورتی نمیتونی ازش بدون اجازهء صاحب امتیاز استفاده کنی. فرضا در بخش سمت سرور کامیت از while استفاده نکنی و از یه چیز کاملا متفاوت استفاده کنی و در بخش سمت کلاینت هم از یه ترفند دیگه استفاده کنی، اما بازم اگر اساس کارت روی باز نگه داشتن ارتباط HTTP و منتظر رخ دادن شرایط مورد نظر موندن باشه، داری از همون ایدهء مرکزی و اساسی که کامیت باشه استفاده میکنی. البته این داستان ممکنه ظریف تر و پیچیده تر از این باشه، چون بستگی داره اون ایده در عمل چطور مطرح شده و تحت چه عنوانی ثبت شده. منظورم اینه که ممکنه به اون شکل مرکزی و اساسی خودش توسط ارائه کنندهء اون مطرح و ثبت نشده باشه.
اما خوشبختانه فکر نمیکنم کامیت بعنوان یه اختراع ثبت شده باشه، وگرنه دیگران نمیتونستن آزادانه ازش استفاده کنن (مگر اینکه طرف بعد از Patent کردن، استفاده از اون رو آزاد کرده باشه).
احتمالا کامیت اصلا شرایط لازم برای اختراع بودن رو نداره. ولی بهرحال یه ابتکاره.
منظور منم این نبود که حتما اختراعه. خواستم بگم بهرحال اونی که این روش رو ارائه کرده یا بهرصورت بعنوان پدر این روش شناخته شده، هر اسمی رو که دوست داشته روش گذاشته.


یا اینکه مطلب بالا رو به طنز نوشتید؟اگر منشاء نام کامیت رو میگی، خیر طنزی در کار نبوده. این چیزی هست که در مقالهء ویکیپدیا آمده و بنظر کاملا درست میاد؛ جای دیگری هیچ چیز دیگه ای در این ارتباط بیان نشده. اگر کامیت سرنام کلمات خاصی بود یا منشاء دیگری داشت بعید بود که توی اینهمه منبع مختلف بهش اشاره ای نشه.


اگر اینطور باشه هر کس می تونه به کمک دستورات آماده و از قبل نوشته شده روشهای جدید پیدا کنه و بره ثبت کنه ! البته توضیح دادم که اختراع در اصل اون ایدهء محوری هست و نه شکل و ابزار پیاده سازی.
ولی اوضاع Patent های نرم افزاری دست کمی از این حالتی که میگی نداره. چون از الگوریتم های ساده تا پیچیده رو بالاخره کسی یا شرکتی بنام خودش ثبت کرده.
تنها مواردی که ثابت بشه قبلا به شکلی مورد شناخت بودن یا مواردی که بیش از حد پایه و ساده یا بدیهی بنظر بیان یا بنوعی مورد استفادهء مردم باشن رو نمیشه Patent کرد.
در این بین نقش مسئولینی که Patent ها رو بررسی میکنن و تشخیص میدن که واجد شرایط اولیه و در نهایت اختراع هستن یا نیستن هم دخلیه. و این افراد هم مسلما مثل بقیهء انسانها دچار نقص و ضعف و اشتباه هستن.
کلا بسط دادن قانون Patent در حیطهء نرم افزار مشکلات و موارد غیرمنطقی زیادی رو موجب شده و مخالفان زیادی هم داره.
با تحقیقی که سالها پیش روی هستهء لینوکس انجام شد مشخص شد حدود 300 مورد Patent نرم افزاری در اون نقض شده؛ درحالیکه برنامه نویسان اون از این موارد هیچ خبر نداشتن!!
هر سال حدود صد هزار پتنت نرم افزاری در آمریکا ثبت میشه. تازه این آمار مربوط به چند سال پیشه.
از اونجایی که یک برنامهء بزرگ و پیچیده، در مقایسه با دستگاههای دارای ماهیت فیزیکی، مشابه یک دستگاه بسیار بزرگ و گسترده با قطعات و اجزای بسیار زیاد است، نوشتن چنین برنامه هایی بدون نقض کردن Patent های نرم افزاری تقریبا غیرممکنه. مگر اینکه هزینه و وقت و انرژی زیادی صرف کنید تا بتونید موارد نقض رو پیدا و حذف یا با الگوریتم های دیگری جایگزین کنید؛ تازه معلوم نیست این روش هم واقعا عملی باشه!

idocsidocs
جمعه 11 شهریور 1390, 14:57 عصر
چیزایی میگی خدایی!
طرف یه دستگاه جدید درست میکنه، با یه ایدهء جدید، بعد خب مسلمه توش از چرخ دنده و موتور الکتریکی و هرچی استفاده میکنه که توسط دیگران قبلا اختراع شدن. اونوقت چیزی که طرف ساخته اختراع نیست به این خاطر؟
درمورد اینکه کامیت Patent شده باشه یا نه اطلاعی ندارم، و اینکه دقیقا اختراع باشه یا نه، ولی بهرحال مهم اون ایدهء باز نگه داشتن کانکشن هست و استفاده از اون در زمان آینده/زمانی که شرایط/پاسخ لازم مهیا میشه، یا استفاده از اون برای چند پاسخ بجای یکی. اون ایده هست که باید بررسی کرد آیا کس دیگری قبلا ارائه کرده یا نه.
بهرحال شاید هم درحد اختراع نباشه، اما بهرحال یه ابتکار که هست.
حقیقتش رو بخواید تعجب می کنم که یه همچین ترفندی تونسته توی مقالات زیادی تحت یک نام واحد معرفی بشه.

حتما به یه جا استناد می کنن که همه از یک اسم استفاده می کنن، حالا یا این ایده ثبت شده یا بقیه برای حفظ کپی رایت اسمش رو تغییر نمی دن. بنظرم اگه توی ایران این روش پیاده می شد چند هزارتا اسم براش انتخاب می شد !

اگر سایت گر آواتار رو هم ببینید می بینید که اونم یه ترفند ساده هست ولی کسی نیومده از روش کپی بزنه و با تغییرات دلخواه شبیهش بسازه و بگه این ایده مال من بوده !

بنظرتون برای چی یک چنین ایده هایی پا می گیرن و بین مردم رواج پیدا می کنن و کسی هم ازشون کپی نمی زنه؟

A B C D
جمعه 11 شهریور 1390, 19:42 عصر
میشه منظورت رو واضحتر بگی؟ مفهوم نبود.

idocsidocs
جمعه 11 شهریور 1390, 19:50 عصر
میشه منظورت رو واضحتر بگی؟ مفهوم نبود.
ببینید روش کامیت که روش بحث کردیم در اصل از یه حلقه while و یه تابع usleep تشکیل شده. برای من عجیبه که می این روش با یک اسمم بین این همه برنامه نویس رواج پیدا کرده.

حتما ثبت شده که همه با این اسم می شناسنش.

در مورد سایت گرآواتار هم اگه نگاه کنید می بینید که هر کسی می تونه این سایت رو کپی برداری کنه ولی هیچ کس این کار رو نمی کنه.

حدس می زنم که روش کامیت و سایت گرآواتار و بقیه نوآوری های مشابه هم تحت حمایت یه مرجع قانونی هستن و ثبت شدن وگرنه به این سادگی بین کاربران نت مشهور نمی شن.

فکر کنم توی ایران برای ثبت نرم افزار جایی پیش بینی نشده.

A B C D
جمعه 11 شهریور 1390, 20:10 عصر
کامیت به نامهای دیگری هم شناخته میشه:
Ajax Push
Reverse Ajax
Two-way-web
HTTP Streaming
HTTP server push
...

بعدشم یه اسم مگه چه اهمیتی داره؟
مهم تاریخچه و اسم کسی هست که اولین بار اون رو اختراع کرده، که اینا هم توسط کسی قابل جعل نیستن.
البته بعضی چیزها رو یک نفر به تنهایی برای اولین بار بوجود نیاورده یا کلا اولین کسی که اونا رو بکار برده بصورت قطعی مشخص نیست.
بعضی چیزها توسط چند نفر در طول زمان تکمیل و بهینه سازی و قابل استفاده شدن و انصاف نیست فقط اسم یک نفر روش باشه. ولی گاهی به علتهای مختلف به اسم یک نفر مشهور میشه یا اسمی که یک نفر یا گروه خاص در زمان خاص براش انتخاب کرده متداول میشه.


ببینید روش کامیت که روش بحث کردیم در اصل از یه حلقه while و یه تابع usleep تشکیل شده. برای من عجیبه که می این روش با یک اسمم بین این همه برنامه نویس رواج پیدا کرده.حلقه while و یه تابع usleep فقط ابزار و شکل پیاده سازی یه ایده هستن.
مهم اون ایده هست که برای اولین بار به ذهن کسی برسه و پیاده سازی کنه.
AJAX هم چنین چیزی بوده. وگرنه چیزهایی که در پیاده سازی AJAX میرن لزوما هیچکدام اختراع و چیز جدیدی نیستن. مهم ایدهء اولیه هست که کسی فکر کرده با فناوریها و امکانات استاندارد موجود، پشت صحنه چجوری درخواست بفرسته و جوابش رو از سرور بگیره و در صفحهء جاری استفاده کنه. درحالیکه دیگران ذهنشون طرف چنین فکری و ممکن بودن اون نمیرفته یا بهرصورت بیشتر در این وادی پیش نمیرفتن و به نتیجه نمیرسیدن. اینکه اولین بار یه چیزی رو ابداع کنی تفاوت داره با اینکه کسی بهت بگه یا دیگران قبلا انجام داده باشن و مشابهش رو دیده باشی. چون دراینصورت کار خیلی راحتتر میشه (بقول معروف که میگن معما چون حل شود آسان شود).
درمورد کامیت هم ایده این بوده که نیازی نیست فورا جوابی داده بشه و کانکشن بسته بشه.
شما خودت این ایده تاحالا بنظرت رسیده بود؟
منم این ایده بنظرم نرسیده بود، اما به محض اینکه این ایده رو خوندم تونستم یه روش پیاده سازی براش طراحی کنم که همون حلقه while و یه تابع usleep باشه. میبینی که بین این دوتا تفاوت هست. یعنی ایدهء محوری به سادگی به ذهن کسی نمیرسه، در عین اینکه چیز پیچیده ای هم نیست، اما استفاده از حلقه while و یه تابع usleep خیلی راحت و سریع برای پیاده سازی اون ایده به ذهن آدم میرسه.

iranme
جمعه 11 شهریور 1390, 20:42 عصر
خیلی ممنون از آموزشتون، خیلی خوب توضیح دادید ولی ببخشید این دو روش رو وقتی من در کامپیوتر خودم اجرا میکنم کار نمیکنه!
روش long polling که به صورت دلخواه نشان میده!!! یعنی از هر 10 باری که یک متن داخل اون فایل مینویسم شاید 6-7 تاش رو نشان میده! در ضمن در مرورگر IE هم اصلا نشان نمیده!
روش streaming هم که چند تا مرورگر را با هم باز میکنم تا ببینم در همه مرورگر ها نشان داده میشه یا نه فقط در مرورگری نمایش داده میشه که در اون لحظه انتخاب شده است و در بقیه مرورگر ها انگار هیچ اتفاقی نیفتاده است!

اگر میشه لطف کنید در مورد این پست هم نظرتون رو اعلام کنید که آیا با روش کامیت قابل پیاده سازی هست یا نه از طریق همون روشی که آقای hossin.esm (http://barnamenevis.org/member.php?110750-hossin.esm) اعلام کردند بهتر است!؟

پاسخ سرور در آن واحد به همه کلاینت ها (http://barnamenevis.org/showthread.php?273737-%D9%BE%D8%A7%D8%B3%D8%AE-%D8%B3%D8%B1%D9%88%D8%B1-%D8%AF%D8%B1-%D8%A2%D9%86-%D9%88%D8%A7%D8%AD%D8%AF-%D8%A8%D9%87-%D9%87%D9%85%D9%87-%DA%A9%D9%84%D8%A7%DB%8C%D9%86%D8%AA-%D9%87%D8%A7)

ممنون

A B C D
جمعه 11 شهریور 1390, 22:13 عصر
روش long polling که به صورت دلخواه نشان میده!!! یعنی از هر 10 باری که یک متن داخل اون فایل مینویسم شاید 6-7 تاش رو نشان میده! در ضمن در مرورگر IE هم اصلا نشان نمیده!نمونه کدهای این تاپیک صرفا برای نمایش و تست الگوریتم درحد پایه بودن و بنابراین قصد باگیابی و تکمیل اونا رو و اینکه در شرایط مختلف تست و تکمیل بکنیم تا کار بکنن نداریم. در همین حد که برای اکثریت کار کنن و بتونن روش و الگوریتم و مفهوم رو برسونن و نمایش بدن کافیه.
اینم که میگید بعضی وقتا نشون نمیده احتمالا بخاطر این هست که صفحهء مربوطه رو قبلا رفرش کردید یا چند بار باز کرده بودید و کد ما چون کامل نیست و با ریفرش یا بستن صفحهء جاری در کلاینت، در سمت سرور برنامه های مربوطه خاتمه پیدا نمیکنن و در حلقه های while دور میزنن این اشکال پیش میاد که یکسری از پیامها توسط اون برنامه های در حال اجرا که کانکشن HTTP اونها بسته شده و دیگه با مرورگر در ارتباط نیستن مصرف میشن!
اون یکی برنامهء چت رو که کاملتر هست تست کردید؟ (در تاپیک دیگه ای (http://barnamenevis.org/showthread.php?301496-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D8%A2%D8%B2%D9%85%D8%A7%DB%8C%D8%B4%DB%8C-%D8%A7%D9%84%DA%AF%D9%88%D8%B1%DB%8C%D8%AA%D9%85-%DA%86%D8%AA-Comet) ضمیمه شده، ولی در این تاپیک لینکش درج شده).
اون برنامه کاملتره و این مورد درش لحاظ شده. البته نه لزوما بصورت خیلی کامل و بهترین حالت اصولی؛ چون اون برنامه هم باز یه برنامهء آزمایشی بود.


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



اگر میشه لطف کنید در مورد این پست هم نظرتون رو اعلام کنید که آیا با روش کامیت قابل پیاده سازی هست یا نه از طریق همون روشی که آقای hossin.esm (http://barnamenevis.member.php?110750-hossin.esm) اعلام کردند بهتر است!؟

پاسخ سرور در آن واحد به همه کلاینت ها (http://barnamenevis.showthread.php?273737-%D9%BE%D8%A7%D8%B3%D8%AE-%D8%B3%D8%B1%D9%88%D8%B1-%D8%AF%D8%B1-%D8%A2%D9%86-%D9%88%D8%A7%D8%AD%D8%AF-%D8%A8%D9%87-%D9%87%D9%85%D9%87-%DA%A9%D9%84%D8%A7%DB%8C%D9%86%D8%AA-%D9%87%D8%A7)بنظرم استفاده از کامیت برای اون مورد که شما مطرح کردید ممکن هست. ولی آیا ضرورتی درش هست؟
کامیت بیشتر برای چیزهایی مثل چت و جاهای خاص دیگری که واقعا ارزشش رو داشته باشه استفاده میشه.
چون بهرحال برای کامیت یک کانکشن دائما با سرور برقرار هست که احتمالا هزینه و محدودیت و عوارض خاص خودش رو داره و بنابراین برای موارد غیرضروری منطقی نیست استفاده بشه.
درمورد پیاده سازی کامیت برای نیاز شما هم بنده رو معاف بفرمایید چون بنده وقت ندارم و تا الان هم چند وقته دارم سوالات دیگران رو جواب میدم و تحقیق انجام میدم که البته به نفع خودم هم بوده، بخاطر اینکه موضوعات عمومی و کلی بودن یا جنبه های عمومی و کلی مهمی هم داشتن و خودم هم چیزهای متعدد مهمی یاد گرفتم. ولی مورد شما چیز جدیدی از نظر مفهومی نداره و تنها پیاده سازی یک کاربرد خاص هست و ببخشید اینطوری میگم، کار و وظیفهء بنده نیست برنامهء شما رو براتون بنویسم. در این حد که روش پایه رو آموزش بدیم و سوالات و مشکلات کلی کامیت رو حل کنیم انجام شد و بقیش دیگه فعالیت و مهارت کاملا عادی هر برنامه نویسی هست که بتونه الگوریتم و روشهای کلی رو در برنامه ها و نیازهای خاص خودش بکار ببره.

idocsidocs
یک شنبه 13 شهریور 1390, 02:26 صبح
خیلی ممنون از آموزشتون، خیلی خوب توضیح دادید ولی ببخشید این دو روش رو وقتی من در کامپیوتر خودم اجرا میکنم کار نمیکنه!
روش long polling که به صورت دلخواه نشان میده!!! یعنی از هر 10 باری که یک متن داخل اون فایل مینویسم شاید 6-7 تاش رو نشان میده! در ضمن در مرورگر IE هم اصلا نشان نمیده!
روش streaming هم که چند تا مرورگر را با هم باز میکنم تا ببینم در همه مرورگر ها نشان داده میشه یا نه فقط در مرورگری نمایش داده میشه که در اون لحظه انتخاب شده است و در بقیه مرورگر ها انگار هیچ اتفاقی نیفتاده است!

اگر میشه لطف کنید در مورد این پست هم نظرتون رو اعلام کنید که آیا با روش کامیت قابل پیاده سازی هست یا نه از طریق همون روشی که آقای hossin.esm (http://barnamenevis.org/member.php?110750-hossin.esm) اعلام کردند بهتر است!؟

پاسخ سرور در آن واحد به همه کلاینت ها (http://barnamenevis.org/showthread.php?273737-%D9%BE%D8%A7%D8%B3%D8%AE-%D8%B3%D8%B1%D9%88%D8%B1-%D8%AF%D8%B1-%D8%A2%D9%86-%D9%88%D8%A7%D8%AD%D8%AF-%D8%A8%D9%87-%D9%87%D9%85%D9%87-%DA%A9%D9%84%D8%A7%DB%8C%D9%86%D8%AA-%D9%87%D8%A7)

ممنون
اگر امکانش هست لطفا نتایج آزمایشهاتون روی کامیت رو توی این تاپک قرار بدید.

iranme
یک شنبه 13 شهریور 1390, 10:32 صبح
اون یکی برنامهء چت رو که کاملتر هست تست کردید؟ (در تاپیک دیگه ای (http://barnamenevis.org/showthread.php?301496-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D8%A2%D8%B2%D9%85%D8%A7%DB%8C%D8%B4%DB%8C-%D8%A7%D9%84%DA%AF%D9%88%D8%B1%DB%8C%D8%AA%D9%85-%DA%86%D8%AA-Comet) ضمیمه شده، ولی در این تاپیک لینکش درج شده).

بلی تست کردم و جواب هم داده است!


بنظرم استفاده از کامیت برای اون مورد که شما مطرح کردید ممکن هست. ولی آیا ضرورتی درش هست؟
کامیت بیشتر برای چیزهایی مثل چت و جاهای خاص دیگری که واقعا ارزشش رو داشته باشه استفاده میشه.
چون بهرحال برای کامیت یک کانکشن دائما با سرور برقرار هست که احتمالا هزینه و محدودیت و عوارض خاص خودش رو داره و بنابراین برای موارد غیرضروری منطقی نیست استفاده بشه.
درمورد پیاده سازی کامیت برای نیاز شما هم بنده رو معاف بفرمایید چون بنده وقت ندارم و تا الان هم چند وقته دارم سوالات دیگران رو جواب میدم و تحقیق انجام میدم که البته به نفع خودم هم بوده، بخاطر اینکه موضوعات عمومی و کلی بودن یا جنبه های عمومی و کلی مهمی هم داشتن و خودم هم چیزهای متعدد مهمی یاد گرفتم. ولی مورد شما چیز جدیدی از نظر مفهومی نداره و تنها پیاده سازی یک کاربرد خاص هست و ببخشید اینطوری میگم، کار و وظیفهء بنده نیست برنامهء شما رو براتون بنویسم. در این حد که روش پایه رو آموزش بدیم و سوالات و مشکلات کلی کامیت رو حل کنیم انجام شد و بقیش دیگه فعالیت و مهارت کاملا عادی هر برنامه نویسی هست که بتونه الگوریتم و روشهای کلی رو در برنامه ها و نیازهای خاص خودش بکار ببره.

خیلی ممنون، ولی تاکید من برای استفاده از comet به این دلیل بود که کاری که من میخوام انجام بدم دارای یک تایم زمانی کوتاه (مثلا 10 ثانیه) است و هر ثانیه هم برای من مهم هست که از دست نره چون در اون زمان تعیین شده ممکن هست که خیلی از افراد درخواستی را بدهند و داده ها را تغییر بدهند و چون شما اطلاعاتتون از من خیلی بیشتر هست برای همین هم از شما سوال کردم که آیا این روش را توصیه میکنید یا خیر!؟
البته بنده هیچ وقت از شما درخواست حل این مساله رو نداشتم فقط سوالم در مورد این بود که اگر این روش را توصیه میکنید چطور این روش را با پایگاه داده انجام بدم چون اون طوری که من متوجه شدم شما در دو روش هم از فایل استفاده کردید و حجم فایل را در نظر گرفتید که در صورت این که حجم فایل بیشتر از 0 شد از حلقه while بیرون برود، حالا در mysql چطوری بفهمم که آخرین رکورد (شاید هم چند رکورد آخر) وارد شده چه بوده تا بتوانم از حلقه خارج بشوم!؟

iranme
یک شنبه 13 شهریور 1390, 10:35 صبح
اگر امکانش هست لطفا نتایج آزمایشهاتون روی کامیت رو توی این تاپک قرار بدید.
شرمنده متوجه نشدم منظورتون از نتایج آزمایش چی هست!؟ در همون پست گفتم که چطوری برام اجرا میشه و البته دوست خوبمون A B C D (http://barnamenevis.org/member.php?218827-A-B-C-D) دلیلش را گفتن که به خاطر چی بوده است.

idocsidocs
دوشنبه 14 شهریور 1390, 02:08 صبح
شرمنده متوجه نشدم منظورتون از نتایج آزمایش چی هست!؟ در همون پست گفتم که چطوری برام اجرا میشه و البته دوست خوبمون A B C D (http://barnamenevis.org/member.php?218827-A-B-C-D) دلیلش را گفتن که به خاطر چی بوده است.

زمان ارسال این تاپک با هم بوده و من نتونستم جواب دوستمون رو بگیرم.

hanels
چهارشنبه 16 مرداد 1392, 08:26 صبح
سلام
تو رو خدا همین آموزش رو توی asp.net خم بزارید من خیلی نیاز دازم

H:Shojaei
چهارشنبه 16 مرداد 1392, 16:07 عصر
سلام
دوست عزيز اولا كه اين تالار PHP هست و شما بايد تو تالار asp.net يه تاپيك ايجاد كنيد و به اين تاپيك لينك بديد بگيد يكي اين رو كه با PHP نوشته شده رو واستون پياده سازي كنه.
اگر كمك نكردن :شیطان: بگيد يعني اين برنامه كه با PHP نوشته شده قابل تبديل به asp.net نيست. بعد ميبينيد كه حس رقابتشون گل ميكنه و ... :چشمک:
موفق باشيد.

s_salavati2002
پنج شنبه 17 مرداد 1392, 03:53 صبح
از آموزشتون ممنون
البته استفاده از node.js هم در مواردی که به سرعت بالا احتیاج داریم خیلی می تونه کمک کنه
حتی به mysql هم وصل میشه
اگر علاقه مند بودید :
nodejs.org

vatansever
پنج شنبه 30 آبان 1392, 21:05 عصر
نه. مگه خواندن و نوشتن دیتابیس چقدر زمان میبره؟
طرفهایی که چت میکنن انسانند و خیلی کندتر از این هستن که تاخیر دیتابیس در برابر کندی تایپ و حواس اونها مشهود باشه.
برنامهء ما هم خودش در هر دور نیم ثانیه میخوابه و در این مدت حتی اگر پیامی باشه پردازش نمیکنه. البته میتونیم این زمان رو از این خیلی کمتر کنیم.
مگر در شرایطی که سرور چت ترافیک سنگین داره، یعنی تعداد زیادی کاربر بصورت همزمان درحال چت هستن، باشه که تفاوت سرعت میان دیتابیس و فایل مشهود بشه. اینکه در این برنامه ها از فایل استفاده شده بخاطر این بوده که این یک سیستم ساده و نمایشی هست و هیچ نیازی به دیتابیس و پیچیدگی کار با اون نداره و میخوایم مثال هم ساده و قابل درک و براحتی قابل نصب و تست باشه.

با سلام و تشكر از مطالب مفيدي كه تو اين تايپيك نوشتين
ميشه بگين چطور ميتونيم به جاي فايل از mysql بخونيم و وقتي سطر جديد اضافه شد نمايش بده.

كدي كه من سعي كردم و به نتيجه نرسيدم :


<?php

header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Cache-Control: private, no-cache, must-revalidate, post-check=0, pre-check=0, max-age=0");
header('Pragma: private');
header("Pragma: no-cache");

header('Content-Type: text/html; charset=utf-8');

$msg_file='msg.txt';

$con=mysql_connect("localhost","root","");
mysql_select_db("databasename",$con);


$sql=mysql_query("SELECT name FROM posts ORDER BY id DESC");
$num=mysql_num_rows($sql);
$ms=mysql_fetch_array($sql,MYSQL_BOTH);

clearstatcache();
while($num == 0) {
usleep(500000);
clearstatcache();

}



$msg=$ms['name'];
mysql_close($con);
echo '_-_', $msg;

?>