Reliable Distributed Media Server By Waseem Abo Moch

Reliable Distributed Media Server By: Waseem Abo Moch Henry Shehadi Supervisor: Vladimir Zdornov

תיאור המצגת 1 מבט כללי. 2 דרישות ומטרות הפרויקט 3 סקירת פרוטוקולים 4 מודלים לשרת מבוזר 5 ארכיטקטורה 6 הסבר על FTP 7 אופן תכנון השרת 8 הסבר על Java Rmi 9 - תוכנית VLC והוספת - Plug in 01 סיכום -11 References

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

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

פרוטוקולים להעברת מדיה קיימים מספר פרוטוקולים ל : streaming ◦ ◦ 1 RTP 2 RTSP/RTP כולל בקרה. 3. HTTPs/HTTP 4. MMS 5. FTP 6. RTMP ועוד. . .

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

מודלים לשרת מבוזר ◦ ניתוב לקוחות למקומות שונים דרך ה : Web Page במערכות WEB כמו …, You. Tube מנצלים את העובדה שלקוח מתחבר קודם לשרת ה web ומקבל דף שמכיל את הלינקים לסרטים ולכן בכל פעם הם מכניסים לינקים לסרטים המאוחסנים בשרתים אחרים ובכך מחלקים את העומס בין כל השרתים. איך בנינ וא ◦ ניתוב לקוחות ע"י ת ה השרת : שרת ? חלוקה ברמת השרת עצמו , הוא זה שמפנה את הלקוח לשרת אחר מבלי שה user ירגיש. * אנו השתמשנו בגישה השנייה.

ארכטיקטורה ◦ הלקוח ) (client מנהל את כל השיחה של העברת המדיה כמו התחלת זרימה או עצירה או הזזה ) (seek מול שרת אחד ויחיד וזהו השרת שנקרא לו . manager ◦ ה manager בתורו שולח הוראות לשרתי המשנה לשליחת התוכן של המדיה ללקוח. ◦ תפקידי ה manager הנוספים : 1 אחראי לעקוב אחרי שרתים שנופלים ולהוריד אותם מרשימת שרתי המשנה. -2 מטפל בלקוחות אשר השרת שלהם נופל. ) ניתוב מחדש לשרת עובד (

ארכטיקטורה

ארכטיקטורה ◦ ה client מכיר שרת יחיד בעל כתובת IP יחידה. ◦ לשרת הזה נקרא שרת ראשי. ) (manager/PI-server הנחת הפרויקט ששרת זה לא נופל. ◦ השרת הראשי מנהל שיחת FTP עם ה client דרך ערוץ בקרה, וברגע שמחליטים שצריך להעביר מדיה השרת הראשי מפנה את ה client לשרת משני. ) (slave/DTP-Server

למה ? ? FTP ◦ FTP זהו פרוטוקול להעברת קבצים ) (File Transfer Protocol ולכן זהו פרוטוקול כללי ולא מיוחד להעברת מדיה. ◦ אנחנו השתמשנו בפרוטוקול זה כדי להעביר את המדיה ללקוח וזה בגלל : הפשטות של פרוטוקול התמיכה שלו ב redirection מה שמקל עלינו מימוש מבוזר של השרת כך שה manager יכול להפנות את הלקוחות לשרתים משניים ברגע הצורך להעברת המדיה. ◦ סיבה חשובה נוספת היא שכמעט כל תוכנית client היום של audio/video תומכת בפרוטוקול העברה . FTP

על FTP מפריד בין העברת פקודות לבין העברת . data פקודות עוברות בחיבור TCP שנקרא ). PI (protocol interpreter ה data עובר בחיבור TCP שנקרא ). DTP (Data Transfer Protocol FTP מגדיר פקודות: … , . user, pass, retr, size פקודה חשובה שניצלנו ל redirection היא : pasv הלקוח שולח pasv השרת מחזיר את ה ip והפורט של שרת ה . DTP ולכן כל הפקודות נעביר על ידי חיבור ה PI לשרת הראשי. ◦ ברגע השליחה הלקוח שולח PASV ◦ מקבל את הכתובת של שרת המשנה שממש פרוטוקול ה . DTP ◦ מתחילים העברה משרת זה.

FTP טרנזקציה כללית)שרת רגיל(

מבוזר FTP שרת

תיאור השרת שלנו בנוי מ : שרת ראשי שנקרא לו Manager או - PI Server שרת זה מממש את הפרוטוקול PI של ה . FTP ◦ ה Manager מחזיק רשימה של משתמשים והסיסמאות שלהם ומרשה רק למשתמשים מורשים לקבל שירות. ישנם עוד שרתי משנה DTP Servers אשר מממשים את הפרוטוקול DTP של ה . FTP * אופן הפעולה : ◦ ◦ כאשר לקוח מתחבר ל Manager הוא מחליף איתו commands שמטרתן להזדהות בפני השרת ולקבל אינפורמציה על גדול הקובץ וכו. . . לבסוף הלקוח מחליט לקבל את הקובץ ושולח פקודת . pasv ה Manager מחזיר את כתובתו של שרת המשנה המועדף ) לפי המדיניות שנבחרה( ובכך הלקוח מתחבר לשרת זה ומתחיל לקבל את הקובץ ולנגן אותו . on the fly

עוד על השרת הראשי ◦ השרת הראשי בונה רשימה של שרתי משנה : איך בונים רשימה זו ? בתחילת ריצת השרתים המשניים , הם שולחים לשרת הראשי בקשת הרשמה דרך פרוטוקול שהגדרנו - ). (Registeration Protocol ◦ השרת הראשי מחזיק את כתובתם של השרתים המשניים, ומקבל רפירנס מרוחק של RMI ל DTP factory בכל אחד מהשרתים המשניים. ◦ השרת הראשי בוחר איזה DTP ישרת את הלקוח הבא בתור לפי אחת מהמדיניות הבאות: Fastest Lowest. Load Random

מה זה ? ? Java Rmi הזכרנו קודם כי העברת פקודות הניהול בין השרת הראשי לבין שרתי המשנה היא דרך ) : RMI(Remote Method Invocation אז מה זה ? RMI ◦ זוהי טכנולוגיה מתקדמת ש . Java ◦ מטרתה : לקבל reference לאובייקטים מרוחקים שחיים במכונה מרוחקת דרך interface מוגדר מראש. תוצאה : מהשימוש ב RMI בעצם אין לנו ממש שרתים מרוחקים אלא במקום יש לנו אובייקטים מרוחקים אשר מדמים שרתים מרוחקים. איך אנו משתמשים בטכנולוגיה זו ? ? ◦ כל שרת משנה מריץ שרת אשר מבצע רישום של אובייקט שנקרא Remote. Dtp. Factory שמבוצע בשרת הראשי דרך הפרוטוקול שהגדרנו . Registration protocol ◦ השרת הראשי מקבל רפרנס מרוחק ל Dtp. Factory הזה ושומר זאת ב Dtp. Factory לוקלי אצלו. * ובכך הוא יכול להפעיל מתודות על אובייקט זה. ◦ בכל בקשת חיבור data עם : client השרת הראשי קורא למתודה על ה Remote. Dtp. Factory אשר מייצרת Remote. Dtp ורושמת אותו בשירות ה RMI שמקבל רפירנס אליו ומתחיל להפעיל עליו את המתודות של שליחת הקובץ שנמצאות בצד ה . client

Our Design as an RMI Model

מדיניות בחירת שרת ה DTP ה Manager מחליט לבצע שליחת ה Data דרך אחד מהשרתים המשניים הזמינים לפי אחת משלושת המדיניות הבאות : ◦ הכי מהיר ) : (fastest הוא מבצע קריאת מתודה על השרתים ומודד זמן תגובה של כל אחד ובוחר את הכי מהיר. ◦ הפחות עמוס ) : (lowest load מבצע שאילתה על השרתים לגבי מספר ה DTPs הקיימים בשרת ובוחר את זה בעל המספר הכי נמוך. ◦ רנדומאלית ) : (random בוחר שרת באופן אקראי. המדיניות נקבעת בזמן הרצת ה Manager דרך ארגומנט command line או דרך קובץ הקונפיגורציה . ini

Class Diagram: Manager(Pi-Server)

Class Diagram: Manager(DTP-Server)

Running The Manager(PI Server) אשר מוכלים classes והיא אוסף של RFtp. Server אנו קוראים manager לאפליקציית השרת : ואחד ללינוקס windows , הכנו שני סקריפטים להרצה אחד ל jar בקובץ Start_ftp_server. bat: for windows Start_ftp_server. sh: for linux : – ולראות איזה פרמטרים מקבל השרת h אפשר להריץ עם הארגומנט usage: java Ftp. Server server [--host=<host ip> | --port=<host tcp port> |. . . ] --base_dir <arg> The Base Ftp dir --config <arg> The configuration file path -h, --help Print help and exit --host <arg> The ip or hostname to bind on, default: Any --log_file <arg> The log file path, default: std_error --log_p <arg> The logging priority, default: 3 -m, --man_port <arg> The tcp port for managment, default: 2122 -n, --name <arg> --no_gui -p, --port <arg> --policy <arg> Server name, default: Reliable Ftp. Server 2008 v 1. 0 Disable GUI: enabled The tcp port to bind, default: 21 The Policy of selecting DTPs שניתן דרכו גם לתת את כל הפרמטרים וגם נתונים לגבי איזה ini לשרת גם יש קובץ קונפיגורציה . משתמשים ניתן להכניס למערכת וגם איפה נמצאת התיקייה הראשית של קבצי המדיה

(הרצת שרת משנה Dtp Server) של IP בצורה דומה אפשר להריץ את שרתי המשנה כך שצריך לספק לכל אחד את כתובת ה . ini או דרך קובת קונפיגורציה command line השרת הראשי או דרך ארגומנט : – תיתן h הרצה עם usage: java dtpserver. jar server [--host=<host ip> | --port=<host tcp port> |. . . ] --base_dir <arg> --config <arg> The FTP Base Dir The configuration file path --connectivity_port <arg> The Connectivity port, default: 2124 -h, --help Print help and exit --host <arg> The ip or hostname to bind on, default: Any --log_file <arg> The log file path, default: std_error and dtp_log. txt --log_p <arg> The logging priority, default: 3 -m, --man_port <arg> --master_host <arg> -n, --name <arg> -p, --port <arg> The Master machine tcp port for managment, default: 2122 The ip or hostname of the master machine Server name, default: Smart Ftp Server The tcp port to bind for RMI, default: 2123

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

צד לקוח Client Side הלקוח מצורת עבודתו יודע באיזה נקודת זמן מתחילת השידור קרתה התקלה. תיאורטית : הלקוח יכול לבקש פעם נוספת את אותו קובץ ולספק פקודת ה - FTP REST אשר קובעת לשרת מאזיה בית בקובץ המדיה צריך להתחיל את השידור. היינו חייבים לערב את ה client לבצע זאת מכיוון שמאוד קשה לשחזר חיבור TCP שבור מבלי להתעסק ב network stack של מערכת ההפעלה וזה מצריך המון עבודה. ולכן שינוי קל ב client שאפילו הרבה clients כבר תומכים בפעולה זו והיא : auto-reconnect מכיוון שתמיד ישנם שרתים משניים )ההנחה שיש הרבה שרתים משניים( ולכן בכל רגע שהלקוח מבקש את המדיה שוב נמצא שרת זמין אחר)מזה שנפל( ונתן לו לשלוח ללקוח את המדיה מאותה נקודה. ברגע ששרת נופל ה Manager זורק אותו מרשימת השרתים הזמינים.

צד לקוח VLC Plug-in : Client Side השתמשנו ב VLC בצד הלקוח : ◦ VLC הינה תוכנית אשר משמשת גם כ client וגם כ server לסרטים. ◦ תוכנית זו הינה stand alone אשר לא מחייבת התקנת external codecs והיא מכילה כל codec שאפשר לחשוב עליו. בחרנו לספק plug-in לתוכנית זו מכיוון שהיא נפוצה מאוד וגם כן ניתנת לאינטגרציה בדפי , web אנו משתמשים בה רק כ client ולא משתמשים ביכולות ה streaming שלה. הכנו plug-in עבור גרסת ה windows האחרונה , 0. 9. 8 a אשר הוסיף יכולת . auto-reconnect

VLC Plug-in : Client Side צד לקוח תוספת שלנו

צד לקוח VLC Plug-in : Client Side בחירת Auto. Reconnect גורמת לשרת לנסות וחדש את החיבור עם ה Retry. Count Manager פעמים. אחרי שמנסים מס' זה של ניסיונות ה client קובע שאי אפשר לחדש את החיבור ונותן הודעת שגיאה שהשרת נפל. ◦ הוספנו גם אפשרות לשינוי זמן ההחלטה על חיבור מת, כלומר : אם בוחרים שדה זה להיות 0001 אז אם ה Client לא מקבל מידע בחיבור ה DTP במשך שנייה ) (1000 msec אזי מחליטים ששרת ה DTP נפל וצריך חיבור חדש בתנאי : שהאופציה Auto. Reconnect פעילה ולא נגמרו הניסיונות.

דוגמא להרצה Secondary Server(Dtp Server) Manager (Pi Server) VLC Client-Include Our plug-in

סיכום - מה למדנו הרבה דברים מהפרויקט הזה: ◦ -1 הבנת פרוטוקולי רשת והעברת מדיה כגון : . FTP, RTSP, RTP ◦ -2 תכן ותכנות מערכת מבוזרת. ◦ -3 התנסות טובה בשפת . Java ◦ -4 שימוש בטכנולוגיה מתקדמת . Java Rmi ◦ -5 הוספת plug-in לאפליקציה קיימת . VLC ◦ -6 בניית מערכת תוכנה עמידה בפני תקלות כגון נפילות רשת או נפילת שרת והתאוששות.

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

References FTP: RFC 959 http: //www. faqs. org/rfcs/rfc 959. html Java Tutorialhttp: //java. sun. com/docs/books/tutorial Java RMIhttp: //java. sun. com/docs/books/tutorial/rmi /index. html VLC-http: //www. videolan. org/

תודה רבה היה נעים ? ? ? Any Questions