הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
מאמרים בנושא תכנה ומחשבים.
צעד חשוב קדימה — ביזור של CppCMS.
למרות ש־CppCMS מצטיינת בביצועים גבוהים במיוחד, עדיין מגיע הרגע, בו צריך לבצע ביזור המערכת לצורך שיפור ביצועים. המערכת נבנתה מלכתחילה במחשבה שהיא תצטרך לרוץ על מספר מחשבים נפרדים, אבל היה חסר רכיב משמעותי אחרון --- מערכת Cache מבוזרת.
עד היום CppCMS באה עם שתי אופציות של Cache --- משותף לחוטים של אותו תהליך (threaded) ומשותף לתהליכים שנוצרו ע"י מנגנון prefork (fork cache). לא היה ניתן לשתף Cache בין שני מחשבים שונים. לא הייתה בעיה עיקרונית להוסיף אותו, למעט העדר זמן הפיתוח.
ההכרות שלי עם ספריית Boost.Asio פישטה את התהליכים בצורה משמעותית ואפשרה לי לממש את המודול החדש במהירות.
למעשה, המודול החדש מאוד דומה בתפקידו ל־memcached למעט שיפור קטן ומשמעותי: תמיכה ב־triggerים או אפשרות לנקות ערכים מסוימים לפי הדרישה.
כדי להקל על ביזור, כל לקוח יכול להתחבר למספר שרתים ואז, כל ערך מתמפה לאחד מהשרתים בעזרת פונקציית hash פשוטה, כך שבפועל ה־cache יכול להיות מבוזר בין 10 שרתים באופן אחיד ולהגדיל את הקיבולת שלו/להקטין עומס על שרתים בודדים.
כדי להבטיח עקביות של ה־cache, פעולות כמו הפעלת trigger שמוחק ערכים בקבוצות, נשלחות לכל השרתים ביחד. כל שאר הפעולות עובדות מול שרת יחיד לפי המפתח. לכן, מבחינת המשתמש, יש שקיפות מלאה, אם הוא עובד עם שרת בודד או עם 10.
המודול מופעל ע"י שורת קונפיגורציה cache.backend="tcp" ושני פרמטרים נוספים cache.ports ו־cache.ips המגדירים את רשימת הפורטים וכתובות ה־IP עליהם מאזינים שרתי ה־cache המבוזרים.
פיתוח יישומי רשת ב־C++ או הצצה ל־Boost.Asio.
במאמר זה, אביא סקירה קצרה של ספריית Boost.Asio -- ספרייה לפיתוח יישומי תקשורת ב־C++ בצורה מהירה, יעילה ונוחה. ההכרות שלי איתה התחילה, דווקא מצורכי העבודה. אחרי זמן קצת, הבנתי שהיא מאוד נוחה ואפילו תהיה שימושית עבור CppCMS. למעשה, הספרייה הזו, אפשרה לי לעטוף את ספריית ה־cache של CppCMS ולהפוך אותה למבוזרת --- לבנות פתרון בסגנון memcached --- תוך מספר שעות בלבד.
הספרייה הזו קיימת בשתי גרסאות:
- גרסת Boost.Asio: היא חלק מ־Boost החל מגרסתו 1.35.
- גרסת Asio עצמאית, שדורשת Boost גרסה 1.33 ומעלה --- מאפשרת לעשות שדרוג של ספרייה ללא תלות בגרסת Boost.
אחד המאפיינים המעניינים שלה היא העובדה, שהספרייה כולה כתובה על בסיס Template Metaprogramming ומהווה אוסף קובצי־".hpp" בלבד.
"בעיית עשרת אלפים קשרים" או "למה צריך ספריות כאלה בכלל?"
מעבר לעובדה ש־Berkeley Sockets API די מסובך, עדין ושונה במערכות הפעלה שונות --- כבר סיבה מספיק טובה לבנות מעטפת עבורו --- אני אתרכז דווקא במשהו אחר, כתיבת יישומים יעילים.
נתחיל מסיפור קצר. נגיד אתם רוצים לפתח שרת מסרים מידיים שמטפל במספר רב של הלקוחות בו זמנית. בסה"כ השרת מבצע תפקיד מאוד פשוט: קבל הודעה מלקוח מסוים, להעביר ללקוח אחר.
יש מספר גישות לבניית השרת:
המשך...מתיאוריה למציאות, או עד כמה UTF-16 באמת בעייתי
בהמשך לפוסט הקודם, החלטתי לעשות סקירה קצרה: "האם באמת תכנות שכתובות עם utf-16 לא עובדות כמו שצריך עם קידודים כפולים ומה קורה עם תכנות שמשתמשות בייצוג פנימי ב־utf-8/utf-32?"
לקחתי תו "𠂊" או U+2008A וניסיתי להציג אותו ביישומים שונים מבוססים על toolkitים שונים. התו הזה מתייחס ל־CJK Unified Ideographs Extension B ולא לא יכול להיות מיוצג ב־utf-16 בעזרת איבר אחד (שני בתים) אלא דורש צירוף של שני איברים (ארבעה בתים). אם אתם לא רואים את התו הזה, או רואים אותו כריבוע בדפדפן שלכם, אפשר להתקין גופן חופשי: AR PL ShanHeiSun Uni, בעלי דביאן יכולים להתקין חבילה ttf-arphic-uming. חייב לציין, אין מי מושג מה התו או המילה האלה אומרים, כך שמתנצל מראש.
קודם כל: היישומים שעובדים עם utf-16 שהתמודדו אתו בצורה יפה ונכונה (או פשוט לא מצאתי באגים ב־2 דקות ששיחקתי איתם) הם:
- OpenOffice שעובד עם icu (אם כי, אני לא בטוח שהוא משתמש בו בייצוג פנימי)
- Microsoft Word עבד ללא בעיות ועובד עם Windows API המבוסס על utf16.
- FreeMind שכתוב ב־Java הצליח להציג את התו ולערוך טקסט בצורה מסודרת. (Java משתמשת ב־utf-16 במחרוזות שלה).
אבל פה פחות או יותר נגמרו היישומים שעובדים עם utf-16 וגם מסתדרים עם התו הבעייתי. נתחיל:
המשך...UTF-8, UTF-16, Unicode וכל מה שביניהם.
היו היה בית, בתקופה של תחילת עידן המחשבים הוא היה מסוגל לשמור תו בודד. אבל אנושות הלכה והתפתח ויום אחד התברר שהוא לא מספיק. יש צרפתים, יש רוסים, יש סינים ולא ניתן לדחוף את הכל התווים הידועים לבית אחד מסכן. אז התאספו אנשים חכמים ובסוף שנות ה־80 --- תחילת 90 החליטו לבנות תקן אחיד שיכסה את כל השפות האפשריות --- Unicode.
האנשים האלה חשבו וחישבו ששני בתים יספיקו לכסות את כל השפות אפשריות. כך נולד קידוד של Unicode בשני בתים. בתחילת ה־90, יצרתי UNIX הגדולים גם חשבו ובנו UTF-8 שכדי להבטיח תאימות לאחור עם כל התכנה הקיימת --- כך נולד קידוד בעל אורך משתנה.
עבר הזמן, יצרני תכנה שונים הולכו בשני כיוונים: אחד להציג כל תו בשני בתים והשני להמשיך להשתמש ב־ANSI C String ולעבוד עם תווים בעלי ייצוג באורך שונה. אבל, באמצע שנות ה־90 כבר היה ברור ששני בתים לא יספיקו כדי לכסות את כל השפות האפשריות. ולכן התקן הורחב כך שהוא כלל ערכים מ־0 ועד ל־0x10FFFF.
המשך...מה השתנה בדפדפן הזה, או הניצוץ של כרום.
לא, אני לא הולך לכתוב עוד אחת מאלף ואחת סקירות מתלהבות (או לא כל־כך) על Google Chrome. בסה"כ הגיע עוד דפדפן מעשרות הקיימים: IE, Maxton, Firefox, Galeon, Epiphany, Konqueror, Safari, Flock, Camino, Opera ועוד. אז יש לנו עוד דפדפן, מה הסיפור שלו? היום, לבנות דפדפן זה משהו יחסית פשוט. קח מחלקה של KHTML, Gecko, או של WebKit, דחוף אותה למעטפת GUI ויש לך דפדפן. עכשיו נשאר להמציא עוד כמה עשרות כפתורים מוזרים, להוסיף כמה פיצ'רים נחמדים ולשווק.
לכן, כפי שאתם יכולים להבין אני לא הולך לדבר על דפדפן עצמו. הוא לא מעניין אותי בתור דפדפן יותר מאשר רוב הדפדפנים שפירטתי לעיל. מה שמעניין אותי באמת, זה הצירוף של WebKit עם המותג Google.
המשך...