1 / 33

Reliable Distributed Media Server

Reliable Distributed Media Server. By: Waseem Abo Moch Henry Shehadi Supervisor: Vladimir Zdornov. תיאור המצגת. 1- מבט כללי. 2- דרישות ומטרות הפרויקט 3- סקירת פרוטוקולים 4- מודלים לשרת מבוזר 5- ארכיטקטורה 6- הסבר על FTP 7- אופן תכנון השרת 8- הסבר על Java Rmi

niesha
Download Presentation

Reliable Distributed Media Server

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

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

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

  9. ארכטיקטורה

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

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

  12. 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 . • מתחילים העברה משרת זה.

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

  14. שרת FTP מבוזר

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

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

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

  18. Our Design as an RMI Model

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

  20. Class Diagram: Manager(Pi-Server)

  21. Class Diagram: Manager(DTP-Server)

  22. Running The Manager(PI Server) • לאפליקציית השרת manager אנו קוראים RFtpServer והיא אוסף של classes אשר מוכלים בקובץ jar , הכנו שני סקריפטים להרצה אחד ל windows ואחד ללינוקס: • Start_ftp_server.bat: for windows • Start_ftp_server.sh: for linux • אפשר להריץ עם הארגומנט –h ולראות איזה פרמטרים מקבל השרת: usage: java FtpServer 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> Server name, default: Reliable FtpServer 2008 v1.0 --no_gui Disable GUI: enabled -p,--port <arg> The tcp port to bind, default: 21 --policy <arg> The Policy of selecting DTPs • לשרת גם יש קובץ קונפיגורציה ini שניתן דרכו גם לתת את כל הפרמטרים וגם נתונים לגבי איזה משתמשים ניתן להכניס למערכת וגם איפה נמצאת התיקייה הראשית של קבצי המדיה.

  23. הרצת שרת משנה (Dtp Server) • בצורה דומה אפשר להריץ את שרתי המשנה כך שצריך לספק לכל אחד את כתובת ה IP של השרת הראשי או דרך ארגומנט command line או דרך קובת קונפיגורציה ini . • הרצה עם –h תיתן: usage: java dtpserver.jar server [--host=<host ip> | --port=<host tcp port> | ...] --base_dir <arg> The FTP Base Dir --config <arg> 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> The Master machine tcp port for managment, default: 2122 --master_host <arg> The ip or hostname of the master machine -n,--name <arg> Server name, default: Smart Ftp Server -p,--port <arg> The tcp port to bind for RMI, default: 2123

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

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

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

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

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

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

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

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

  32. References • FTP: RFC959- http://www.faqs.org/rfcs/rfc959.html • Java Tutorial-http://java.sun.com/docs/books/tutorial • Java RMI-http://java.sun.com/docs/books/tutorial/rmi/index.html • VLC-http://www.videolan.org/

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

More Related