מאמרים בנושא ‏אינטרנט‏.

גם Tatoeba תשתמש ב־CppCMS

ב־יום שני, 13 ביוני 2011, מאת ארתיום; פורסם תחת: תכנה חופשית, אינטרנט, פיתוח, תכנה ומחשבים, CppCMS, C++‎‏, Unicode; ‏7 תגובות

טטואבה, פרויקט בינלאומי המהווה מעין מילון האוסף מספר רב של משפטים, מפתח גרסה חדשה ב־C++‎ שמבוססת על CppCMS.

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

גרסת האלפה (עדיין מאוד בסיסית) כבר עלתה לרשת וזמינה בכתובת:‏ http://tato.sysko.fr. הגרסה הזו מחליפה את מנוע החיפוש הנוכחי העובד עם MySQL בבסיס נתונים ייחודי שהם פיתחו ותשתית הרשת שכתובה בעזרת CakePHP מתחלפת באחרת המבוססת על CppCMS.

בהודעה הזו הם מסבירים את ההחלטה שלהם לבחור ב־CppCMS. להחלטה הזו היה מספר לא מבוטל של סיבות.

בקיצור... תתחילו לקחת את CppCMS בצורה רצינית :-)

CppCMS אי שם בענן

ב־יום ראשון, 12 ביוני 2011, מאת ארתיום; פורסם תחת: תכנה חופשית, אינטרנט, פיתוח, תכנה ומחשבים, CppCMS; ‏3 תגובות

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

על־אף של־CppCMS יש רשימת תפוצה פעילה וידוע לי על לפחות מספר חברות שמשתמשות ב־CppCMS במוצרי embedded שלהם, עדיין רוב המשתמשים לא ממהרים לפרסם את עצמם כמשתמשים גאים של שהתשתית המיוחדת הזו.

היום בחיפוש פשוט בגוגל על "x-powered-by: cppcms" גיליתי את חברת הזנק הבאה: http://dhiti.com.

הופתעתי לגלות שהיא מפעילה מספר "שירותים בענן" המשתמשים ב־CppCMS, ביניהם: ‏http://dive.dhiti.com,‏ http://drilll.com,‏ http://intweetion.com.

אלה למעשה שירותים שמבוססים על RESTful API‏ שצד הלקוח (הדפדפן) מתקשר אתם.

אחרי שהסתכלתי באתר החברה, נזכרתי שפעם קיבלתי מהם דיווח באג ותיקנתי אותו. אבל לאחר מכן, לא ממש עקבתי אחרי ההתפתחות שלהם... עד היום כשגיליתי שירותים X-Powered-By: CppCMS.


אני שמח סוף־סוף לראות CppCMS במקום שלו הוא מיועד. אני מאוד מקווה שהפעם יתאפשר לי לספר על הפרויקט הזה באוגוסט פינגווין הקרוב.

שוחררה גרסת 0.0.5 של CppCMS (ענף יציב)

ב־יום שני, 11 בינואר 2010, מאת ארתיום; פורסם תחת: תכנה חופשית, אינטרנט, לינוקס, פיתוח, תכנה ומחשבים, CppCMS, C++‎‏; ‏2 תגובות

שוחררה גרסה חדשה של ענף יציב של CppCMS, שינויים:

תיקוני בעיות אבטחה:

  • נכתב מעקף לבעיה של ספריית CgiCC שהיה יכול לגרום ל־DoS.
  • תוקנה בעיה שהייתה עלולה לגרום להווצרות SID בעלי אנטרופיה נמוכה.

תיקוני באגים:

  • תוקן זמן חיים של ערכים "חשופים" בניהול מצב (sessions)
  • תוקן באג שמנע אפשרות עבודה ב־FastCGI/SCGI מעל TCP/IP
  • תוקנו בעיות בניה עם גרסאות Boost לא סטנדרטיות.
  • תוקנו בעיות ביצירת HTTP Status Headers לא נכונים במקרה של שגיאות.
  • תוקנו בעיות בניה עם גרסאות gcc שונות ועם קומפיילר של אינטל.

שיפורים:

  • שופרו זמני בעיות views בצורה משמעות.

נפלאות ה־Comet בשרתי האינטרנט המודרניים...

ב־יום שישי, 28 באוגוסט 2009, מאת ארתיום; פורסם תחת: תכנה חופשית, אינטרנט, לינוקס, תכנה ומחשבים, CppCMS; ‏2 תגובות

כפי שפרסמתי לאחרונה, אני עובד על תמיכה ב־Comet או HTTP Push ב־CppCMS. כאשר הכוונה לאפשרות שרת האינטרנט ליידע את הלקוח על אירוע חדש, למשל: "הגיעה מסר מידי חדש, או מחיר המניה השתנה" -- למעשה להעביר אירועים ללקוח בזמן אמת.

כיצד התהליך מתבצע? הלקוח פונה לשרת עם בקשת HTTP לקבל עדכונים; והשרת, במקום לענות באופן מידי ממתין ומחזיק את הקשר פתוח. כאשר מגיע האירוע החדש, כמו עדכון מחיר המניה או הודעה חדש מחבר, התשובה נשלחת והתליך חוזר.

לא מי יודע מה מסובך כמובן זה גם תלוי ביכולת השרת להחזיק קשר HTTP פתוח למשך הרבה זמן.

אבל, מה קורה אם הלקוח סוגר את הקשר לפני שהוא מקבל תשובה? בבקשות HTTP רגילות זה אירוע נדיר והיישום בצד השרת יכול בקלות "להתעלם" ממצב כזה. ביישומי Comet זה שונה: מספיק שמישהו נכנס לאתר שמחכה לדף שמבצע בקשה מסוג זה ויוצא ממנו, הקשר לקבלת עדכונים ייסגר.

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

אבל מה? יישום ה־Comet בד"כ לא מדבר ישירות עם הלקוח בעזרת HTTP אלא מדבר עם שרת web בעזרת פרוטוקול סטנדרטי כמו FastCGI או SCGI. לכן, תפקידו של השרת הוא לדווח ליישום על כך שהלקוח סגר את הקשר. למעשה פרוטוקול FastCGI מגדיר במפורש דרך להפסיק בקשה מסויימת ע"י סגירת ה־socket או שליחת בקשה מיוחדת "Abord Request", כנ"ל ניתן לבצע בעזרת scgi ע"י ניתוק ה־socket.

פשוט? כן. האם זה קורה בפועל? לא ממש.

אחרי שמימשתי מערכת ניתוק הקשר ובדקתי אותה על שרת http פנימי, החלטתי לבדוק את ההתנהגות של שרתי web אמתיים: Lighttpd,‏ Nginx ו־Apache2. מה שגיליתי היה ממש לא נעים: למעט Nginx אף שרת לא מדווח על ניתוק הקשר לא מעל FastCGI ולא מעל SCGI.

לצורך דוגמה פשוטה, אני יצרתי חיבור ומיד סגרתי אותו, כך עשיתי עשר פעם.

  • Nginx הוא היחיד דיווח על כך ליישום FastCGI באופן מידי ואפשר לי לטפל בלקוח ש"נעלם"
  • Apache דיווח רק אחרי timeout ארוך של כדקה הן ב־FastCGI והן ב־SCGI.‏
  • lighttpd בכלל שכח מזה והחזיק קשרים פתוחים כל הזמן -- יותר מזה בירידה, הוא התלונן על כך שהיישום שלי "נעלם" ולא ענה לבקשת השרת (שאין לו כבר למי להעביר אותה).

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

מזל שמימשתי שרת HTTP פנימי בעצמי.

CppCMS פוגש Comet

ב־יום חמישי, 27 באוגוסט 2009, מאת ארתיום; פורסם תחת: תכנה חופשית, אינטרנט, פיתוח, תכנה ומחשבים, CppCMS, C++‎‏; ‏0 תגובות

פרסמתי כאן כתבה על טכנולוגיית Comet (או Server Push) הנתמכת בגרסה הבאה של CppCMS.

הצגתי כדוגמה קלאסית: מימוש של יישום Chat, בצד הלקוח ובצד השרת, בכ־50 שורות קוד בכל אחד מהם, עם שימוש ב־XHR Long Polling.

העמוד הבא

העמוד הבא

דפים

נושאים