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), היות ולי אישית כבר יש מימושים בנושא.

פורסם בקטגוריה firefox, google, Opera, אינטרנט, אירגונים וחברות, אתרי אינטרנט, טכנולוגיה, טלפוניה, כלכלה, פיתוח, קהילה, קוד פתוח, תוכנה, תכנות, תקנים, תקשורת | השארת תגובה

גו – השלמתה של שפה

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

למשל יכול להיות שרת ג'ינטו מ 2007 (שלא התעדכנה) ומערכת פדורה 20, שהמערכת צריכה לרוץ על שניהם.

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

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

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

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

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

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

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

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

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

פורסם בקטגוריה go, Ruby, טכנולוגיה, פיתוח, קוד פתוח, תוכנה, תכנות | השארת תגובה

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

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

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

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

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

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

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

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

G711

להמשיך לקרוא

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

הפילוסופיה של הקוד

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

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

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

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

כל זה נעשה בשפה העברית.

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

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

ענב הזעם – API

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

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

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

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

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

פורסם בקטגוריה Ruby, אינטרנט, טיפים וטריקים, טכנולוגיה, פיתוח, קוד פתוח, תוכנה, תכנות, תקשורת | 6 תגובות

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

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

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

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

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

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

פוסט למחשבה.

פורסם בקטגוריה facebook, אינטרנט, אתרי אינטרנט, חברה, חוק, טכנולוגיה, קהילה, קוד פתוח, תקשורת | 2 תגובות

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

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

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

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

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

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

טיפים על עבודה ב 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 מאפשר לנו גם לבצע הגדרות מדוייקות לשרתים שונים. למשל: להמשיך לקרוא

פורסם בקטגוריה Operating Systems, unix, טיפים וטריקים, לינוקס, קוד פתוח, תוכנה, תקשורת | 2 תגובות

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

אחד מהשותפים העסקיים שלי התקשר אלי וסיפר לי כי יש לו בעיות מאוד מוזרות בשרתים שלו – לפעמים משום מקום, דווקא כשאין הרבה תעבורה יחסית, האפצ'י שלו מפסיק להגיב, בצורה רנדומאלית, שמאוד קשה לתפוס אותה ולהבין מה קורה. הוא היה בטוח שהבעיה היא בפתיחת 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 ועכשיו אפצ'י חייב לחכות ללחיצת היד כמו שצריך לפני שיוכל לנתח את מה שנשלח.

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

 

פורסם בקטגוריה Operating Systems, unix, אינטרנט, אתרי אינטרנט, טיפים וטריקים, טכנולוגיה, לינוקס, קוד פתוח, תוכנה, תקשורת | השארת תגובה

עוד מערכת לדיווח על אזעקות

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

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

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

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

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

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

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

 

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

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