anti patterns של מתודולוגיות עבודה


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

הקדמה

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

הדגמות

להמשיך לקרוא

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

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


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

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

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

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

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

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

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

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

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

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

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

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

Firebird וליברה אופיס


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

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

ביולי 2013, פרסמתי כי Base מקבל תמיכה בFirebird כחלק מפרוייקט SOC.

החל מגרסה 4.2, במידה ומפעילים תמיכה ביכולות נסיוניות, ניתן לקבל תמיכה בFirebird כמסד נתונים embedded עבור Base.
libreoffice base firebird בשביל לקבל תמיכה בדברים ניסיוניים בליברה, פשוט הולכים בתפריט ל Tools משם ל LibreOffice, משם ל Advanced ולוחצים על Enable experimental features.

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

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

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

פורסם בקטגוריה firebird, Office, Open/Libre Office, טכנולוגיה, מסדי נתונים, קוד פתוח, שולחן עבודה, תוכנה | השארת תגובה

Sequel וPostgreSQL


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

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

ישנם שני דרכים לטעון תוספים:

  1. דרך גלובלית
  2. דרך שתופעל רק על החיבור שלנו

הדרך הגלובלית נראת כך:

Sequel.extension(:core_extensions, :pg_range, :pg_array)

הדרך של החיבור, נראת כך:

DB.extension(:pg_range, :pg_array)

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

DB[:readers].where(Sequel.pg_range(:comments_id).contains([10, 15, 1900])).sql
# SELECT * FROM "readers" WHERE ("comments_id" @> (10, 15, 1900))

והנה יש לנו שאילתא אשר משתמשת ב Range של Pg, אבל כתובה עם ORM.
בתעוד כתוב שגם שם השדה יכול להיות המקור של pg_range (למשל), אבל אצלי זה לא כך (גם אם זה גלובלי).

למערכים, הפעולה מאוד דומה גם כן:

DB[:comments].where(uid: 10).where(Sequel.pg_array_op(:comments).contains(Sequel.pg_array([15,23]))).sql
# SELECT * FROM "comments" WHERE (("id" = 1) AND ("comments" @> ARRAY[15,23]))

קריאה נוספת:

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

הגדרת 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. להמשיך לקרוא

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

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


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

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

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

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

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

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

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

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

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

רובי לאן ?


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

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

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

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

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

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

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

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

הסכנות בשימוש md5 כסיסמה


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

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

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

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

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

במידה אתם מעוניינים לבצע שמירה של סיסמאות, ישנם כ3 אלגוריתמים מומלצים כיום:

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

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

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


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

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

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

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

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

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

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

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

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

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


פוסט זה הוא שכתוב רביעי של הנושא, בתקווה שהוא יהיה ברור לאנשים טכניים לא מעולם ה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.

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

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

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