קטגוריה: תקשורת

מציאת רשומה לפי התחלה מדוייקת ב PostgreSQL

הנה בעיה מעניינת – כיצד אני מביא רשומה המתאימה ביותר להתחלה כלשהי, כאשר ההתחלה משתנה באורך/תווים שלה?

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

כאשר אני יודע כי 2 תווים ראשונים מחזיקים תמיד בקידומת הבעיה מאוד פשוטה – אני חותך 2 תווים ראשונים ומחפש עליהם קידומות בצורה חד חד ערכית, ואם מדובר ב unique index חיפוש מהיר ביותר שאולי יעשה sequence scan במקום חיפוש באינדקס ויהיה מהיר מאוד.

אבל כאשר חלק מהקידומות הן בעלות 2 תווים, חלק אחר בעלות 3 תווים ואפילו ישנן קידומות בעלות 4 או 6 תווים כאשר התו האחרון הוא זה שמבדיל בין ספקיות שונות יש בעיה.
הרי אין לי ידע מקדים מה הקידומת ומה הוא המספר עצמו.

למזלי יש כלים מאוד חזקים המסייעים בזה עם מסד נתונים PostgreSQL או PG בקיצור.

הדגמה של טבלת קידומות:

להמשיך לקרוא

ממשקי משתמש – יצירתיות מול שימושיות

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

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

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

כלומר ממשקי המשתמש עבור סיוע לאנשים הסובלים מכאבי שרירים כרוניים אינם מתאימים אותם האנשים.

נלקחת מ: https://commons.wikimedia.org/wiki/File:Mission_Accomplished_-ALS_Ice_Bucket_Challenge(14848289439).jpg

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

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

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

זה התחיל בערך בעשור האחרון – יותר ויותר חברות הולכות לאנשים שהמקצוע שלהם – "חווית משתמש" ו/או "תכנון ממשקים", ונראה כי מאז שזה מתרחש – לי קשה מאוד להתמודד עם הרבה מאוד תכנים. שמתי לב כי ככול שהממשק נקי יותר וממוקד יותר במה שאני צריך ממנו – ככה קל לי יותר לעבוד איתו, בעוד שככול שהוא עשיר יותר בצבעים וכו' קשה לי להתמודד איתו.

ככה גם אני מנסה ליצור ממשקים למערכות שאני יוצר – נקי וממוקד מאוד עם מינימום צבעים ו"גרפיקה", רק מה שנדרש לביצוע הפעולה וכמה שיותר ממוקד.

אני חושב כי אנשי ux/ui חייבים ללכת ולעשות שיעורי בית מול דבר ראשון אלו שצריכים להשתמש במערכת ולהתחיל להקשיב לאנשים עם בעיות שונות, ורק אז לחשוב איך לעצב את זה בצורה "סקסית" ו"מושכת", אחרת הניתוח הצליח, אבל החולה מת.

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

עלייתן ונפילתן של רשתות חברתיות – דעה

ב2007 קיבלתי הזמנה לקחת חלק מאנשים מובחרים באמת ברשת חברתית חדשה ואנונימית בשם פייסבוק.

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

במהלך השנים עזרתי לנהל דף פייסבוק מאוד נפוץ שהגיע ליותר מ50,000 עוקבים, שהיו מפולחים מאוד, וקיבלו פרסומות (מתוך פייסבוק) לעסקים שהם באמת רצו להחשף אליהם, עד שיום אחד פייסבוק משום מקום או התראה החליטה לסגור את הדף, להשעות לכלל המנהלים את החשבון ו… הייתי צריך להוכיח שאני לא בוט.

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

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

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

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

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

בעל האתר כרגע מתמודד לראשות עיריית לונדון, אולי במטרה לשנות את המקצוע בעקבות הנושא.

להמשיך לקרוא

צעדים ראשונים ב wireguard

נדרשתי למערכת אשר צריכה לעבוד מאחורי NAT.
עם NAT יש מספר בעיות, אשר אחת מהן היא כיצד אני מקבל דברים פנימה, ולא רק כיצד אני ממפה את הפנים כלפי חוץ.

כלומר נגיד ואני רוצה לגשת ל 10.0.0.12 ב HTTP כאשר אני נמצא באינטרנט, והשרת נמצא מאחורי 10.0.0.12, אין לי סיכוי ללא יכולת לעשות Port forwarding, הנגשת השרת כלפי חוץ או reverse proxy כלשהו.

אותו הדבר הפוך. יש לי הרבה מחשבים שצריכים לקבל פנימה תקשורת מבחוץ כשהם לא יזמו את הפניה, מה שאומר שאין session פתוח, ואין דרך ככה סתם להתומדד עם הבעיה הזו בתקשורת ללא כלים נוספים.

כאשר יש אפשרות לשלוט ברשת, ניתן להוסיף כלים שונים, אבל מה קורה כאשר אין לך יכולת לשלוט ברשת הפנימית, אבל עדיין צריך להיכנס פנימה? ובכן, משתמשים ב VPN ויוצרים רגל חדשה בין 2 קצוות (או יותר).

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

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

הרעיון של Wireguard הוא שכל חיבור בין אם "שרת" ובין אם "לקוח" הוא בעצם Peer.
כאשר אני רוצה לתהחבר ל"שרת", אני אשים את הכתובת להתחבר אליו, ובמידה ואני רוצה למצוא שכנים אני אגדיר אותם במפורש בקובץ ההגדרות עבור אותו Peer.

ברגע שהבנתי את העיקרון הזה, ולי לקח זמן להבין את הרעיון הזה, למעשה הבנתי לגמרי כיצד Wireguard מוגדר ועובד.

ישנם מדריכים מדהימים ברשת, כולל באתר, הרשמי, כך שלא אכנס להגדרות כאן.

שמתי לב כי הוא מתפקד הרבה יותר טוב במרבית האנדרואידים, ויש לו תמיכה ב QR Code בשביל לטעון קובץ הגדרות מאוד פשוט. דבר שמקל מאוד מאשר להזין את הנתונים ידנית.
כמו כן, מצאתי כי קשה לייבא את הקובץ בצורה פשוטה במכשירי האנדרואיד שהיו ברשותי, ולכן זה היה הפתרון הקל ביותר.

אחד הדברים המדהימים באמת של Wireguard זו הפשטות ליצור תעודות הצפנה.
פקודה קטנה ליצור מפתח פרטי ופקודה נוספת לקחת את המפתח הזה וליצור מפתח ציבורי.
בקובץ של המכשיר שמים את המפתח הפרטי, ובהגדרות של כל מי שצריך לדבר איתו שמים את המפתח הציבורי.
המפתחות שמורים כשורת base64 ואין התעסקות עם המון כלים כדוגמת easy-rsa של openvpn, ואין צורך להתעסק עם openssl.
קובץ ההגדרות יראה בצורה הזו ב"לקוח":

[Interface]
PrivateKey = 
Address = 10.1.0.2/24

[Peer]
PublicKey = 
PersistentKeepalive = 20
Endpoint = address:port
AllowedIPs = 0.0.0.0/0, ::/0

[Peer]
PublicKey = 
AllowedIPs = 10.1.0.3/32

[Peer]
PublicKey = 
AllowedIPs = 10.1.0.2/32

 

היצירה של ה QR התבצעה על ידי באמצעות לינוקס עם הפקודה qrencode בצורה הזו:

qrencode -t PNG -o qr_conf_for_phone.png --verbose < wg_conf_for_phone.conf

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

בשורה התחתונה, אני מאוד מרוצה מה vpn שלא רק קל להגדרה אלא נראה יציב יותר.

אופטימיזצית פרוייקט בזמן קורונה

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

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

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

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

התחלתי למדוד מה המקומות שלוקחים הכי הרבה זמן וגיליתי כי משהו שהוא מחוץ לשליטתי הוא הגורם לכך.

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

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

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

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

יצרתי סוג של טיימר הסופר עד כמות מסויימת של מילי שניות ובמידה והגיע אותו timeout לפני שהתוצר הסתיים, הייתי מדווח שגיאה חזרה.
במידה והסתיים, המידע המתאים נשלח כי הוא התקבל חזרה, ובטיימר לא היה באמת sleep כלשהו אלא תפיסה של "אירועים" על ידי שיחרור מיוטקסים או לחכות לmutex מסוים להשתחרר. הידע מתי לשחרר אותו התבצע על ידי שמירת ה payload שמגיע בstreaming pipe עד אשר תו מסויים מגיע, או אורך מסוים הגיע (הראשון מבניהם). במידה ועד שזה מתבצע הגיע הזמן לשחרר, אז mutex אחר שספר ticks פעל כאשר הבדיקה היתה על אחד משניהם.

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

לאחר השינוי הזה, המערכת התחילה לחזור אלי לרוב אחרי 10-200 מילי שניות, כאשר 500 מילי שניות היו לתוכן גדול בהרבה ממה שאותו משרד ממשלתי שולח אלי.

גרמתי למערכת לרדת לפעמים לפחות מ10 מילי שניות כאשר מקודם לכן הממוצע הנמוך עמד על 500 מילי שניות והגבוה על 700 מילי שניות.

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

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

היה שלום פרל, ותודה על הסימנים

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

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

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

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

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

על הדרך גיליתי שורות קוד שהזכירו לי גם מה לא אהבתי בפרל (אם כי במכלול הגדול של הדברים, אני מת על השפה). למשל 4 שורות קוד שלקח לי שעה להבין מה הן עושות (ואני כתבתי אותן) כי הן השתמשו במשתנים כדוגמת ‎$_‎ אשר מייצג למשל תוכן של scope ולא תמיד ברור של מה התוכן. בנוסף גם עוד מספר משתנים בסגנון.

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

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

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

זה סוג של סיום תקופה כזו. אז היה שלום ותודה על סמלים

לצטט ברשת

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

ממשק ציטוטים

מספר אנשים שגם הם חובבי ציטוטים תמיד מקבלים ממני קישור לאוסף עצמו שנמצא בקובץ טקסט במבנה מאוד מוגדר:

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

כל שורה (למעט קישור ווב) לא תעבור את עמודה 80, ותהיה ירידת שורה במידה וכן.

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

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

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

כל הקוד נמצא (נכון לכתיבת הפוסט) בקובץ javascript בודד, שכתוב ב es6 והוא קורא את הקובץ באמצעות fetch ומפרסר את הציטוטים.
לאחר הריצה הראשונית, כל הצגה של ציטוט חדש, מתבצע מתוך הזיכרון ולא מטעינה חדשה של המסך.

כל זה ללא שימוש בשום framework או ספרייה כלשהי, אלא נטו קוד שלי.

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

תהנו 🙂

גילוי פורטים פתוחים בצורה נאיבית

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

אני מדבר כרגע על TCP. ובשביל להבין כמה זה לא מסובך, צריך להבין כיצד בקשת TCP עובדת בעצם.

ישנם מספר פעולות אשר נמצאות ברמה נמוכה יותר (בתוך מימוש TCP), אשר מבצעות עבורינו לחיצת יד. פעולות אלו מסוגלות לעשות זאת רק כאשר יש תשובה בצד השני, ומקבלים ack.
אם לא מקבלים אישור, יכולים להיות שני גורמים:

  1. התעבורה עברה, אבל לא קיבלנו אישור – הפורט פתוח אבל מפולטר (מלווה ב Connection Refused).
  2. אין פורט פתוח – אולי מפולטר, ואם כן מקבל drop כאילו אין פורט פתוח.

פעולה זו של SYNchronize היא הדרך עבורינו לגלות האם TCP פתוח.

ההצעה הפשוטה ביותר להתמודד עם זה, זה לנסות לפתוח חיבור TCP בפורט המבוקש לכתובת, במידה ונפתח, החיבור פתוח. במידה והחיבור נכשל (אם קיבלנו timeout או connection refused), אנחנו יודעים שהוא לא פתוח. כאשר האחרון אומר כי הוא מפולטר.

זו לא הדרך היחידה לעשות את זה, אבל זו הדרך הפשוטה ביותר.

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

רובי:

#!/usr/bin/env ruby
require 'socket'
def tcp_connect(address, port, timeout: 20)
# making sure we are talking with IP
connected = false
addr = Socket.getaddrinfo(address, nil)
sock_addr = Socket.pack_sockaddr_in(port, addr[0][3])
Socket.new(Socket.const_get(addr[0][0]), Socket::SOCK_STREAM, 0).tap do |socket|
begin
socket.connect_nonblock(sock_addr)
rescue IO::WaitWritable
if IO.select(nil, [socket], nil, timeout)
begin
# try again, might work
socket.connect_nonblock(sock_addr)
connected = :connected # no other exception, then should be yes
rescue Errno::EISCONN # we have a connection
connected = :connected
rescue Errno::ECONNREFUSED # we are filtered
connected = :filtered
rescue Errno::ETIMEDOUT # timeout
connected = :closed
rescue StandardError # something else :'(
connected = :error
end
else # unable to wait for an answer, but no exception was raised
connected = :error
end
rescue StandardError # ops, something went wrong
connected = false
ensure
socket.close
end
end
connected
end
puts tcp_connect('192.168.97.3', 8823)
view raw scan.rb hosted with ❤ by GitHub

גו:

package main
import (
"fmt"
"net"
"strings"
"time"
)
const (
errUnknown = "Unknown error"
connTimeout = "closed"
connFiltered = "filtered"
resolveError = "Resolve error"
lookupError = "Lookup error"
connSuccess = "open"
)
func tcpConnect(address string, port int, timeout time.Duration) (string, error) {
ipList, err := net.LookupHost(address)
if err != nil {
return lookupError, err
}
if len(ipList) == 0 {
return resolveError, fmt.Errorf("Unable to resolve %s", address)
}
connAddr := fmt.Sprintf("%s:%d", ipList[0], port)
conn, err := net.DialTimeout("tcp", connAddr, timeout)
if err != nil {
sErr := err.Error()
if strings.HasSuffix(sErr, "connection refused") {
return connFiltered, err
}
if strings.HasSuffix(sErr, "i/o timeout") {
return connTimeout, err
}
return errUnknown, err
}
defer conn.Close()
return connSuccess, nil
}
func main() {
addr := "google.com"
port := 443
status, err := tcpConnect(addr, port, time.Duration(3)*time.Second)
fmt.Printf("%s:%d - ", addr, port)
if status == errUnknown {
fmt.Println(err)
} else {
fmt.Println(status)
}
}
view raw scan.go hosted with ❤ by GitHub

מחשבות על Github ומיקרוסופט

לפני כשבוע נפלה פצצה בעולם התוכנה בעולם – מיקרוסופט רוכשת את Github. זה הגיע לאחר גל שמועות, למרות שהרכישה עצמה לא התבצעה עדיין (הרכישה מיועדת לסוף 2018), אך ההכרזה הגיעה בגלל עודף שמועות, וספקולציות אף פעם לא טובות לשוק.

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

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

  1. מלחמה טובה לעסקים.
  2. שלום טוב לעסקים

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

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

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

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

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

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

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

אתם מבינים? כיום מיקרוסופט אוהבת קוד פתוח, כי היא הבינה איך עושים דרכו כסף, אבל מחר? מחר הוא יכול להיות חזרה אויב אכזר לחברה, ומה אז?

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

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

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

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

מתכנת IT

הרבה שנים שאני מנסה להסביר לאנשים מה המקצוע שלי. אני מנסה להסביר כי המקצוע שלי הוא "מתכנת IT", אבל אנשים חושבים כי אני מדבר על DevOps.
התשובה היא לא, זה לא DevOps.

תנו לי רגע להסביר מה זה בעצם IT, שכולם אוהבים להתייחס אליו.
IT הם ראשי תיבות של Information Technology. כלומר מי שמוגדר כאיש IT, מתעסק בטכנולוגיות העוסקות במידע.

עכשיו אשאל אתכם שאלה: האם איש DBA שייך לקבוצה הזו? התשובה היא כן. האם הוא איש DevOps? התשובה היא לא.

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

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

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

איש DBA יודע למשל המון על IO ועל דיסקים, וזיכרון, אבל זה לא אומר שהוא יודע מספיק בשביל להחליף ציוד, או לבחור חומרה בצורה נכונה. הוא רק יודע מה מסוגל לתת ביצועים טובים, אבל האם לוח מסוים עדיף? האם שרת מסוג מסוים? האם בקר מסוים? האם מעבד מדגם אחד טוב יותר וכיוב', הם פחות מהמומחיות שלו. זה לא אומר שהוא אינו יודע, זה אומר שהוא פחות חי את זה. זה יותר סוג של by-product של העבודה, מאשר המומחיות.

להמשיך לקרוא

מימוש RDP טבעי בשפת רובי

על רגל אחת, RDP הם ראשי תיבות של Remote Desktop Protocol. אך השם מעט מטעה. זוהי למעשה אסופה של הרבה מאוד פרוטוקולים, חלקם אפילו לא של מיקרוסופט, אלא של ארגון ITU. למעשה הוא מבוסס על סדרה של פרוטוקולים שהחלו את דרכם בארגון ה ITU אשר נועדו לאפשר לתוכנות לשתף מידע ותכנים בניהם.

הפרוטוקולים עצמם הם פרוטוקולים בינאריים, ולא פרוטוקולים טקסטואליים (כדוגמת HTTP למשל), וככאלו יש עבודה רבה עם bit manipulation והבנה של מיקומים שונים ומה המשמעות שלהם.
הרעיון של RDP הוא להצליח להעביר את כל סביבת המיקרוסופט למחשב מרוחק, כולל העתקת קבצים, שיתוף מדפסות, שיתוף כוננים, שיתוף קול ואפילו לבצע הזרמה של ווידאו.

כל זה נעשה תחת מערכת שמבצעת הזדהות מול מערכת כדוגמת Active Directory בפרוטוקולים כדוגמת NTLM ו spnego, אשר האחרון, הוא מימוש הזדהות התומך גם בקרברוס למשל, כאשר התעבורה אמורה להיות מוצפנת בגישות שונות, בהתאם לתמיכה של שני הצדדים. על כל זה מופעל סוג של compression למידע.

לאחרונה התחלתי בשיתוף עם בר חופש ליצור מימוש טבעי בשפת רובי עבור פרוטוקולי RDP של מיקרוסופט.
המימוש שלנו משוחרר בקוד פתוח (רישיון MIT), והוא נועד לספק שרת, וגם לקוח טבעיים במערכות הפעלה כדוגמת לינוקס ובכלל שליטה מלאה בכל מה שעובר בפרוטוקול, כולל האפשרות להגדיר מה אפשרי ומה לא בצורה תכנותית.

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

כתובת הפרויקט: https://github.com/Safe-T/rdp-rb

סיכום שנה – 2015

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

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

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

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

הגעתי למשל למצב שבו אני יושב עם אנשי מתג של חברת תקשורת מוכרת בישראל, והם צוחקים עלי שאני ילד, כי אני "רק" תשע שנים בתחום התקשורת. כאשר אני התחלתי (ועדיין אפילו לא מתקרב לחיתולים)  ללמוד קצת על SS7 ו SIGTAN עבור אחד הפרויקטים.

פרויקט של גוף ממשלתי שהשורשים שלו נטעו בסוף 2012, הגיע למצב של פיילוט ב2015, שעכשיו ב2016 כנראה שיכנס להיות בכל הארץ אצל אותו גוף ממשלתי.

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

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

דברים נוספים שהתחילו ב2013, התפתחו יותר ב2015, כאשר אני מקווה שעד 2017 אוכל כבר להציג ולדבר עליהם בחופשיות יותר, היות והם הולכים לשנות מספר גישות שאנחנו מכירים כיום, במידה ויישארו בכיוון שנכנס כרגע, והיו כמובן משוחררים בקוד פתוח.

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

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

הכירו את SCTP

זהירות, פוסט ארוך

לאחרונה התחלתי ללמוד קצת על מערכת אותות מספר 7 (SS7) במסגרת פרוייקט מאוד גדול שאני מתעסק בו כבר מספר חודשים לחברה מאוד גדולה וידועה.

עד עכשיו היה שימוש רק ב E1, אז החיבור הוא קווי באמצעות קו רגיל של ISDN, אבל יש לזה מגבלה של 30 ערוצי תקשורת פר חיבור (אם אין דחיסה).
אנחנו כמובן מעוניינים לספק כמה שיותר תעבורה, אז התחלנו לברר על משהו הנקרא SIGTRAN אשר הוא בעצם SS7 על גבי IP, אך הוא אינו משתמש ב TCP או UDP בשביל זה, אלא על גבי פרוטוקול (יחסית חדש) בשם  SCTP.

אני כבר מספר שנים יודע כי הפרוטוקול קיים, ומעולם לא הבנתי מדוע עולם ה VoIP לא לקח אותו לשימוש. ולאחר שלמדתי על HTTP/2 לא הבנתי גם מדוע הוא לא נבחר לשם.
הפוסט הבא מנסה להסביר בקצרה יחסית מהו הפרוטוקול, בתקווה שיעזור לכם להיחשף לעוד מידע שלרוב איננו נחשפים אליו.

מהו SCTP?

הקדמה

ישנם שני פרוטוקולים מעל רמת IP אשר מאוד מוכרים בעולם – TCP ו UDP.

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

כאשר מדברים על UDP, אנו מדברים על מערכות הדורשות גישה של real-time. אין בפרוטוקול עצמו איזשהו מנהל אשר יודע מה קורה עם המידע, כלומר הוא לא יודע לזהות ולדווח האם הבקשה הגיעה ליעדה בהצלחה או לא, או האם הסדר הוא בכלל תקין, ובעצם הניהול הוא בפרוטוקול עצמו (שכבה 5 ולפעמים גם 7) המשתמש ב UDP ולא מתוך שיטת התעבורה הנקראת UDP.

אז מה הוא SCTP או Stream Control Transmission Protocol בשמו המלא?

הסבר הרעיון (TL;DR)

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

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

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

כלומר יש לנו כאן סוג של פרוטוקול multiplexing .

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

מוכר לכם ממשהו? למשל מגישה בשם HTTP/2?
אבל כאן זה פרוטוקול ברמה נמוכה יותר, ולא מימוש בשכבה 7.

אבל העניין הוא שזה ממש לא הכל. יש לפרוטוקול תמיכה בmultihoming – כלומר האפשרות להתחבר למספר שרתים במקביל, וכך להבטיח שרידות בקבלה ושליחה של המידע.
הפרוטוקול אפילו מאפשר תמיכה במציאות הנתיב עם האיכות הכי טובה שהגדרנו, כמו ש MPLS, DiffServ וכיוב' מספקים.
עוד פיטצ'ר נחמד, הוא תמיכה ב jumbo frames, אשר מאפשרים לשלוח עם MTU גדול יותר מ1500 בתים.

אז כיצד זה בעצם עובד?

להמשיך לקרוא

אנדרואיד, mms ובעיית אבטחה עם פתרון ישים

נמצאה בעיית אבטחה (למעשה באג) באנדרואיד כאשר מקבלים mms. הבעיה בגדול מאוד, אומרת כי ניתן ליצור תמונה שתוכל להריץ קוד זדוני, וכל מה שצריך לעשות זה לשלוח לטלפון mms, ואפילו לא צריך לפתוח אותו, היות ואנדרואיד יוריד ויפענח את התמונה ואז הוא גם יריץ את הקוד.

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

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

בעולם הסלולרי, יש לנו יכולת לשלוח הודעות קצרות (אם כי לאחרונה זה הפך להיות יותר כמו מגילה מאשר הודעה קצרה) בשם SMS. הפירוש של SMS הוא Short Message Service.
הוא נשלח באמצעות אותות בשם ss7 ממכשיר לאנטנה, ומאנטנה לספק טלפון כלשהו. עכשיו הספק מעביר את זה הלאה לספק אחר שהוא שולח את ההודעה למכשיר אחר.

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

אחרי שהגיע אלינו WAP, הגיעו מהנדסים ושאלו מדוע לא ניתן "לנצל" את ה WAP ואת ה SMS ביחד ולשלוח בעצם מולטימידיה באמצעות הודעות קצרות (דמיינו מם לזה). וכך נולד לנו ה MMS.

כיצד עובד ה MMS? אני שולח הודעת SMS במבנה מסוים שאומר כי יש לי משהו כדוגמת תמונה בשרת שניתן להוריד באמצעות WAP.

אז עכשיו אחרי שהבנו, מבלי להיכנס לעובי הקורה כיצד הדברים עובדים, הנה הפתרון הכל כך פשוט:
ספקי הסלולר המחזיקים שרתי WAP, או בכלל ספקי SMSc המחזיקים בשרת WAP, יכניסו משהו פשוט שנקרא "אנטי וירוס", אשר מזהה מערך התקפות על קבצי מולטימידיה, ובכך בעצם הבעיה קיבלה מענה די הולם, אם כי לא מושלם.

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

ניסויים בתורי הודעות

יש מערכת שאחרי load test הבנתי כי אני חייב לבזר את המערכות שבה. אז התחלתי לבצע מחקר על סוגים שונים של message queue בשביל לבזר את המערכת. עשיתי ניסויים עם המון מערכות שונות, כולל התייעצות עם אנשים שממשים כבר מערכות המשתמשות בהם, והגעתי להבנה כי כנראה ש RabbitMQ מתאים לצרכים שלי.

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

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

למשל אני עשיתי 2 הגדרות בלבד לRabbit להתאים למכונת הפיתוח החלשה שלי, והגעתי ללמעלה מ7 מליון בקשות בשניה אחת, עד שרוחב הפס נחנק, אבל ה load היה על 0.02 לאורך זמן רב. כלומר לא הגעתי ל load שהם דיברו עליו. אבל יכולתי לבדוק לאורך זמן, רק כאשר ירדתי בערך ל5 מליון בקשות בשניה, ואז הרוחב פס כבר לא נחנק לי.

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

יותר מזה, בתיעוד של Rabbit, כתוב שאפשר להגביל את ה load על המכונה, במידה ועוברים כמות מסויימת של שימוש במשאבים, היא מפסיקה לקבל עבודות, דבר שגם לא הוסבר אם נכנס לבדיקה שלהם, אך אני בכלל לא הגדרתי אותו.

כך שלי חסר מאוד מידע איך ומה בוצע בפוסט, אבל אני לא מצליח לשחזר את מה שהם כן מזכירים.
העניין הוא, שאני לא בוטח ברדיס לפעולות ה mq שאני צריך, כי אני צריך מחסנית יציבה של worker..
אם חלילה וחס הוא נפל, אסור שהמידע יאבד, ויותר מזה, במידה ואני צריך להוסיף workers, אני צריך מצב של ביזור המידע, בלי שworker אחד ידרוך על השני, ואני מקבל את זה בצורה טבעית ב Rabbit, (ועוד מספר סוגים של MQ שבדקתי), אבל רדיס מעולם לא תוכנן לזה. הוא נמצא בזיכרון, אני כמובן שיכול להכריח אותו לכתוב לדיסק (איטי מאוד, אבל זה מה שקורה עם persistence queue בRabbit), אבל בשביל לעשות תורים בגישה של Round Robin, ובכן, בלי לכתוב משהו ב lua, אני לא מכיר תמיכה לזה ברדיס, למרות שאשמח לגלות שיש.

ככול שאני עובד כרגע (אמנם עדיין בפיתוח) עם MQ, ככה אני אוהב יותר את הרעיון של השימוש ב Rabbit.
במערכת שאני בונה, יש לי מערכת חיצונית שהיא של ספק אחר שמדברת עם HorentQ, דרך הפרוטוקול שנקרא STOMP (בניגוד לRabbit שברירת המחדל שלו היא AMQP אך תומך גם ב STOMP), והיתרונות של מערכת כזו שהיא robust מאוד, מאפשרת להתמודד עם בעיות שונות, כדוגמת קריסת מערכת, ניתוק התקשורת, התנהלות של load balance של מספר שרתים וכיוב'…

כך שלדעתי, אחרי הרבה ניסויים, אני חושב שRabbit זו הגישה המתאימה לי, ובמידה ולא, תמיד אפשר לעבור בלי להחליף קוד 🙂

 

 

חשיבה מופשטת

לפני כ15 שנה קראתי ספר על תכנות בעולם הAI, אשר בו מלמדים בעיקר לחשוב, ופחות לתכנת.
הנה הדגמה: יש לי משולש, עיגול ומרובע. כיצד אוכל להגיד למחשב להניח את המרובע, על המרובע לשים את העיגול ועל העיגול לשים את המשולש?

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

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

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

תיאור זה מה שhtml עושה מצויין. למשל יש את כל הנושא של aria, המתארת איך להסביר מה בעצם לבצע עם הטאגים, המידע והאלמנטים בכלל עבור קוראי מסך (למשל), וכך למשל הטאג של role מסביר מתוך aria שה ul שיש לנו, הוא בעצם תפריט ולא bullet point, כי לעיצוב אין משמעות, וה div ההוא זה בעצם חלון דיאלוג, וביחד עם שאר ה aria, אני יכול להגיד כי ברירת המחדל שלו, הוא מוסתר.

כן, כמובן שאפשר לעשות את זה ב Javascript וכמובן שיש לזה גם css, אבל קוראי המסך לא מתעסקים בעיצוב או תכנות, אלא בקריאה של התיאור בלבד, כלומר HTML.

אבל זה לא הכל. גם לעיצוב בhtml יש תיאור, למשל בשביל להגיד שcss הוא עבור המסך. זה נקרא media types.

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

אני מסביר לדפדפן כי הדף שנטען הוא למשל בקידוד של UTF-8, ואני מסביר לדפדפן כי אסור לו לבצע זום.

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

וזה הכיוון שאני חשבתי עליו כאשר דיברתי על מה אני הייתי רוצה ש HTML יבצע.

למשל אני רוצה שhtml יתאר כי התוכן בתוך ה div יטען מקובץ מסוים, אבל רק אם גודל המסך מתאים לחוק מסוים, ובמידה ולא ניתן לטעון את המידע, הצג הודעת שגיאה.

מה זה מאפשר לנו להשיג אם זה בhtml (ולא, זה לא דומה אפילו לתכנות)?
דבר ראשון, זה אומר שאנחנו טוענים פחות מידע. למשל יש עכשיו את פרוטוקול HTTP/2. הפרטוקול אומר כי בגלל שיש המון מידע שצריך להטען, במקום לחכות לכל המידע הזה, אני אכניס הכל בבקשה אחת ואצור multiplexing.
טעינה של המון לוגיקה ב Javascript, טעינה של המון CSS שלא לדבר על תוכן שאולי רק לא יוצג ב HTML, כולם יוצרים בעיות ביצועים. אך במידה ואנחנו נוכל לטעון רק את המידע הרלוונטי כאשר הוא רלוונטי בלבד, אז למעשה כמות המידע ירד, ולמרות ש HTTP/2 הוא נחמד, עדיין אשיג אופטימיזציה מצויינת רק מעצם זה שאני לא טוען מידע שאני לא זקוק לו.

אז איך ניתן להשיג את כל זה בלי תכנות? סתם רעיון, לא באמת הדרך הנכונה:

<div src="/foo.html" alt="no content" media="(max-wdith: 640px and max-height: 480px)">

הנה עוד בעיה, אתרים עובדים עם bootstrap בגרסה 3.3.4 (לצורך ההדגמה בלבד), ובאתר הראשון שנכנסתי אליו שמשתמש בו, אני מקבל עותק מקומי שעשה minified אבל למעט ה copyright נמחקו כל ההערות בפנים.
האתר השני בכלל משתמש ב cdn. האם הדפדפן שלי ידע כי מדובר באותה גרסה בדיוק? לא! אבל מה אם אוכל לתאר לו שזה המצב? האם זה לא יוסיף לי אופטימיזציה? האם זה לא יוסיף לי מהירות של חוסר טעינה מחודשת של המידע? האם זה לא יוריד את כמות התעבורה לטעינת bootstrap בגרסה זו?

הנה הדגמה גם לזה:

<link href="/styles/bootstrap.min.css" rel="stylesheet" provides="bootstrap" ver="3.3.4">

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

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

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

מעניין איך תפתרו את ה"תרגיל" למעלה …

הבעיות שיש לי עם תכנות ריספונסיבי

הקדמה

אנחנו חיים בעולם שיש בו המון מילות באזז, כדוגמת big data, responsive design, cloud computing, סייבר וכיוב' …
כל המילים האלו מגיעות מעולם השיווק, אבל לאדם טכני לא באמת אומרות הרבה.

במקצוע שבחרתי לעצמי, אני מוצא כי יש פיתוח לוואי בכל מה שאני עושה, אשר נקרא "עולם האינטרנט", שהכוונה כאן היא בניית מערכות מבוססות דפדפנים (ממשקי ווב).

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

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

מונחי יסוד

HTML – שפה אשר יודעת לתאר מסמכים ומה המידע שיתקיים בהם, תוך שימוש באלמנטים שבהם המידע יכול להתקיים.

CSS – הם קבוצה של חוקים אשר יכולים לכסות אחד את השני (מכאן השם: Cascading Style Sheet) בצורה שתספק עיצוב למסמך.

הסבר

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

בטח תשאלו מה ההבדל בין הדברים.
ובכן, כאשר מדברים על עיצוב, אנחנו מדברים על איך המראה יהיה תחת רזולוציות שונות, אבל למשל תקשורת סלולרית (HSPA) כדוגמת 3G, 4G, LTE וכיוב', אינן נלקחות בחשבון, היות והן מדברות על תעבורה, לא על מראה.

העניין הוא, שהתעבורה של המידע צריכה להילקח בחשבון גם כאשר מספקים מערכת למכשירים שונים.
יותר מזה, אנחנו צריכים לקחת בחשבון את הזיכרון שיש למכשיר, מעבד, גודל אחסון של מידע וכיוב' כאשר אנחנו מתכננים סביבה שהיא "תכנון ריספונסיבי", אבל אלו מעולם לא היו חלק מהיכולת של HTML או CSS. כלומר מסמך HTML אינו מודע לכל זה.

כך שאולי יש מסמך איכותי עם המון מידע, שמעוצב מדהים ויודע להיות מוצג בהרבה רזולוציות, אבל האם הוא באמת יודע להגיב כמו שצריך למגבלות המכשיר אשר המסמך מוצג בו?

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

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

הפרוטוקולים המהירים של גוגל

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

עם המהלך הזה של גוגל יצאו 2 פרוטוקולים מאוד מעניינים:

  1. SPDY – אשר כרגע עובר להית HTTP/2
  2. QUIC – היכולת לקחת את UDP ולתת לו רק חלק מהתכונות של TCP

שני הפרוטוקולים למעשה מספקים מערכת שמבצעת multiplexing  – כלומר (על רגל אחת) היכולת ליצור "בקשה" אחת, שבתוכה מכילה המון בקשות, אך כל עוד הבקשות בתוכה אינן מסתיימות, אנחנו למעשה רואים רק בקשה אחת.

העניין הוא, שבSPDY, יש שימוש בפרוטוקול TCP, והוא, כאשר יש משהו שנמשך הרבה זמן הופך להיות סוג של blocking עד שהבקשה הארוכה הזו מסתיימת.
אז איך מאיצים את זה?
אפשר לחשוב על UDP. הבעיה היא שהוא חסר state. כלומר או שעבר לי מידע או שלא, אבל אני לא יכול לדעת מעבר לזה, וזה אומר שבשביל לדעת אם משהו ביצע, אני יוצר עוד סוג של over-head וזה ליצור בתוך המידע שלי יכולת לדעת אם משהו הצליח או לא.

אז הפתרון הוא לקחת משהו שכן שומר את ה state, אבל בלי הרבה over-head. בשביל זה גוגל בעצם ממציאים את QUIC.
הרעיון הוא לספק תקשורת מאובטחת, אשר יודעים מתי ואיך המידע יגיע או אם הוא לא יגיע, אבל בלי להתמודד עם מצב בו יש "תקיעה" של מידע כי מידע אחד צריך להסתיים תוך כדי עבודה, ובכך יש לנו משהו באמצע, בין UDP לבין TCP.

כרגע יש שמועות שבנוסף לHTTP שעבורו תוכנן QUIC, הפרוטוקול יהיה בשימוש בעוד מקומות, כמו למשל webrtc, אך זה רק שמועות כרגע, ונראה שהולך להיות מאוד מעניין 🙂

סינטרה מודולרית

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

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

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

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

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

אנחנו משתמשים בRack בעצם, היות וכמעט וכל הframeworks עבור בניית מערכות web ברובי משתמשים בו, אנו זקוקים לקובץ קבוע בשם config.ru.

הקובץ הזה, בעצם אחראי על התחלת השרת, וטעינה של המערכת שלנו, כאשר הוא תומך בטעינה של יותר ממערכת אחת בו זמנית, כולל שני framework או יותר, אך נכון לגרסה הנוכחית, אני משתמש בו רק עבור Sinatra.

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

לאחר טעינת התלויות, אני טוען קובץ בודד בשם app.rb שהוא בעצם מה שמנהל את האפליקציה שלי. אך במקום להשתמש ב require "רגיל", אני משתמש בפונקציה בשם require_relative, אשר מאפשרת לטעון דברים מהמיקום הנוכחי של הקובץ המנסה לטעון אותה.

כל הקסם של ניהול מספר מחלקות, נעוץ אצלי ב app.rb.
אני יצרתי אותו שיהיה מאוד פשוט – טען לי את המחלקות האחרון והכנס אותן לסביבת העבודה של רובי, על ידי שימוש ב use.

למערכת שיצרתי ישנם שני מצבים – מערכת לדיבוג REST, ומערכת "בדיקות" אשר עליה אפשר לבדוק שדברים עובדים, והיא בעיקר על תקן "echo" כלשהו.

את המערכת של יצירת המסכים, ושליחת ה REST, יצרתי בקובץ rest.rb, והכל מאוגד שם.
יש שם משהו שהולך לעבור למקום אחר בקרוב, וזה מספר מתודות לסיוע בפעולות.

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

Sinatra תומך במשהו אשר קיבל את השם Helpers, וזה מתודות אשר מסייעות לנו לבצע דברים, בצורה שלא נהיה צריכים לחזור עליה כל פעם, וזה זמין גם ל view שלנו, ובגרסה הבאה שאשחרר (נכון לכתיבת הפוסט), המידע יעבור לקובץ בשם helpers.rb ואיתו עובדים קצת שונה ברובי.

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

במקרה הזה, הגדרתי כי במצב של ‎:development משתמשים ב Sinatra::Reloader, אשר מגיע עם Sinatra-Contrib – תת פרוייקט המספק הרבה כלי עזר לדברים שונים.
הסיבה לשימוש ב Reloader הוא לא לאתחל את השרת בכל שינוי שעושים למחלקה של סינטרה, כאשר Reloader מגלה כי התוכן של הקובץ השתנה, הוא גורם ל rack לטעון אותו שוב, וככה אנחנו לא זקוקים לטעינה מחודשת של השרת עצמו.

המערכת שכתבתי, משתמשת ב template בשם haml, למעשה פעם ראשונה אשר אני משתמש בה מרצון. תוכלו למצוא את ה layout.haml שהוא המסגרת הרגילה וכן כרגע קובץ בשם index.haml תחת ספריית view.
ועבור העיצוב, אני משתמש ב Foundation 5, אשר אני אוהב אותה יותר מאשר bootstrap.
עבור Javascript יש גם את jQuery וגם את knockout.js, כאשר אני נעזר גם ב lodash.js למספר דברים פשוטים, והיא מספקת בעצם גרסה שעברה אופטימיזציה ל underscore.

את הקבצים של Foundation, וכל ה Javascript ניתן למצוא תחת public.

דבר אחרון שנשאר לספר עליו הוא שאני משתמש במשהו אשר נקרא puma.
מה זה ?
puma הוא משהו שלוקח את rack וגורם לו להיות שרת לכל דבר ועניין, אשר ניתן לבצע עליו חיבור לשרתי HTTP שונים, כדוגמץ apache או nginx.
החיבור נעשה על ידי הגדרת proxy בשרתים.

ההגדרות של puma, נמצאות תחת config, וכפי שניתן לראות את הקובץ הראשי והחשוב, הוא גם יודע לבנות לעצמו מבנה ספריות במידה והן לא קיימות, דבר שהוספתי לקוד עצמו. הוא כרגע מכוון למצב של development, ולכן יש לשנות קצת הגדרות בשביל שזה יעבור למצב production.

אתם מוזמנים לבצע fork, לשחק עם הקוד וגם להחזיק לי תיקונים ותוספות.

האקינג לראוטר, או איך להפוך ראוטר לקוד פתוח

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

מאז לא היו לי אתגרים באמת מעניינים בנושא ההאקינג של מכשירים, עד שרכשתי את WDR4300 של TP-Link והחלטתי שאני לא אוהב את הרעיון שאין לי שליטה על הראוטר שלי.

גיליתי שאני מוגבל, היות ובמדינת ישראל יש הגבלת תדרים על ידי משרד הביטחון (ולא משרד התקשורת) – WTF ?!
אז בגלל זה אני למשל לא הייתי יכול לעדכן את הראוטר לגרסה חדשה יותר של TP-Link, כי אין להם הורדה של גרסה "ישראלית" המגבילה תדרים (מצטער אבל זה הזוי).

אז התקנתי openwrt, ופתאום נזכרתי לטובה במוקו, אשר דרש ממני קצת האקינג בשביל לגרום לו לעבוד.
מצאתי את עצמי ב7 בערב עד 1 לפנות בוקר מתאים אותו לצרכים שלי.

זה כיף להיכנס למכשיר דרך telnet ולהתחיל להגדיר את הפצת הלינוקס כפי שאתה רוצה. וזה עוד יותר כיף, כשמערכת החבילות זהה למוקו 🙂 .
אחרי שאתה מגדיר סיסמה ל root, ה telnet מתבטל, ואתה חייב לעבוד עם ssh, שגם עברה מספר שיפצורים על ידי.

אני קיבלתי את הראוטר עם חומרה v1.7, שזה השיפצור האחרון של tplink (נכון לכתיבת הפוסט הזה) בנושא החומרה, ונראה שהכל עובד מהקופסא, אחרי שאפשרתי מספר דברים 🙂

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

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

הראוטר של בזק מנתק את ה wifi כל כמה זמן לכמה שניות. כלומר את המכשירים המחוברים אליו.
מדפסת הרשת שלי, משום מה לא עובדת כמו שצריך עם הראוטר הזה, אבל הכי גרוע זה ה TR-069 שיש בראוטר ואני לא יכול לבטל אותו, הוא סוג של back-door  לכל הראוטרים האלו, המאפשרים לבזק לבצע provision מרחוק, אבל מסכנים את הראוטר לחלוטין.

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

אני יכול לבצע אפילו התקנת freeswitch עליו, מגרסת הפיתוח (משום מה), שלא לדבר על אסטריסק, או yate.
התקנה של מרכזיה כדוגמת freeswitch למשל, מאפשרת אם מתבצעת נכון, להעביר את הכוח לסוג של DMZ, שמוגן מתקיפות למינהן, אבל כן מסוגל לבצע שיחות.
אך אין לי כוונה להתקין מרכזיה כלשהי על הראוטר.
אם זה לא מספיק, אני יכול גם להתקין את Kamailio מסדרת שלוש וסדרת ארבע, מה שאומר שאני גם יכול לקבל SIP Proxy שאני יכול לתכנת כפי שאני רוצה, אך גם כאן, זה לא יהיה מה שאעשה.

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

בכל מקרה, אני מאוד נהנה 🙂

אריקסון ו webrtc

כבר כתבתי בעבר על webrtc, אך זה עולם שכל הזמן משתנה ולא רק טכנולוגית.

אחד הדברים שמאוד נחמדים בעולם ה webrtc, זה היענות של מרבית החברות הגדולות בשוק בשביל לאמץ אותו.

גוגל היא החברה הכי מפורסמת שמנסה לקדם את webrtc, ויש לה אתר שהיא פתחה בנושא, והיא משחררת מימוש (בראש ובראשונה נועד עבור כרום) ברישיון MIT.

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

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

החברה פתחה אתר בנושא, ושמה את הקוד שלה ב github, וגם הוא ברישיון פתוח – BSD.
הכלים שהיא משתמשת גם הם פתוחים, כדוגמת Gstreamer .
הם גם משתמשים במימוש של סיסקו – מימוש קוד פתוח עבור H.264, למעשה זה משהו שהם מספקים שגוגל בכלל לא.

הם גם משחררים דפדפן עבור iOS בשם bowser אשר מאפשר בעצם לקבל תמיכה ב webrtc, ובכך הם הופכים להיות הדפדפן הראשון במערכת הפעלה זו שתומך בזה.
הדפדפן נועד לקדם דווקא את H.264, אבל בנתיים גם מאפשר להשתמש ב webrtc.

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

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

כרגע יש קרב גדול על בחירת קודקים לוידאו, כאשר הקרב הוא בין H.264 לבין VP8 ובעתיד גם VP9.

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

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

knockout.js

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

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

תארו לכם אבל, שיש לכם המון שדות לעריכה (לא בהכרח באותו הזמן), שאתם צריכים אבל לנהל בעצמכם, וקיבלתם כאב ראש.

ניסיתי מספר כלים בנושא של data binding כדוגמת Rivets.js ועוד מספר ספריות פשוטות נוספות. אבל אף אחת מהן לא סיפקה את הצרכים שלי, תמיד הייתי צריך לעקם את עצמי בשביל פיתרון, במקום שהפתרון יהיה מתאים לצורת העבודה שלי.
העניין הוא שכל כלי מבקש צורת חשיבה לגמרי שונה, כלומר זה לא שיש דרך אחת נכונה ואני עושה אותה לא נכון, אלא המון דרכים וצורות, שאף אחת מהן לא מתאימה לי אישית.

אז החלטתי לפנות לכלים כדוגמת Backbone, Angular.js ו Ember.js. אבל גיליתי כי עבור הצרכים שלי הן מפלצות – ביחוד אנגולר ואמבר. הכלי שניסיתי היה ד"א אנגולר.

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

חשבתי ליצור משהו משל עצמי, ועשיתי קצת ניסויים בנושא של data binding, וזה גרם לי למצוא כלי מאוד נחמד שבשעה (כולל הפרעות) הצלחתי לעשות את כל מה שלא הצלחתי בשבוע עם אנגולר.

הכלי נקרא knockout.js. הכלי הזה בנוי בגישה של "תשאיר לי את ה data binding, השאר שלך לעשות מה שתרצה".

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

הגישה של konockout.js קיבלה את השם Model-View-ViewModel אשר מאוד מוכרת לי מעולם הדלפי, רק בצורה שונה.

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

המונח של knockout לזה הוא observable.
זה למעשה שדה כלשהו אשר נכנס לפונקציה וכאשר רוצים לשנות אותו, משתמשים בפונקציה שהיא השדה, וכאשר רוצים לקרוא אותו זו אותה הפעולה.

זה נעשה בצורה די פשוטה בג'אווהסקריפט נקי:

function observable() {
   if (arguments.length > 0) {
      //write stuff
   } else {
      // read stuff
   }
}

למעשה arguments זה המקביל ל var_args של C או open array של פסקל, רק שהוא מכיל בתוכו אוביקטים כי זו שפת javascript.

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

הנה קוד מאוד פשוט ב knockout:

<p>First name: <input data-bind="value: firstName" /></p>
<p>Last name: <input data-bind="value: lastName" /></p>
function ViewModel() {
    this.firstName = ko.observable("Joe");
    this.lastName = ko.observable("Bloggs");
 
    this.fullName = ko.computed(function() {
        return this.firstName() + " " + this.lastName();
    }, this);
}
 
ko.applyBindings(new ViewModel());

מה שקורה כאן זה שבמידה ותעבדו עם knockout אתם קיבלתם 2 שדות המכילים מעקב אחרי שינויים בצורה דו כיוונית, כלומר מה שנכתב בבתוך ה input עדיין ישפיע על השדה. ומה שישתנה בשדה, יושפע גם ב input.
בנוסף, יש שדה שמחושב כל פעם לפי הערכים של השדות השהוגדרו.

זהו, זה כל מה שהיה צריך. אין צורך בשיריון של namespace, איזורים וכיוב' … בלי לבחור סוג של template וכיוב'.
במקום שבו משתמשים בשדות, אז נכנסים לתוך ה namespace של אותו אובייקט, ואז במידה ורוצים לצאת החוצה משתמשים ב ‎$parent ובמידה ורוצים להתחיל מההתחלה, משתמשים ב ‎$root כלומר בנקודה שבה קראנו ל applyBindings.
אם אתם רוצים את האובייקט עצמו שאנחנו משתמשים בשדה מסוים (למשל כאשר משתמשים במערך), משתמשים ב‎$data וישנם עוד סוגי משתנים. הנה הסבר פשוט בנושא.

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

טלפון חכם, טלפון טיפש

לאחרונה נשאלתי אצל לקוח שאלה מעניינת – מה ההבדל בין טלפון "טיפש" (טלפון "בזק" רגיל) לבין טלפון "חכם" (טלפון SIP) ?
חשבתי לחלוק את התשובה גם כאן.

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

התשובה המסובכת יותר: להמשיך לקרוא

webrtc ORTC

הקדמה

במידה ולא הכרתם, יש בעולם הHTML5 (באזז וורד בפני עצמו) טכנולוגיה מדהימה לזרימת מדיה בשם webrtc (אשר אפילו אני מספק עבורה פתרונות).

הרעיון הוא לקחת SDP ו RTP (שכמובן מכיל RTCP) ולאפשר להזרים אודיו ווידאו בצורה טבעית בדפדפן ללא שימוש בתוספים.
הטכנולוגיה גם מגיעה עם תמיכה ב STUN, ICE ו TURN.

היא תומכת ב OPUS, ו G711, ומחייבת אותנו לעבוד בצורה מאובטחת תחת DTLS,

עכשיו כל מה שנשאר זה לממש מערכת סיגנלים כדוגמת SIP או כל פתרון אחר – פשוט יותר עם web sockets,שגם הוא כיום (לפי התקן של webrtc) חייב כבר להיות מאובטח תחת TLS, ויש לנו פיתרון סטרימינג מלא.

אבל יש בעיה: SDP הוא אחד הפרוטוקולים הכי לא קריאים שיש, ובנוסף ישנו תיאור של מידע יחסית ארוך.

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

הדגמה קלה (מה RFC):

v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=.
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000

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

הנה הסבר על מה שאתם רואים מול העיניים שלכם:
האות v, מייצגת version – גרסת הפרוטוקול, שלפחות כרגע היא תמיד 0.
האות o, מייצגת origin של הבקשה, ומכילה (לפי הסדר) – שם משתמש, session id, בנוסף session-version, סוג רשת (אינטרנט), סוג הכתובת, כתובת הרשת.
האות s מייצגת את session, כלומר השם שלו.
האות c מייצגת מידע על connection. זה אומר סוג הרשת, סוג כתובת הרשת, כתובת הרשת.
הכוונה היא לאן רוצים להתחבר בשביל המדיה.
האות t מייצגת זמנים.
האות m מייצגת מדיה, עם סוג מדיה, פורט דינאמי, פרוטוקול משלוח של המדיה, ומידע הקשור לפרוטוקול.
האות a מייצגת attribute, שזה תכונות שונות, למשל כאן, זה מייצג איזה קוקדים של אודיו ישלחו, כולל הקוד שלהם שמוגדר ב RFC עבור כל סוג קודק.

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

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

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

תוכן

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

לפני ORTC, תכננו פרוטוקול אחר לגמרי, אשר היה מאוד low level, ומאוד קשה להגנה, וסיפק יותר מידי כוח בצד המשתמש. הפרוטוקול קיבל את השם Open Peer. אז בגלל הסיבות האלו, החליטו לרדת ממנו.

ואז ישבו הרבה אנשים, אשר רובם יצרו את webrtc ואת Open Peer, והחליטו על גרסה 1.1 לwebrtc בכנס מסחרי מסוים, אם כי למרות ההכרזה על 1.1 ההכרזה מרגישה יותר כמו 2.0.
השם לפרוטוקול החדש באותו כנס, קיבל את השם ORTC או Object Real Time Communication, אשר ה draft הראשון (מבחינת יכולת מימוש) שלו שוחרר באוגוסט 2014.
היכולת לעקוב אחרי דברים, נעשת באתר ייעודי לכך בשם ortc.org.

הרעיון הוא לספק סוג של API, שמצד אחד קל לתכנות, ומצד שני קל לאבטח, אשר מאפשר לשלוט בצורה קלה ופשוטה יותר במידע על המדיה, כאשר יש API בצד ה javascript, אך גם עם תאימות לאחור, בשביל לא לשבור פתרונות קיימים.
אבל לא סתם API, אלא הדגש הוא על גישה של Object Oriented, כאשר בעבר דיברו על כך שהיא תכלול את היכולת להחזיק אובייקטים של סוקטים בשם RTCSocket אשר ניתנים לשימוש מחודש במידת הצורך, ובכך בעצם לעשות שימושיות ב RTC ללא צורך באתחול מחודש של הכל. אך אינני מוצא זאת בdraft האחרון (נכון לכתיבת פוסט זה).

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

הבעיה היא שORTC הוא סוג של API שבסוף משתמש ב SDP (אבל רק בהתחלה – תאימות לאחור) ואח"כ כנראה שיפרד מהגישה הזו. אבל הם עוד לא בטוחים בזה. כלומר הרעיון שלהם, הוא שבסופו של דבר לא יהיה SDP, אלא דיבור ישיר בין ה"ענן" (מערכת כלשהי שאתם תבנו בצד השרת) לבין הדפדפן, ואיכשהו יוחלט מה יורץ.

זה רעיון נחמד, אבל איך הוא מתבצע כאשר אין לך SDP ?
התשובה פשוטה – אתה תממש משהו כזה מחדש, ואתה תספק לו שם חדש, למשל השם Media Information Protocol או משהו בסגנון.

ואכן, זה מה שORTC מבצע. הם יצרו אובייקט בשם RTCRtpCapabilities, אשר התפקיד שלו לדבר על "מה אני צריך" עם הצד השני וניתן אפילו לעשות החלפה בזמן ריצה של המידע (ב SIP זה נקרא re-Invite).

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

יש עודף שאלות פתוחות לדעתי בנושא, והוא לא באמת כזה ברור בשלב הנוכחי, והוא צריך עוד להתבשל ולהתפתח יותר.

אבל הגישה הזו של ORTC ובעצם שכתוב של חלק מאוד חשוב ב webrtc גורם לכך כי במקום לסייע לאנשים לאמץ את webrtc, מרבית השוק כרגע מנסה להתעלם ממנו לגמרי, וזה רק מעקב את האימוץ הזה, אך האם המאמץ הזה יהיה שווה ? רק ימים יגידו.

אז מה דעתי בנושא ?
מצד אחד, אני חושב ש SDP זה כאב ראש. מצד שני, אני לא עד הסוף סגור על הרעיון של ORTC, ולכן אני לא ממהר לקפוץ ולהגיד שזה טוב או רע, רק מפריע לי שהוא שונה כל כך מהתקן הקיים היום (שעדין ב draft), היות ולי אישית כבר יש מימושים בנושא.

קודקים למתחילים

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

ישנו מושג בעולם המולטימדיה אשר נקרא codecs. הפירוש הוא encoder ו decoder של מידע כדוגמת אודיו ווידאו.

ישנם הרבה מאוד סוגים מאלו, אבל מה זה בעצם אומר ?

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

ישנם 2 סוגי דחיסת נתונים בעולם הקודים:

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

Lossless מייצג צורת דחיסת נתונים עם יכולת שחזור מלא של המדיע ללא איבוד המידע. הדחיסה נמצאת בעיקר בדחיסת מידע מדוייק, כדוגמת טקסט, פורמטים כדוגמת ZIP וכיוב'.
ישנם גם תמונות (כדוגמת PNG) ואפילו קבצי קול (כדוגמת FLAC) המשתמשים בשיטה זו, אך אלו נדחסים פחות טוב בדרך כלל, ולכן גודל הקובץ גדול יותר, מאשר אם היו משתמש בים lossy.

G711

להמשיך לקרוא

ענב הזעם – API

ברובי, הדבר הכי מוכר ביקום הוא framework בשם Rails, אשר מאפשר ליצור אתרים דינאמיים בצד השרת.

ישנם עוד מספר סוגי framework עבור עולם ה web, בהם Sinatra, שאני משתמש המון, ולאחרונה התחלתי לשחק גם עם framework מאוד מעניין שנקרא grape.

Grape הוא framework אשר נועד לתת לנו כלי לפיתוח API. זה אומר שכל הפיטצ'רים שלו הם על טהרת REST ואין שום דבר הקשור להצגת templates למשל בצד המשתמש.

כלומר ניתן להציג xml, json או כל מבנה אחר של מידע, אבל זה לא נועד ליצור אתר, אלא להחזיר מידע, או לבצע פעולות API.

הנה הדגמה קלה כיצד תראה תוכנית שכזו: להמשיך לקרוא

למי הפרופיל רשת חברתית קיים אחרי המוות ?

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

כאשר הגיע יום ההולדת של אותו אדם, התחלקו הדברים לאלו שידעו/זכרו את המצב, מול אלו שלא, וזה נראה כך:

facebookעכשיו השאלה היא לא רק למי שייך המידע, אלא מה קורה עם פרופיל שכזה כאשר אדם מת ?

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

מה אנחנו כבני אדם בכלל רוצים שיהיה בחברה שלנו במצב שכזה ?

פוסט למחשבה.

סידור תיבות דואר

יש לי חבר קיבל פרויקט בעבודה שלו – סידור מחדש של שרתי דואר של לקוחות החברה (חברת ISP), ולמרות שהם כולם בתוצרת maildir, הם מסודרים בצורה לא קבועה, וחלקם נמצאים בספרייה בשם mbox למשל, למרות שהם לא בפורמט הזה.

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

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

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

  • חיפוש תתי ספריות ברקורסיה
  • איטרציה על קבצים
  • ביצוע פילטר על תוכן במערך
  • יצירת ספריות
  • העתקת תוכן של ספריות בצורה רקורסיבית

טיפים על עבודה ב ssh

כאשר פותחים חיבורים של ssh,אנחנו מקבלים משהו שנקרא channels, שהם בעצם הצורה ש ssh מזהה את החיבורים שלנו על אותה "מנהרה" שמוצפנת.
חשוב להדגיש כי חיבור לשרתים שונים, לרוב לא יכללו את אותה המנהרה, אלא רק חיבורים לאותו השרת, אך כל חיבור מכיל channels.
אני נוהג להשתמש בצורה שבה כל חיבור לשרת, משתמש בsocket בודד, וכך עושה את החיבור יעיל אפילו יותר – היות וגם ככה כל חיבור מנוהל על ידי channel.

בשביל להתחיל לעבוד בגישה הזו, של מספר חיבורים בו זמנית על אותו הsocket ניצור תחת ספריית הבית שלנו תת ספרייה (עם נקודה בהתחלה) בשם ssh. .במידה והיא קיימת, זה מצויין.

בתוך הספרייה ניצור קובץ בשם config ונכנס לו את ההגדרה הבאה:

Host *
  ControlPath ~/.ssh/sockets/master-%l-%r@%h:%p
  ControlMaster auto
  GSSAPIAuthentication=no
  ServerAliveInterval 25
  Compression yes
  IdentityFile ~/.ssh/id_rsa

ה"חלק" הזה שיצרנו בעצם יוצר קבוצה של הגדרות עבור 100% מהחיבורים שלנו (אלא אם נדרוס אותן). אנחנו יודעים זאת, בזכות הglob של כוכבית.
אנחנו אומרים לו ליצור קובץ socket על שם החיבור המדויק שלנו, ושopenssl ינהל אותו לבד. מדובר למעשה ב unix socket, וזה מה שמאפשר את השיתוף.
אנחנו אומרים למערכת שלנו כל 25 שניות לשלוח סוג של ping בשביל להשאיר את החיבור פתוח (אחרת יש חיבורים שיסגרו בשרתים שונים אם אין תגובה אחת לזמן מסוים), אנחנו דוחסים את המידע העובר עם החיבור, ובסוף אומרים מה המפתח ברירת המחדל שלנו.

כל האופציות האלו, הן אופציות שניתן להגדיר גם בשורת הפקודה, וגם תחת ssh_config שנמצא ב etc, אך כאן אנחנו עוקפים את ההגדרות של הקובץ האחרון, ובנוסף אין צורך ליצור משהו בשורת הפקודה, ואפילו alias מיותר.
בשורת הפקודה אנחנו מגדירים את רובם עם הדגל של ‎-o, ואז מציינים את ההגדרה שרוצים.

הקובץ של config מאפשר לנו גם לבצע הגדרות מדוייקות לשרתים שונים. למשל: להמשיך לקרוא

אפצ'י מפסיק לפעמים להגיב לבקשות בצורה רנדומאלית

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

העניין הוא, שזה קורה בהרבה שרתים שונים, שנמצאים במקומות שונים בעולם, על תשתיות שונות לגמרי, ובצורה לגמרי רנדומאלית. הדבר היחיד שמשותף לכולם זה LAMP.

הגעתי אל המשרדים של השותף, במטרה ליום שלם של מחקר בנושא. ובאיזשהו שלב, גם הצלחתי לשחזר את הבעיה – ובעיה זו היתה מאוד קשה לשחזר, ולמעשה רק אחרי הצהריים הצלחתי להגיע אליה, למרות שהתחלתי את המחקר ב9 בבוקר.

הפעלתי wireshark, וגיליתי כי three way handshake אינו מתבצע עד הסוף, ולמעשה ה ACK האחרון לא נשלח חזרה על ידי השרת (ה wireshark היה על השרת עצמו).
יש מספר נסיונות שליחה של לחיצת היד, ובסוף יש RST על הבקשה כי לא ניתן היה ליצור קשר, והבקשה התנתקה.

גוגל לא עזר בכלל, כנראה שהבעיה מדוייקת מידי וקשה להסביר אותה במילים, ובסוף נשברתי, ושמתי nginx על אחד השרתים, ושום דבר לא חזר על עצמו, כלומר המערכת עבדה חלק בלי שום בעיות למשך יום וחצי של עבודה עוד.
לפני ה nginx ניסיתי אפילו את שרת הפיתוח של PHP בנושא, וגם אצלו לא היו בעיות שונות, הבעיה היתה רק באפצ'י. אם בהתחלה חשבתי שאולי יש באג בTCP Stack של לינוקס, זה די כיוון אותי לכיוון האפצ'י.

בנתיים דיברתי עם בוריס, והוא הצליח למצוא קישור מעניין שמדבר כי אפצ'י בברירת המחדל מגיע עם דגל של TCP_DEFER_ACCEPT. עד כמה שאני מבין, הדגל הזה אומר לשרת לא לחכות ל three way handshake, אלא במידה ונשלח מידע אחרי החיבור הראשוני, כשעוד אין ACK, אלא רק SYN-ACK, ניתן כבר לקבל את המידע, ולמעשה רק כשהוא יסתיים להישלח, ישלח גם ה ACK.

מסתבר שבאפצ'י 2 הדגל מאופשר בברירת המחדל (בניגוד לnginx ששם צריך להגיד לו את זה במפורש), ולכן צריך לכבות אותו.

בשביל לכבות את הדגל בחיבור, צריך לשים ב httpd.conf הראשי, את הקוד הבא:

 AcceptFilter http none

במידה ויש הגדרה אחרת בנושא, למשל עם data, יש לשכתב אותה לnone.
וזה מכבה למעשה את הדגל של TCP_DEFER_ACCEPT ועכשיו אפצ'י חייב לחכות ללחיצת היד כמו שצריך לפני שיוכל לנתח את מה שנשלח.

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

 

מערכת פשוטה לשיתוף קבצים פנים ארגונית

יש לי פרויקט ארוך טווח עם מספר אנשים, אשר חלקם מאוד לא טכניים, בלשון עדינה.
היה צורך לשתף בין כולם קבצים, אבל כל אחד עובד על סביבות לגמרי שונות, וכל האנשים הם עסקים קטנים מאוד, אשר מערכות שיתוף קבצים רגילות כדוגמת share point או own cloud הם overkill רציני לנושא, ולפחות המערכת של מיקרוסופט יקרה מידי לנושא, ומחייבת אותנו להחזיק שרתי ווינדוז ללא סיבה אמיתית.

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

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

אז החלטתי כי במקום להמשיך ולחפש תוכנה, אכתוב משהו פשוט שיעשה את זה, ותוך שעה וחצי, כולל דיבוג כתבתי את simple file sharing – גרסת mercurial וגרסת git.
זהו מנוע פשוט, הכתוב ברובי עם סינטרה ללא javascript שאני כתבתי, אלא cgi מול html/css פשוטים מאוד מבוססי foundation.

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

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

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

node.js כן או לא ?

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

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

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

אבל יש לי עם זה בעיה, שגורמת לי לחשוב ולרעוד מפחד, כל פעם שאני מסתכל לכיון node.js.
גוגל החליטה לפני שנה לעשות fork לwebkit שהוא עצמו fork של khtml, וקראה לפרויקט שלה blink.
היא עשתה זאת, מבחירה מסחרית גרידא ("אנחנו בידלנו את עצמנו בצורת פרוססים וטרדים שלנו, ולכן עשינו fork").

אמנם node.js לא משתמש ב webkit או ב blink, אבל הוא יוצר לי בעיות קשות:

  1. האם v8 ישאר גם מחר ?
  2. האם יהיה fork ?
  3. האם הוא ימשיך להיתמך ?
  4. האם הכיון שלו כיום ישאר, או אולי ישוכתב/ישתנה לגמרי בגרסאות חדשות יותר ?

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

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

יכול להיות שאם דבר כזה יקרה, אולי השוק פשוט יברח מ node.js ורק מי שאינו יכול להרשות לעצמו יתקע.

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

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

עייפות הIT

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

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

עולם העסקים, נחשב אצל המון אנשים כשדה קרב שבו כל יום הוא מאבק אין סופי, אך אפילו בצבא, יש מנוחה, והניסיון לחלץ אנשים משדה קרב כאשר רק ניתן, ולא להמשיך ולתת לחייל להיות בתוך המלחמה 24/7 במשך כל השנה ללא הפוגות שיאפשרו להם להתאושש, דבר שאינו באמת מתרחש בעולם העסקי של ימנו.
כאשר מדובר בארגונים, לפעמים שעה של אי זמינות, מתפרשת כאסון כאילו היקום קרס, וצריך בשניה הזו ממש מענה להכל.

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

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

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

הבעיה של זמינות של 24/7 מחלחלת למטה, עד שאם כרגע יש תקלה ברשת כלשהי שכלל הציבור משתמש בה (למשל שרתי דוא"ל לא מגיבים, אתר מסויים למטה, רשת סלולרית אינה מגיבה), זה נחשב באותה מידה לאסון עולמי. למרות שרשת תקשורת אולי כן חיונית למענה של חיים ומוות, מרבית השירותים אינם כאלו, למשל שידורי תוכנית טלויזיה אהובה שמתפספסים בגלל תקלה, אך עדיין הגישה מכריחה את כולם לתת מענה מיידי, או שהשמים יפלו ומלחמת העולמות תתחיל בלעדינו.

מוקדש כחומר למחשבה

תם עידן הפרטיות, תחי הפרטיות

Le roi est mort, vive le roi !

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

אנחנו חיים בעידן של מאגרי מידע, ואנחנו חיים בעידן בו אנחנו יכולים לחשוף את ערוותנו בציבור באמצעות האינטרנט (ואף מדיות אחרות). כל זה באמת קיים כיום. אך מדובר בנושא של בחירה מול הכרח.

האם אני רוצה לשתף את הרחוב בכל דבר העובר עלי, או האם אני מעוניין להשאיר לעצמי דברים ?
האם אני באמת חושש מכך שיראו תמונה שלי וידעו שזה אני, או האם אין לי בעיה בכך ?

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

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

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

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

וכך המעבר מבחירה מה לחשוף ואיך להחשף הופכת לאבסולוטית וכאן הבעיה – חוסר היכולת לשלוט במידע ובזהות שלנו יותר, וזו המשמעות של וויתור על הפרטיות.

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

זה תלוי בנו בלבד, ובבחירות שלנו. אני מקווה שכולנו ננהג בחוכמה בנושא.

מוגש כחומר למחשבה.

יצאה גרסת 1.4.4 של FreeSwitch

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

המרכזייה בנויה מיחידת בסיס (core) ואוסף מודולים שונים, אשר מספקים לה תכונות שונות, בהתאם לצורת השימוש.
למשל, במידה ומעוניינים ליצור call centre, אז יש מודול לכך, ובמידה ורוצים ליצור ivr בצורה פשוטה, גם לכך יש מודול. אפילו חדרי ועידה מקבלים תכונות רבות יותר מאשר אלו של אסטריסק.
כל ההגדרות כולל ה diallplan נעשות באמצעות קבצי xml, אבל אפילו תוכניות החיוג זה למעשה מודול חיצוני. כאשר מעוניינים בכך, ניתן לצאת לשפות תכנות חיצוניות (גם כמודול), כדוגמת lua (שנתמכת הכי טוב), פרל (לא מתועדת מספיק), פיתון ואפילו ג'אווה סקריפט (יש תמיכה ב v8 ו SpiderMonkey, כאשר האחרון נמצא בשלב deprecated).
בנוסף, יש מימוש של event sockets – אחת הדרכים לשלוט במרכזיה, ולקבל אירועים ממנה, על ידי שימוש בפרוטוקולי תקשורת, כדוגמת TCP. ואלו מאפשרים חיבור של שפות נוספות, כדוגמת Go.
בנוסף, יש גם ספרייה שממשת את rayo – תת פרוטוקול xmpp אשר מאפשר גם שליטה דומה ל event sockets.

אז מדוע אני מציין דווקא את הגרסה הזו על פני כל הגרסאות הקודמות ? ובכן, זו הגרסה הראשונה של סדרת 1.4, אשר נחשבת לגרסה יציבה, ולא גרסת Beta. כלומר זו גרסה רשמית יציבה ראשונה של העץ 1.4.

עץ 1.4 הביא איתו המון חידושים ושיפורי ביצועים, בהם בראש ובראשונה תמיכה מלאה בתקני webrtc ו websockets, אשר מניסיון שלי, טובים יותר מהתמיכה שיש באסטריסק. נכון לכתיבת שורות אלו, כרום ביטל את התמיכה ב SDES, דבר שמקשה על התמיכה ב webrtc של אסטריסק ללא בנייה אישית שלו, בעוד שFreeSwitch תומך ב dtls-srtp ללא בעיה מהקופסא.

בעוד שהפצת הלינוקס העיקרית של אסטריסק מבוססת red-hat (בדגש על centos), החל מגרסה 1.4, דביאן היא ההפצה הרשמית של Freeswitch.
במידה ואתם עדיין על centos5, אז יש סיכוי כי אולי תתקלו בבעיות בעת השדרוג.

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

את היכולות (הלא מלאה או מעודכנת) של Freeswitch, ניתן למצא בדף הבא בוויקי של הפרוייקט.
למעשה הוויקי של הפרוייקט, הוא התעוד עצמו של הפרויקט, והוא בנוי בצורה מאוד טובה ונוחה, ולרוב מתועד כמו שצריך.
למעשה אם משווים אותו לאסטריסק, אז לאסטריסק אין תעוד בכלל בוויקי של הפרוייקט, למעט הAPI עצמו, אך כמעט ללא הסברים ודוגמאות, וזאת בניגוד ל Freeswitch.
הוויקי של הפרוייקט כרגע בתהליכי מעבר ל Jira, התעוד החדש יושב כאן. אבל חשוב להבין כי היות ויש כרגע מעבר (איטי), כרגע יש מעט בלאגן בנושא, אך גם הוא בלאגן מתועד (בתוך דף הוויקי הספציפי שעבר).

העניין החשוב באמת הוא, ש FreeSwitch מספקת את האפשרות לקבל מרכזייה יציבה, שמשתמת יחסית במעט משאבים (תלוי באופן השימוש), עם המון יכולות.
היא יכולה להיות למעשה מרכזייה ברמת class 4 ולא רק class 5 בניגוד לאסטריסק למשל. ועץ 1.4 מבטיח כניסה לעולמות חדשים.

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

סיפ, מדוע זה לא פשוט כמו HTTP ?

אחד התסכולים הרבים שיש בעולם ה VoIP הוא התמודדות עם בעיות הקשורות לעולם הרשתות.

רוב העולם בטוח כי HTTP זו התקשורת המסובכת ביותר שיש בעולם הרשתות, ולכן אני שומע את השאלה: "אני לא מבין למה SIP לא פשוט כמו HTTP ?"

ובכן, התקן של SIP בראש ובראשונה מדבר כי חייבים לתמוך ב UDP, אך ניתן גם לתמוך ב TCP.
אבל זו לא הבעיה בכלל. UDP זו לא צורת תקשורת שהיא אויב כלשהי, היא פשוט עובדת ללא ידיעה מה מצב המידע שנשלח, מה שאומר שאת המצב מעלים לרמת פרוטוקול במקום לרמת תשתית (layer 4)

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

RTP עומד בפני עצמו, ואינו חלק מ SIP עצמו, כלומר, הוא עוד תעבורה נוספת, עם חוקים משלו, כאשר SIP רק שולט במשא ומתן עם הצד השני, של מה נתמך ואיך ולאיפה יש לבצע זאת, באמצעות פרוטוקול נוסף, אשר נקרא SDP.

על זה נוסיף עוד בעיה "נחמדה" אשר נקראת NAT, כאשר ישנם 2 סוגי NAT: להמשיך לקרוא

מוזילה, לאן ? (2014)

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

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

פיירפוקס תומך בהרבה טכנולוגיות חדשות אשר מתאימות גם לי כאיש טלפוניה, כדוגמת webrtc.
מצד שני, הוא החליט לממש את נושא האבטחה בצורה מאוד בעייתית, שנראה כאילו נדרש משהו באמצע ש"יתקן" את הבעיה (כמות הפורומים, באגים ושיחות ברשת על הבעיות של DTLS עם פיירפוקס בנושא, מאוד נרחבת).

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

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

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

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

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

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

אז השאלות המתבקשות הן:

  • מה הכיוון שמוזילה הולכים אליו ?
  • לאן הם בדיוק מכוונים ?
  • האם יש עתיד כלשהו בכיוון שלהם ?
  • האם כיום יש עם מי לדבר, כאשר מימוש טכנולוגי מסויים (למשל webrtc) אינו מתפקד כמו שצריך ?
  • האם בעתיד יהיה מישהו לדבר איתו על כך ?
  • כיצד הם באמת מספקים אלטרנטיבה ראויה למתחרים שלהם, אשר לא בוחנים אידיולוגיה, אלא ביצוע ?

או בריכוז לשאלה בודדת, מוזילה, לאן ?

תכנון מודלארי של מערכת

"If I had eight hours to chop down a tree, I'd spend six sharpening my ax." — Abragam Lincoln

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

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

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

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

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

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

בגישה המונוליטית יותר, היה קשה יותר להתאים את עצמי לשינוי של flow מסויים של המערכת, ולהוסיף במקומות מסויימים משהו נוסף, ובמקומות אחרים להסיר משהו אחר.

למשל אפילו הגדרה של "עד שלא מאשרים משהו, אתה משמיע אפשרויות" לקח לי חצי דקה להוסיף למערכת.

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

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

הגדרת sip trunk עם freeswitch

freeswitch שונה מאוד מאסטריסק בתפיסה של איך דברים עובדים.
במידה ונרצה להוציא שיחות או להכניס שיחות, אין צורך בהגדרות מיוחדות, למעט הגדרות acl לכתובות ip. כלומר בברירת מחדל אין צורך ככה סתם להגדיר sip trunk בשביל שדברים יפעלו עבור ספק מסויים.

אך במידה ויש צורך להגדרות מיוחדות, או הגדרות של ביצוע פעולת register, אז אנחנו זקוקים להגדיר sip trunk, אך גם שם ישנם 2 גישות, אשר מוגדרות תחת sip_profiles:

  1. internal
  2. external

הרעיון של sip_profiles הוא כאשר צריך להגדיר דברים תחת רשת פרטית (lan) מול דברים השייכים לרשת ציבורית (wan). למעשה זו סוג הפרדה של השימושים במערכת, אשר מאפשרת להתנהג שונה בהתאם למקור ההגדרות. אפשר להגדיר את זה כרשת trusted מול רשת שהיא untrusted אם זה נוח יותר.

בברירת המחדל, internal מוגדר להשתמש עם sip בפורטים של 5060 ו 5061 (אם זה sip או sips). בעוד שרשת external מוגדר בברירת המחדל להשתמש בפורטים 5080 ו5081.

השאלה הנזרקת לאוויר, היא מה קורה כאשר הרשת החיצונית נכנסת דרך 5060, והתשובה היא שfreeswitch מכניס ל header בקשה לעבור ל5080, ובמידת האפשר מעביר את התקשורת לשם, ואם לא, אז נשארים על 5060, אבל היא לא נחשבת לרשת trusted.

העניין הוא, שזה לא נעצר בפורטים, או בהפרדה הזו, אלא זה ממש מסייע למפות מההתחלה עד הסוף מאיפה השיחה מגיעה. האם היא נכנסת מרשת internal או external (למשל), ובכך גם להתנהג לגמרי שונה ולהיכנס ל context לגמרי שונים (כפי שמוגדר בברירת המחדל).
כך למשל, אפשר להגדיר טלפונים (מכשירי טלפון, להבדיל משלוחות המוגדרות ב directory) ב internal בעוד ש sip trunk (או gateway כשם נוסף) לספקית חיצונית נגדיר ב external. להמשיך לקרוא

Telegram – מימוש קוד פתוח דמוי WhatApp

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

לאחר שfacebook רכשו את Whatsapp, התחלתי לקרוא כתבות על תחליפים עבור תוכנה זו, ותוכנה אחת משכה לי את העין – Telegram.

ישנם מספר דברים שמשכו לי שם את העין:

  • הפרוטוקול מאובטח
  • הפרוטוקול מפורסם בצורה גלויה ופתוחה
  • יש API פתוח ומתועד לשרת
  • יש מימושים שונים לפרוטוקול, כולל כאלו שרצים בלינוקס, ווינדוז ומאק
  • התוכנה לאנדרואיד נמצאת ב github
  • התוכנה מסוגלת לרוץ גם אם אין לך מודם סלולרי, (בניגוד ל whatsapp)
  • אפשר למחוק לצמיתות הודעות, ולא לשמור אותן בשום מקום

וכך מצאתי תחליף נחמד וטוב לתוכנה.

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

בנוסף, בתוכנה חסרים עדיין מספר פיטצ'רים שכמה אנשים שאני מכיר צריכים (הקלטת קול למשל), קצת קשה להעביר אנשים לא טכניים אליה, אבל אני מוצא כי זה הכיוון האמיתי שיש ללכת, אם חייבים ולא להשתמש ב whatsapp.
לפחות לדעתי כמובן.

בכל מקרה, ממליץ לכולם לעבור לתוכנה ולעזוב את פייסבוק במנוחה 🙂

רובי לאן ?

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

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

זו לא שפת התכנות המהירה ביותר (בשביל מהירות ויעילות, אני משתמש ב go), אבל מאוד קל, מהיר ופשוט ליצור בה דברים.
עבורי היא שפה לצד הסיסטם, בה אני יוצר מערכות ניהול שונות, אבל גם מערכות טלפוניה שונות.
עבורי סינטרה הוא מעל ומעבר למה שאני זקוק לו. למעשה לרוב אני מרגיש שיש לו הרבה יותר מה להציע ממה שאני צריך.

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

בשל כך, אני שומע הרבה מאוד אנשים שמספידים את השפה. למעשה אני כל הזמן שומע על חוסר ההפרדה בין רובי לבי Rails, אבל כפי ש Metasploit כתוב בשפה, כך גם עוד הרבה מאוד כלים אחרים (כדוגמת fog, puppet, chef, capistrano ועוד).
כפי שכבר כתבתי בעבר, אפילו אצלי, היא מחליפה כבר מזמן את פרל (שגם את השפה הזו אני מאוד אוהב). אפילו YaST – הכלי הכי מזוהה עם סוזה, שוכתב לרובי.

השפה עצמה לא תעלם כל כך מהר לדעתי, ואני מקווה כי בכלל לא.
היא שפה מאוד קריאה, עם המון כוח, והיא מכריחה אותך לחשוב בתפיסה מסויימת, אבל בניגוד לפיתון למשל, יש יותר מדרך אחת לעשות דברים, ואין את ה"דיקטטור הנאור" שמכתיב לך דרך.
יש הרבה מימושים לרובי, בניהם MRI/CRuby, Rubinius, JRuby   ועוד מספר מימושים שונים של השפה עצמה.

אז רובי לאן ? ובכן אולי Rails תשתנה, ואולי ותעלם, אבל אני מאוד מקווה שלא השפה, כי יש לה המון מה להציע, וזה יהיה הפסד נוראי לעולם.

אנטגוניזם מקצועי

יוצא לי המון פעמים לשמוע תלונות של מפתחי ווב, כמה המקצוע שלהם קשה ומסובך, כי הם צריכים לדעת Javascript, CSS, HTML, DOM, XML ובנוסף יש גם את צד השרת עם שלל הדברים שלו (וזו רק רשימה חלקית ולא מכסה את העולם).

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

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

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

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

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

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

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

מרכזיה או פרוקסי, על רגל אחת

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

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

המרכזיה אשר כולם עובדים איתה, אך שקופה מאוד עבור הרבה נקראת מרכזייה class 4. זו מרכזיה אשר מעבירה תעבורה מצד אחד לצד שני.

מרכזייה סוג 3 (class 3) שהיא בעצם מרכזייה איזורית. וכמובן שזה יורד ככה עד לclass 1.

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

  1. שרת אותות (signals)
  2. שרת מדיה (media)

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

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

שרתי פרוקסי יודעים לנתב ולנתח שיחה, לאפשר או לא לאפשר הרשאות שונות, וכן לבצע חיובים שונים על השיחה. אך הם אינם מצב קצה של השיחה, כי אם מצב אמצע, כדוגמת נתב בתקשורת רגילה. אין לה שלוחות, היא לא מנהלת פעולות קצה של משתמשים, אלא רק יודעת לנתח שיחה על מגוון הדברים שלה, ולהחליט אם להמשיך איתה הלאה, ואם כן לאן, או להפיל אותה לפי הצרכים של השרת (UAS – Userver Agent Server), וכן הצרכים של הלקוח (UAC – User Agent Client).
פרוקסי לרוב מקבל את התאור של B2BUA. כלומר לנתח תעבורה ולהחליט מה קורה איתה, כאילו היה UAS.

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

זה על רגל אחת הנושא בניסיון להסביר את ההבדלים של השניים.

מראה מראה שעל הקיר – planet foss il

הרבה זמן שיש בעיות עם האגריגיטור של planet.foss.org.il. לפעמים הוא למעלה ולפעמים הוא למטה.
אז החלטתי לקום ולעשות מעשה – ליצור אתר מראה עבורו בכתובת: planet.linesip.co.il.

אין לאתר שום רצון להתחרות ב planet.foss.il אלא לשמש מראה שתאפשר עדין לראות בלוגים גם אם האתר אינו מגיב.

הדרך שביצעתי את המראה פעל ב3 שלבים:

  1. הלכתי ל cache האחרון של גוגל והורדתי את קובץ ה index.
  2. מחקתי את כל התוכן של הbody פרט לרשימת החברים בplanet‏
  3. יצרתי סקריפט רובי קצר שיצר את קובץ הini עבור מערכת ה planet

אני מקווה כי זה יעזור לכולנו בעצם לחזור ולקרוא פוסטים מעניינים של אנשי הקהילה.

הבנה של bindaddr באסטריסק

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

Serious Network Trouble; __sip_xmit returns error for pkt data

בד"כ במצב כזה, החשד הוא שמשהו אחר תופס את הפורט, אז הרצתי בדיקה של netstat ואפילו lsof, וכלום, הפורט פנוי.
הרצתי netcat כשרת, והוא הצליח ללא בעיה לבצע bind על הפורט הזה.

הבעיה היא, שהלקוח עובד עם elastix שמבוססת על freepbx, וזו מתערבת בקבצי ההגדרות, ויוצרת עוד קבצי הגדרות חדשים עבורך להוספה, ולא ניתן לשנות קבצי הגדרות ידנית, כי היא דורסת אותם, אלא אם אלו קבצי "‎‎_custom.conf"
לאחר המון שעות מחקר, החלטתי לגשת לקבצים שנוצרים אוטומטית, וגיליתי כי bindaddr הצביע על כתובת IP שאומנם חוקית ברשת של המרכזיה, אבל היא לא שייכת למכונה.

כאן צריך להיכנס ולהבין בעצם את אסטריסק יותר לעומק.
במצב רגיל, כאשר פותחים socket ניתן להגיד לו להאזין לכתובת ip מסויימת, במקום להאזין להכל.
אבל באסטריסק ביצוע bind הוא מעט שונה בתפיסה שלו.
באסטריסק, הכתובת ip היא כתובת שקשורה לניתוב. היא אומרת לאסטריסק מאיפה התקשורת תגיע ולאן היא צריכה ללכת. לא ברמה של כתובת שרת, אלא ברמה של כרטיס רשת. כך שאם כתובת הip אינה שייכת לnetwork device, אסטריסק אינו יכול "להינעל" על אותה כתובת ip, שכן זו בעצם היכולת שלו לבצע bind על כרטיס רשת ולכן הוא אינו יכול להאזין לדברים.

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

עם אותו לקוח, הסתבר כי הוא התקין תוסף ל FreePBX שמאפשר לו בצורה גרפית להגדיר את הכתובת, דבר שמוגדר בקובץ שנוצר אוטומטית, ולי אין יכולת להתערב בתוכן שלו בלי שזה ידרס.
הוא הגדיר את הכתובת החיצונית של הרשת שלו (כאשר הוא מאחורי nat), ולא את כתובת המרכזיה עצמה, וכאשר העברתי את זה ל 0.0.0.0 הבעיה נפתרה לה, לאחר שלוש שעות של מחקר להבין מדוע אסטריסק לא ביצע bind לכתובת.