Client-Server Architecture - חלק 1
פרקי ההרצאה: Client-Server Architecture - חלק 1
תמלול ההרצאה: Client-Server Architecture - חלק 1
הטקסט המלא של הדקות הראשונות בהרצאה «Client-Server Architecture - חלק 1» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
אחרי שראינו את הנפשות הפועלות בתחום ה-TCPIP מבחינת פיתוח התוכנה וראינו אילו רכיבים תכנותיים יש לנו לצורך ביצוע תקשורת נתונים ב-TCPIP אנחנו יכולים עכשיו לגשת ולראות Client Server Architecture כלומר ארכיטקטורה נכונה לבנייה של מערכת שבה יש שרת אחד שמשרת הרבה לקוחות כי הדוגמה שעשינו בסרטון הקודם בעצם הראתה
לנו איך אנחנו עושים תקשורת הכי פשוטה בעולם שבתקשורת הזאת אנחנו מרימים איזשהו מחשב שהוא סרבר, איזשהו מחשב אחד ויחיד שהוא קליינט, שניהם מתקשרים אחד עם השני, נניח הסרבר שולח משהו לקליינט והקליינט שולח משהו לסרבר ופה סיימנו את הדוגמה והסיבה שעשינו אותה זה רק בכדי לראות אילו רכיבים קיימים, איך אנחנו עובדים איתם אבל מה שלא ראינו זה איך אנחנו
משלבים את העבודה איתם לצורך יצירת מערכת שלמה שעובדת כמו שצריך אם טרדים ואם לא להיתקע ואם לשרת הרבה לקוחות ואיזושהי לוגיקה שקיימת בתוך המערכת.
כמובן אנחנו הולכים להשתמש עם הכלים שלמדנו. אז קודם כל בהדגמה הזאת אנחנו הולכים לראות איך נכון לייצר את המערכת הזאת מבחינת design pattern ונתחיל עם שלבים שלבים ואז נבהיר כל דבר שיש כאן.
קודם כל במערכת כזאת כמובן שיש לנו סרוור, כאן זה בעצם איזשהו שרת אחד כרגע, יש לו, והוא נמצא על איזשהו מחשב איפשהו בעולם והוא מיועד לשרת הרבה לקוחות.
מבחינת הלקוחות אין לנו לקוח אחד, אנחנו רוצים כמה קליינטס ולכן בלקוחות יש הרבה לקוחות. בסרוור צריך להיות לנו איזשהו רכיב שמנהל את הכל, איזושהי מחלקה שאנחנו צריכים לבנות, אולי הטופס הראשי, אולי איזו מחלקה נפרדת, בדרך כלל עדיף שזאת תהיה מחלקה נפרדת, שמתחילה את כל התהליך.
פה בסרטוט הזה קראתי לה מנג'ר. בסרבר צריך להיות לנו איזשהו קולקשן שיצליח להחזיק את כל הלקוחות ולנהל את כל הלקוחות. אנחנו כבר הולכים לראות מה בדיוק אנחנו הולכים להכניס בתוך הקולקשן הזה, אבל בגלל שהסרבר צריך לשרת הרבה לקוחות, אנחנו צריכים להכניס אותם לאיזשהו אוסף בשביל שנוכל להכיל את כולם בבת אחת.
עכשיו בואו נעבור לצד של הקליינט. בצד של הקליינט קיים איזשהו בן אדם איפשהו בעולם, בואו נניח הבן אדם הזה, השרת נניח נמצא בארצות הברית, והבן אדם הזה בישראל.
אחלה. איזשהו בן אדם שנכנס ורוצה לגלוש לתוכנה. מה הוא עושה? מרים איזשהו, מריץ את התוכנה, נפתח לו נניח איזשהו טופס שאיתו הוא יתחיל, אמור להתחיל לעבוד עם השרת מה אנחנו רוצים לעשות אנחנו רוצים בדיוק במקום הזה כשהוא רוצה להתחיל לעבוד עם השרת שלנו אנחנו רוצים להשתמש ברכיבים שהיו בהדגמה הקודמת ובצד של הקליינט הרי יש לנו tcp קליינט
שצריך ליזום את התקשורת עם השרת אז מה שנכון לעשות בארכיטקטורה כזאת זה לא לשלב את כל הפרמטרים בתוך הטופס, לא לעשות את כל המערכת שמתקשרת עם השרת באזור של היוזר אינטרפייס אלא אנחנו רוצים להוציא אותה לרכיב חיצוני.
אז מה יש לנו כאן מבחינת תקשורת נתונים? אנחנו יודעים שמבחינת תקשורת נתונים אנחנו צריכים שיהיה לנו איזה שהוא סוקט, אנחנו יודעים שצריך להיות לנו איזה שהוא נטוורק סטרים, אנחנו יודעים שאנחנו צריכים פורמטר, אנחנו צריכים אפשרות לשלוח מידע, אפשרות להאזין, איזה שהוא טרד שמאזין.
כל הדברים האלה אנחנו רוצים שיהיה לנו גם בקליינט וגם בסרבר עבור אותו לקוח. לכן מה שאנחנו עושים, אנחנו מוציאים אותם לרכיב נפרד.
הרכיב הזה זה סך הכל איזושהי מחלקה, ובואו נקרא לה קום, קיצור של קומיוניקייטור. המחלקה הזאתי יודעת לתקשר עם הצד השני של העולם. אוקיי, אז הטופס, כל מה שהוא צריך לעשות זה ליצור אובייקט מהקומיוניקייטור.
מה שיהיה בתוך הקומיוניקייטור זה בעצם הדברים שיהיו משותפים גם לקליינט וגם לסרבר מבחינת תקשורת הנתונים.
לדוגמה, מה שיהיה בקומיוניקייטור זה הסוקט, כי גם בקליינט וגם בסרבר אני צריך שיהיה לי סוקט. והנטוורק סטרים והפורמטר ואפשרות לשליחה ולהאזנה וטרד שמאזין כל הדברים המשותפים האלה אני צריך אותם גם בצד של הקליינט וגם בצד של הסרוור לכן יש לנו פה איזושהי מחלקה נפרדת והטופס יוצר אובייקט
מהמחלקה הנפרדת הזאת איך שהטופס יוצר את האובייקט ואמר לו בוא תתחבר בבקשה לסרוור מה אנחנו זוכרים שהיה בצד של הסרוור בצד של הסרוור קיבלנו את הסוקט עבור אותו קליינט, קליינט אחד ויחיד גורם לסרבר לייצר סוקט אחד ויחיד שמסוגל לתקשר אך ורק עם אותו הקליינט.
אם אתם זוכרים אמרנו שסוקט זה נקודת קצה רק לנקודה אחת, לא יותר מזה. אוקיי, אז אם בסרבר יש לנו גם כן סוקט וכמובן אנחנו נצטרך שם גם נטוורק סטרים ובינארי פורמטר וטרד שמאזין ואפשרות לשליחה ואפשרות לקבלה אז ניחשתם נכון אנחנו צריכים גם את הקומיוניקטור
בצד של הסרבר וזה בדיוק מה שאנחנו הולכים להכניס לקולקשן. הקולקשן הזה אמור להיות קולקשן כזה שיכיל קומיוניקטורים כל קליינט ברגע שהקומיוניקטור שלו עולה לאוויר הוא מתחבר עם הסרבר ואנחנו מייצרים לו קומוניקטור שקיים בסרבר שיודע לתקשר אך ורק
איתו ולא עם אף לקוח אחר. תכף אנחנו נראה איך עוד לקוחות משתלבים פה. זה אומר שאיך שהקומוניקטור שבצד של הסרבר עלה, המנג'ר כמובן הולך לדאוג לזה ולהעלות אותו, ליצור אותו כאובייקט ולצרף אותו לקולקשן, אוטומטית נפתח לנו קו תקשורת בין שני הקומוניקטורים, מפני שראינו שסוקט בעצם מתחבר עם סוקט אחר והנטוורק סטרימפס שביניהם מסוגלים לתקשר.
אז יש לנו עכשיו לקוח אחד שמחובר לשרת ובשרת יש אובייקט קומוניקטור שמחובר רק לאותו לקוח. עכשיו, אמרנו השרת נמצא בארצות הברית, הלקוח הראשון שראינו נמצא בישראל, אין בעיה.
בא לקוח שני מאיטליה, יכול להיות בכל מקום בעולם. הוא מאיטליה גם הוא נכנס לתוכנה ופותח טופס אנחנו עושים בדיוק אותו דבר הרי אין הבדל בתוכנות של הלקוחות לכל אחד יש את התוכנה שלו אבל היא תוכנה זהה פשוט היא נמצאת על מחשבים שונים אם הוא פותח טופס אנחנו עושים אותו הדבר ופותחים גם לו קומוניקטור ברגע שפתחנו קומוניקטור ויזמנו
תקשורת עם השרת השרת אוטומטית מקבל סוקט ויכול לפתוח את הקומוניקטור ששייך ללקוח השני ושימו לב שזה אובייקט נפרד לגמרי מהקומוניקטור הראשון שנפתח אפילו ששניהם נמצאים בצד של השרת.
כאן יש קו תקשורת בין שני הקומוניקטורים השניים, לא קשורים לקו תקשורת של הקומוניקטורים הראשונים. עכשיו, לשרת יש גישה לשני לקוחות.
אוקיי, זה היה מאיטליה. בא עוד לקוח מספרד, אין שום בעיה, פותח את הטופס שלנו, מיידית אנחנו מייצרים לו Object Communicator, מיידית אנחנו יוזמים בקשת התחברות לשרת, השרת מקבל את הסוקט, פותח קומוניקטור שלישי, מצרף אותו לקולקשן
ויש לנו קו תקשורת גם איתו. עד כאן זה הארכיטקטורה עצמה איך נכון להרים את כל המערכת. מכאן באה הלוגיקה שלכם וכל מערכת יש לה לוגיקה אחרת.
מה אתם רוצים לבנות? האם אתם רוצים לבנות איזשהו משחק שבו הלקוח הראשון, נניח ההוא מישראל, ושולח איזה חידה והחידה מגיעה רק ללקוח אחד רנדומלי שצריך לפתור אותה ולהחזיר לו תשובה דרך הסרבר?
האם אתם רוצים שתהיה לכם איזושהי תוכנה נניח שמנהלת קבצים כמו לדוגמה דרופבוקס וכל לקוח הוא מתקשר רק עם השרת בפני עצמו ולא קשור ללקוחות אחרים?
האם אתם רוצים שלקוח ישלח הודעה לדוגמה כמו צ'אט וההודעה תחזור לכל הלקוחות? זה כבר הלוגיקה שלכם. מה בדיוק קיים בפרויקט שלכם? אתם צריכים לבנות את הלוגיקה הזאת לפי מה שנכון לכם.
אז בואו בסרטוט הזה ניקח דוגמה הכי פשוטה, שבה אנחנו רוצים לבנות מערכת של צ'אט. מערכת של צ'אט אומרת, בלי חדרים, בלי תקשורת אישית, הצ'אט הכי פשוט שיכול להיות, שלקוח שולח הודעה, ההודעה צריכה להגיע לכל הלקוחות, כולל ללקוח ששלח אותה.
אוקיי, אז אם הלקוח מישראל בא ושולח את ההודעה, מה אנחנו רוצים לעשות? אנחנו רוצים שההודעה תגיע לאזור של השרת, ואנחנו רוצים שאיכשהו ההודעה הזאת תצליח להישלח לכל הלקוחות, כמובן כולל הלקוח ששלח את ההודעה, כי גם אליו אנחנו רוצים שההודעה תחזור ותוצג.
ככה הוא לדוגמה יודע שעדיין הקו תקשורת פעיל לדוגמה. אז בואו נראה. הלקוח הראשון מישראל כותב את המילה לוחץ הלחצן שלח והמילה Hello צריכה להגיע לקומיוניקטור.
כאן אני שנייה נכנס טיפה לקוד טכני. אם הטופס הרים את האובייקט של הקומיוניקטור, זאת אומרת שהטופס עצמו יצר אובייקט קומיוניקטור, אז הטופס מכיר את האובייקט קומיוניקטור.
לכן האובייקט קומיוניקטור והמחלקה קומיוניקטור לא מכירה את האובייקט של הטופס, תכף נדבר על זה. אבל אם הטופס יצר את האובייקט, הרים אותו לאוויר, אז הוא כמובן מכיר אותו, אז כל מה שהוא צריך לעשות בשביל לשלוח מידע זה לקרוא לפונקציה, לדוגמה פונקציית send.
קורא לה, שולח את המידע, אחלה. מה הקומיוניקטור עושה? פורמטר. נקודה סריאלייז. שולח את המחרוזת הזאת לצד השני.
בצד השני הקומיוניקטור השני מאזין מאזין מאזין, אופה, קיבל את המחרוזת על ידי דה סריאלייז. אם הוא קיבל אותה הוא צריך להעביר אותה מכאן למנאג'ר.
למה למנאג'ר? מפני שהמנאג'ר הוא זה שמכיר את הקולקשן ואת כל הקומוניקטורים בתוך הקולקשן. לכן הוא חייב להעביר את המחרוזת שהוא קיבל למנאג'ר.
אוקיי, אבל כאן אנחנו נתקלים בבעיה שדיברנו עליה. מקודם, הקומיניקייטור לא מכיר את המנג'ר בדיוק כמו שהקומיניקייטור לא מכיר את הטופס כי המנג'ר יצר את אובייקט הקומיניקייטור.
לכן המנג'ר מכיר אותו, הקומיניקייטור לא מכיר את המנג'ר. איך אנחנו בפיתוח תוכנה מעבירים מידע למחלקה או לאזור שיצר אותנו או שמשתמש איתנו אם אנחנו לא מכירים אותו?
אז אנחנו עושים את זה על ידי אירועים. ולכן חייב להיות לנו פה איזשהו איבנט שברגע שהקומיניקטור קיבל הודעה מהצד השני של העולם הוא פשוט מעלה אותה באיבנט למי שיצר אותו.
ומי שיצר אותו צריך פשוט להאזין לאיבנט ולקבל את האיבנט. אוקיי, אז המנאג'ר קיבל עכשיו את ההודעה ומה המנאג'ר רוצה לעשות?
אז אם אנחנו מתעסקים עם צ'אט פשוט אז המנאג'ר צריך עכשיו לשלוח את אותה הודעה לכל האובייקטים בקולקשן.
זה אומר שהמנאג'ר צריך לרוץ באיזושהי לולאה, לגשת לכל קומוניקטור ועל ידי פונקציית send לשלוח את המידע כי המנאג'ר מכיר את הקומוניקטור. אז פה יש לנו סוויץ' כזה והקומוניקטור פשוט לוקח את אותה הודעת הלו שכרגע הגיעה אליו ושולח את זה לכל אחד מהקומוניקטורים.
הקומוניקטורים עכשיו בצד של הסרבר קיבלו הודעה לשלוח, מבצעים סריאלייז להודעה, הופה, ההודעה נשלחת לצד השני וכל לקוח מבצע עבורה דה סריאלייז.
עכשיו, קומוניקטור שנמצא אצל לקוח קיבל הודעה, הוא רוצה להעביר אותה לטופס, כמובן שגם כאן הוא חייב להשתמש באיבנט להעלות אותה, הטופס מקשיב לאיבנט, קיבל את ההודעה ומציג על עצמו ואז אנחנו יכולים לראות איך לקוח אחד מישראל לדוגמה שלח את ההודעה היא הגיעה לארצות הברית לשרת
שרת לקח את ההודעה שלח אותה לכל הלקוחות כולל הלקוח עצמו וההודעה הגיעה לכל הלקוחות שמחוברים כרגע גם להוא בישראל גם להוא באיטליה גם להוא בספרד והטפסים עשו מה שהם רוצים לדוגמה הציגו את ההודעה מציגים אותה בליסטווקס או איפה שאתם רוצים
אז בעצם כאן ראינו את כל המנגנון או הארכיטקטורה של קליינטס, הרבה לקוחות וסרבר אחד, איך כל קליינט מחובר בעזרת איזשהו קו תקשורת או קומוניקטור רק לאובייקט אחד ויחיד בסרבר, אבל בסרבר יש קולקשן של אובייקטים כאלה, ומכאן הלוגיקה שלכם יכולה לקבל מידע מהלקוחות ולעשות עם המידע מה שאתם רוצים,
אם אתם רוצים, אתם מחזירים להם, שומרים את זה בדאטאבייס, עושים חישובים, עושים תקשורת בין חלק מהלקוחות או כל הלקוחות, זה כבר הלוגיקה האישית של הפרויקט שלכם.
אז מה שאנחנו הולכים לעשות זה פשוט להרים את כל המערכת הזאת מאפס, כאשר אנחנו הולכים לעשות בדיוק את מה שראינו בפרזנטציה הזאת. איזשהו צ'אט פשוט שלקוח אחד שולח את ההודעה לשרת, מחזיר את ההודעה הזאתי לכל הלקוחות המחוברים כולל הלקוח ששלח את ההודעה וכולם מוסיפים את ההודעה הזאת לאיזשהו ליסט וככה כל הלקוחות יכולים לתקשר עם כולם.
אז בואו נראה איך ניתן להרים את כל המערכת הזאת בהתאם לכלים שלמדנו. דבר ראשון פתחתי פה סולושן ריק מפני שהולך להיות לנו פה כמה פרויקטים וקראתי לו צ'אט. הדבר הראשון שאנחנו רוצים לצרף אליו זה בעצם את אותו רכיב משותף שאנחנו רוצים להשתמש עם הרכיב הזה גם בקליינט וגם בסרוור וזה היה קומוניקטור.
בגלל שאנחנו רוצים את אותה מחלקה בדיוק להשתמש איתה גם בפרויקט הקליינט וגם בפרויקט הפרוור, איזה פרויקט היא צריכה להיות?
קלאסט ליבררי. קלאסט ליבררי בכדי שהיא תהיה משותפת לשניהם ולא נצטרך לחזור על קוד או להעתיק קופי פייסט מחלקות.
אז בואו נקרא ל-DLL הזה Communicator Library, נבצע פה אוקיי, ואנחנו בעצם מצרפים DLL אחד ל-Solution. והדבר הראשון שאנחנו תמיד עושים כשאנחנו מצרפים DLL זה משנים את ה-Namespace.
בואו נקרא ל-Namespace הזה Chat, מפני שאנחנו רוצים שיהיה לנו Namespace אחד ויחיד עבור כל המערכת שלנו. נקרא לו Chat. אוקיי, יש לנו פה איזושהי מחלקה ואנחנו רוצים לעשות בדיוק את מה שהיה בסרטוט נקרא לה com, נשנה את השם של המחלקה ל-com, שימו לב שהיא public בכדי שנוכל להשתמש איתה
מחוץ ל-dll. יופי, מה אנחנו רוצים במחלקה הזאת? המחלקה הזאת הייתה אמורה להיות הרכיב של הקומוניקטור שמתקשר.
אז מה אנחנו צריכים שיהיה לנו? אז אנחנו צריכים מספר דברים שראינו שהם משותפים גם לסרבר וגם לקליינט ואנחנו הולכים לבנות אותם כ-data members.
יש לנו פה את אובייקט ה-socket, יש לנו את אובייקט ה-network stream, יש לנו את אובייקט ה-formatter, יש לנו כאן איזשהו טרד שאנחנו נצטרך לצורך האזנה להודעות, מפני שאם אתם זוכרים, האזנה זה blocking operation, פקודה דה סריאלייז פשוט תאזין לסטרים ולסוקט ותיתקע עד שמישהו לא ישלח לי מהצד השני מידע ובגלל שזאתי פקודת
בלוקינג אופריישן אני חייב בשביל לשחרר את התוכנית להאזין עליה בתרד נפרד. אז בואו ניקח פה תרד נקרא לו listening thread ואני רק מכין את הקרקע ודבר נוסף שאנחנו נצטרך זה את הקונספט של בואו קודם כל נסגור את התרד וניקח כאן איזשהו משתנה, נקרא לו Keep Listening בכדי שנוכל לרוץ עליו
וניקח אירוע. אם אנחנו רוצים אירוע, אנחנו רוצים אירוע שידווח את המידע שהתקבל. בוא נניח שאנחנו מתעסקים עם צ'אט פשוט, אנחנו לא רוצים לשלוח כל מיני אובייקטים מורכבים, אז נשלח סטרינג, פשוט נעשה צ'אט שמיוחד להודעות סטרינג.
לכן אם אני רוצה אירוע שידווח סטרינג אנחנו צריכים לגשת ולבנות מחלקת event args עבור סטרינג אז בואו נצרף פה קלאס ונקרא לקלאס הזאת message event args כמו שאתם רואים זה בעצם הדגמה שהיא כוללת בתוכה המון מרכיבים שנלמדו במהלך הקורס הזה וגם במהלך קורסים ישנים יותר כמו קורס object oriented לדוגמה המחלקה כמובן חייבת להיות public היא יורשת את
event args נגדיר פה public read only כאן יש לנו string message מה ההודעה שאנחנו רוצים להעביר זה המסג' שלנו ניקח פה איזשהו קונסטרקטור שמקבל מסג' ופשוט נכניס את המסג' לדאטה ממבר מסג' ופה סיימנו לבנות את ה-event args כמחלקה נפרדת אפשר לסגור את הקובץ הזה ולחזור לכאן ולבנות את האירוע האירוע שלנו הוא public event handler מסוג
message event args נקרא לו got message כי ברגע שיתקבל הודעה מהצד השני של העולם אנחנו רוצים להעלות את ההודעה הזאת באירוע ולציין תקשיבו קיבלנו הודעה קחו את המידע קחו את הודעה תעשו איתה מה שאתם רוצים אוקיי בואו ניקח כאן איזה שהוא ניקח כאן איזה שהיא פונקציית קונקט public void
קונקט ואולי ניקח גם איזה שהוא ציטור שיהתחל לנו את הפורמטר אני חושב איתכם תוך כדי שאני בונה את זה new binary formatter keep listening יהיה true האמת שזה יותר הגיוני שזה יהיה בקונקט ובואו נחשוב מה אנחנו רוצים לעשות קונקט בשביל לבצע התחברות לצד השני אתם צריכים להביא לי סוקט הנה סוקט וברגע שאתם
מביאים לי את הסוקט לצד השני אני מסוגל לבצע התחברות עכשיו תוך כדי זה שאני כותב אני פתאום רואה שאפשר לעשות קונקט אבל אולי כדאי פשוט להגיד דבר כזה אם מישהו יוצר אובייקט של הקומוניקטור זה לא הגיוני שיהיה לנו איזשהו אובייקט בלי בכלל סוקט כי מה בדיוק המשמעות של לפתוח אובייקט קומוניקטור בלי שהוא
באמת יודע לאן להתחבר ורק אחר כך לעשות קונקט כלומר אנחנו נותנים פה פרצה ליצירת אובייקט בלי לקרוא לקונקט לכן בואו טיפה נעשה פה איזשהו שינוי נגדיר את הפונקציה הזאת במקום פונקציית קונקט, פשוט נגיד הקונסטרקטור צריך לקבל את הסוקט ואז אנחנו יודעים שהביאו לנו סוקט מסוים שמצביע על הצד השני של העולם
ואנחנו יכולים לבצע קו תקשורת איתו. כל מה שאנחנו צריכים לעשות, סוקט שווה סוקט, מכניסים אותו לדאטה ממבר, אפשר עכשיו לפתוח את הנטוורק סטרים על הסוקט הזה, פורמטר כבר בנינו, אפשר לבוא ל-Listening Thread ולהצביע על איזושהי פונקציה
Listen to Messages, אנחנו כבר הולכים לבנות אותה. ה-Listen Thread הגיוני שהוא יהיה Background,