Comet בצורה שפויה

ב־12.8.2012, מאת ארתיום; פורסם תחת: תכנה חופשית, פיתוח, תכנה ומחשבים, CppCMS; ‏0 תגובות

‏ HTML5 ו־Comet

היום HTML5 מציע שני כלים עיקריים ליישומי ‏Comet‏:

מבחינה טכנית, WebSockets ‏(WS) מייצרים קשר דו־כיווני מלא ומאפשרים הן לשרת והן לקוח לשלוח הודעות בזמן אמת - בלי לפתוח קשרים נוספים. לעומת זאת Server-Sent Events‏ (SSE) זהו קשר חד־כיווני, בו השרת הוא זה ששולח אירועים ללקוח ואם הלקוח צריך לשלוח משהו לשרת, הוא משתשמש בכלי Ajax נוכחיים כמו XMLHttpRequest‏ (XHR).

למען האמת, עד עכשיו יצא לי לעקוב אחרי התפתחות של WS. הפרוטוקול החליף מספר גרסאות, הדפדפנים שינו את המימושים בהתאם עד שהפרוטוקול התייצב. כיום התמיכה ב־WS קיימת ברוב הדפדפנים עדכניים ואמורה להיכנס גם ל־IE10. לעומת זאת, כל הנושא של SSE חלף על פניי ולא שמתי עליו לב.

כיוון שאני מעסק בצד השרת בעיקר, הכנסתי את נושא ה־WS לתכנית העבודה שלי. אבל עדיין לא הצלחתי להגיע אליו; ולא במקרה.

למרות העתיד ה"זוהר" של WS, המימוש הוא לא פשוט. לא מדובר כאן בבעיה טכנית, הרי תמיכה ב־Comet כבר קיימת ועובדת יפה, הבעיה היא בעיה מהותית: כדי לממש WS צריך לשנות פרוטוקול HTTP. ברגע ש"לחיצה היד" של WS נגמרת, לא מדובר עוד ב־HTTP, אלא בפרוטוקול שונה לחלוטין.

לכן, הכלים ופרוטוקולים שבעזרתם יישומים מתקשרים עם שרתי Web, לא מתאימים. למשל, אי אפשר להעביר תקשורת של WS מעל FastCGI, SCGI או CGI. גם אם היישום שלך עובד ב־HTTP, לא כל שרת web ידע להתמודד עם הבעיה: החלפת ה־HTTP בפרוטוקול חלופי.

לכן, אפילו ש־WS, זאת טכנולוגיה מבטיחה, היא עדיין רחוקה מהבשלות האמתית.

לעומת זאת, SSE, שנדחקו הצדה, לא סובלים מהבעיות האלה!

  • SSE לא משנים את פרוטוקול ה־HTTP, לכן, אין בעיות שימוש בתשתיות הקיימות.
  • הביצועים של SSE לא נופלים על אלה של WS.

  • SSE הרבה יותר קלים לתפעול:

    • מכילים מנגנון סנכרון אוטומטי, במקרה של התנתקות
    • מאפשרים לשלוח אירועים שונים ברמת JavaScript בלי שכבות נוספות
    • ניתן לסגת בקלות ל־Long Polling עם XHR פשוט במקרה שהדפדפן לא תומך ב־SSE.

החיסרון היחידי של SSE לעומת WS: לא ניתן לשלוח הודעות באותו הקשר לשרת. אלא לכל הודעה לשרת צריך לשלוח XHR משלו. אבל? SSE מכסה את הרוב המקרים של שימוש ב־Comet!

המימוש? קיים ב־Firefox,‏ Opera‏, Chrome‏, Safari ואמור להיכנס ל־IE10

אז איך זה עובד

בואו נדגים אפליקציה שמציגה את מחיר המניה העדכני ביותר בדפדפן:

בצד הלקוח, אנחנו נכתוב את הקוד הפשוט הבא:

function read_data() {
    var stream = new EventSource('/ticker/get');
    stream.onmessage = function(e){
        document.getElementById('price').innerHTML=e.data;
    };

    stream.onerror = function(e){
        console.log(e);
    };
}

read_data();

אנחנו פותחים EventSource ועל כל אירוע שמכיל מידע אנחנו מעדכנים שדה html עם המחיר העדכני ביותר.

בצד השרת הנושא שקצת יותר מורכב כי אנחנו צריכים לנהל מספר קשרים:

כשנכנס קשר חדש, אנחנו מכינים אותו - מגדירים את ה-Content-Type כ־text/event-stream, מבטלים caching בדרך.

לוקחים את ה־id של הערך הידוע האחרון, זה יאפשר לנו לדעת אם הלקוח התנתק אז אם הוא יודע את המחיר העדכני ביותר או לא. אם הערך שונה מהערך הנוכחי, אנחנו שולחים עדכון, אחרת מכניסית אותו ל"רשימת המתנה" - כל הלקוחות הממתינים לעדכון.

void main(std::string /*url*/)
{
    response().set_content_header("text/event-stream");
    response().set_header("Cache-Control", "no-cache");

    auto last_id = atoi(request().cgetenv("HTTP_LAST_EVENT_ID"));

    auto context=release_context();

    if(last_id != counter_) {
        async_send(context);
    }
    else
        waiters_.insert(context);
}

כיצד אנחנו שולחים עדכונים:

התוכן מורכב מה־id - של המחיר - מנגנון הסנכרון שלנו והתוכן - המחיר עצמו.

void async_send(booster::shared_ptr<cppcms::http::context> waiter)
{
    waiter->response().out() <<
        "id:" <<  counter_ <<"\n"
        "data:" << price_ << "\n"
        "\n";

אחר כך אנחנו מגדירים completion-handler שיבדוק אם פעולה הצליח (אם לא אז קשר נסגר אין מה לעשות) ואם כן, ואין עדכונים נוספים ומכניסים אותו לרשימת ההמתנה.

    waiter->async_flush_output([=,counter_](cppcms::http::context::completion_type status){
        if(status!=0)
            return;
        if(counter_ != this->counter_) {
            this->async_send(waiter);
        }
        else {
            this->waiters_.insert(waiter);
        }
    });

}

עכשיו נכתוב פונקציה קטנה שמאפשרת לנו לעדכן את אלו שממתינים למחיר חדש:

void update_price(double new_one)
{
    counter_++;
    price_ = new_one;
    for(auto waiter : waiters_) {
        async_send(waiter);
    }
    waiters_.clear();
}

נעדכן מונה כדי לסמן מחיר חדש, נעבור על הרשימה ונשלח מחיר מעודכן לכולם. מנגנון פשוט שניתן לממש עם כלים פשוטים (במידה והתשתית שלך תומכת ב־Comet).

ניתן למצוא כאן את הקוד המלא.

חיבור לשרת

כדי שהמנגנון הזה יעבוד צריך לוודא ששרת ה־Web ישלח את התוכן באופן מידי ולא ישמור אותו בזיכרון (בציפייה שעוד מידע יגיע).

  • Lighttpd עושה את זה בלי בעיה ב־FastCGI,‏ SCGI ו־HTTP כברירת מחדל.
  • Apache עושה את זה כברירת מחדל ב־SCGI ו־HTTP אבל ב־FastCGI דרושה אופציה ‎-flush ואז הכל תקין.

לעומת זאת, "Nginx המהולל" עושה בעיות. בפרוטוקולים SCGI ו־HTTP ניתן לבטל buffering עם אופציה http_buffering off או scgi_buffering off אבל ב־FastCGI, שהוא הפרוטוקול הכי נפוץ בעבודה עם שרת Web אופציה כזו לא קיימת! כרגיל, Nginx מפתיע... (או שלא).

אז כרגיל, עוד סיבה טובה לא להשתמש ב־Nginx. אז אני אחזור את הטענה שלי: Nginx, תודה לא, Lighttpd‏.

הוסף תגובה:

 
 כתובת דוא"ל לא תוצג
 

ניתן לכתוב תגובות עם שימוש בתחביר Markdown.

חובה לאפשר JavaScript כדי להגיב.

דפים

נושאים