הכרת המחלקות
בכדי שנוכל לכתוב תוכנה המבצעת תקשורת באמצעות פרוטוקול ה-TCP, עלינו להכיר את המחלקות בהן נשתמש. חברת מיקרוסופט בנתה שתי מחלקות אשר יקלו עלינו ביצירת תקשורת באמצעות פרוטוקול זה: TCPClient ו-TCPListener.
TCPListener – מחלקה זו מתארת מחשב מארח (שרת). כפי שצוין, בפרוטוקול ה-TCP חייבת להיווצר קישוריות מסויימת טרם נתחיל לתקשר, וקישוריות זו נוצרת כאשר המחשב המארח מקבל את הלקוח. אנו נעשה שימוש במחלקה זו באופן הבא:
- נאזין ללקוחות אשר מעוניינים להתחבר באמצעות פתיחת פורט מסויים.
- ברגע שלקוח מעוניין להתחבר, נאשר אותו ונשמור את אובייקט הלקוח שלו. אובייקט זה מאפשר לנו להאזין ולשלוח הודעות לאותו הלקוח.
- כאשר אנו רוצים לסגור את השרת, עלינו לסגור את הסוקט.
TCPClient – מחלקה זו מתארת לקוח. הלקוח מתחבר למחשב מארח (שרת) באמצעות אותו הפורט בו המחשב המארח משתמש. על הלקוח לדעת גם את כתובת ה-IP של אותו המחשב – או במילים אחרות, מה הסוקט של המחשב המרוחק. נעשה שימוש במחלקה באופן הבא:
- נתחבר למחשב המרוחק באמצעות כתובת ה-IP והפורט שלו.
- אם ההתחברות הצליחה, נוכל לשלוח ולקבל הודעות מן השרת. אם ההתחברות נכשלה, עלינו להחליט מה לעשות כעת (להציג הודעה למשתמש, לנסות להתחבר שוב וכדומה).
- בסיום השיחה (אם ההתחברות הצליחה) נסגור את הסוקט.
NetworkStream – מחלקה זו מתארת זרם של בייטים. כאשר אנו אומרים זרם של בייטים אנו מתכוונים למערך של בייטים מסודר המתאר מידע שנשלח או מתקבל. המידע אינו בהכרח מתאר חבילת מידע אחת שנשלחה – אלא יכול לתאר מספר חבילות שנשלחו. לדוגמה: כאשר השרת שולח אלינו חבילות מידע במהירות הלקוח לא יקבל כל חבילה בנפרד – החבילות יגיע ביחד על אותו הזרם. במצב כזה אנו מקבלים מערך של בייטים המתאר מספר חבילות מידע. עלינו לדעת כיצד נוכל לזהות היכן חבילה מתחילה והיכן היא מסתיימת. בכדי לעשות זאת עלינו לחשוב על הדרך בה נתאר חבילה.
להלן דוגמה לזרם המכיל מספר חבילות מידע:
125 | 255 | 0 | 169 | 210 | 5 | 1 | 33 | 95 | 20 | 50
כיצד נוכל לדעת איפה כל חבילה מתחילה ומסתיימת? לא נוכל לדעת. עלינו לתאר איך חבילה נראת בכדי שכל צד ידע כיצד לקרוא אותה. לכן עלינו ליצור פרוטוקול (מוסכמות בין שני הצדדים) בנוגע לדרך בה חבילה נראית, מעין שכבה נוספת. כך נוכל לדעת היכן מתחילה ונגמרת חבילה. כפי שציינו בתחילת המדריך, אנו הולכים לכתוב תוכנת צ'אט בין שני צדדים. אם כך, מה הם הצרכים שלנו, ומה החבילה שלנו תכיל?
החבילה שלנו תכיל שתי מחרוזות: מחרוזת המתארת את הכינוי של הצד השולח, ומחרוזת שתכיל את תוכן ההודעה. דוגמה לחבילת מידע:
איציק: שלום, מה שלומך?
הכל טוב ויפה, אבל אנחנו עדיין לא בטוחים שהכינוי ותוכן ההודעה אינם סטטיים בגודלם (אורך המחרוזת אינו קבוע), ועדיין לא נוכל לזהות מתי נגמרת החבילה בגלל שאורכה משתנה. איך נוכל לדעת את גודל החבילה? התשובה לכך היא פשוטה: נציב מספר שלם (Integer) לפני כל מחרוזת. אנו יודעים שמספרים שלמים תמיד יתפסו ארבעה בייטים (32 סיביות / 8 סיביות). לכן, תמיד נקרא את ארבעת הבייטים הראשונים וכך נוכל לדעת את אורך המחרוזת. בסופו של דבר, החבילה שלנו תראה כך:
כעת נוכל להבחין בין חבילה וחבילה בקלות רבה ונוכל לעבור לחלק המעשי של התכנות. עם זאת, מדריך זה מיועד לאנשים עם ניסיון קודם בתכנות – על כן באמצעות מדריך זה לא תלמדו כיצד לתכנת, אלא כיצד לעשות שימוש באותן שיטות אשר נלמדות במדריך זה. לאחר כל קטע קוד ינתן הסבר כללי על הנעשה, בעוד שורות הקוד עצמן יכללו בצד תיאורים קצרים.
הקישור לזיכרון RAM לא נכון
זה לא נכון לקשר מכאן לזכרון RAM כי זה לא הנושא.
מדובר כאן על זכרון של תהליכים, לכל תהליך מוקצה אזור זכרון ואת אותו זכרון הוא לא יכול לחלוק עם תהליכים אחרים.
אין שום טעם לקשר את זה לזכרון RAM למרות שהזכרון הזה נמצא שם.
חוץ מזה מדריך מעולה!!
אתם אתר נפלא שתמיד מחכים אותי.
כתבה מעולה…
תודה רבה קודם כל, אפשר ללמוד המון.
אפשר לשפר בכך שתפרט מעט יותר על כל מיני מושגים שמבחינתך הם בסיסיים אך מבחינת אנשים שאתה בא ללמד הם ממש לא.
בכל אופן ישר כח ותמשיך כך.מצוין!
למה בדוד-מת?
הוא מת כבר לפני שנים.
לא רלוונטי
ב-.NET יש תשתית WCF שהיא תשתית ה-communication של ה-Framework.
לעבוד ישירות מול המחלקות המתוארות זה חסר טעם ולא נכון מבחינת ארכיטקטורה.
התשתית שהיא עשירה לאין ערוך ממה שתואר כאן, מאפשרת העברת נתונים באופן נוח ו"שקוף" ללקוחות המאזינים ולקבוע את צורת התקשורת (Named Pipes, וכיו"ב) בקונפיגרציה.
היא כמובן גם מאפשרת להתמודד עם תרחישים פשוטים ועד תרחישים מסובכים הרבה יותר בהם לדוגמה הנתונים נאספים ממספר מערכות בתהליך טרנזאקטיבי או תרחישים אחרים.
תודה רבה
מדריך מעולה ,נפל עלי כיאלו הזמנתי אותו אישית
בינוני.
מצטער שזה יוצא כ"כ תקיף, אבל הקוד שנכתב הוא ברמה בינונית מאוד.
כל העטיפה, השימוש בThreadים בצורה לא נכונה, עבודה מול UI בצורה לא נכונה, חוסר עבודה בקונבנציות…
ד"א, לבחור שכתב שכדאי לכתוב את זה בWCF – אתה טועה. WCF מתאים לשירותים (SOA במיוחד) ולא לתקשורת כזו. זה סתם overhead לא הכרחי.
סוגרים על פרוטוקול ושולחים בraw sockets כמו שהבחור עשה… אלא אם יש לך שרת מרכזי שמולו אתה עובד (כמו שlive messenger עובד) ואז הארכיטקטורה שלך צריכה להשתנות ואולי WCF יותר יתאים.
בכל מקרה- בחור, רצון יש אבל ידע לוקה בחסר.
6 -קצת צניעות לא תזיק וגם לא ידע
WCF לא קשורה בהכרח ל- SOA למרות שהיא דרך אופרטיבית אידיאלית להשיג SOA.
WCF זו תשתית התקשורת של ה-FRAMEWORK והיא מטפלת בהעברת נתונים באשר היא.
מבחינת ארכיטקטורה הרצון שלך הוא להגדיר מה אתה רוצה להעביר בצורה פשוטה בקוד (גישת AOP שבה עושה שימוש WCF)ולקבוע בקונפיגרציה האם אתה רוצה העברה פשוטה כמו NAMED PIPES או TCP או משהו כמו HTTP או כל פרוטוקול אחר בהתאם לצורך ול-HOST.
אתה יכול לעבור מצורת העברה אחת לאחרת ללא שינוי קוד.
לעיתים בכלל לא מדובר על העברת נתונים בין מכונות אלא על העברה פשוטה בין אפליקציות. זה בכלל לא משנה.
תכנות נכון הוא להבטיח את המחר, את היכולת לשנות ולגדול בלי שכתובים מהותיים.
במקרה שלך, אתה מציע לכתוב קוד "בסיסי" (שהוא אגב הרבה יותר מורכב מ-WCF) ומחר כשהצורך משתנה או גדל להחליף את כולו.
אני מצטער, אבל גם לך יש קצת שעורי בית להשלים.
מיושן – יש היום WCF
בשביל ליצור תקשורות ב
.NET
לא משתשמים בדרך הפרמטיבית הזאת עם על הכבוד , יש טכנולוגיה שנקראת
WCF ( שמחליפה את הדרך שאתה מציג)
שאתה כותב קוד קצר ומאחורי הקלעים עולם ומלאו(שמכיל את הדרך הזאת) כולל אבטחה ( RSA גם). ניתן לבחור בשלל אפשריות מתוך ה
WIZARD
אבטחה – סוג תקשורות TCP UDP WSHTTPS ועוד הרבה .
מטרת המדריך
שלום, מטרת המדריך אינה להציג למשתמשים את הדרך הפשוטה והקלה ביותר ליצירת תקשורת בסביבה זו. המטרה היא לא להעביר את המידע במספר השורות הקצר ביותר או בדרך הקלה ביותר. מטרת המדריך היא ללמד את המשתמשים ליצור תקשורת ברמה נמוכה יותר תוך כדי שהם לומדים כיצד חבילות המידע נשלחות ומה קורה בעצם ברקע. במדריך המשתמשים לומדים כיצד להשתמש ב-Multi-Threading ובקבצי DLL. אומנם הדרך שבה המידע הועבר בין ההליכים אינה הדרך הטובה ביותר ולא הכי נכונה אך היא המובנת ביותר. כמובן ניתן היה למשל להשתמש במחלקת ה-SynchronizationContext בכדי להעביר מידע בין ההליכים בצורה נכונה יותר.
למי שמגיב נגד, ולכותב המדריך
אני לא ראיתי אף מדריך שמסביר זאת
מי שחושב שהמדריך לא טוב, שיכתוב מדריך בבקשה.
אני כרגע לומד את זה ואני אומר תודה רבה למי שכתב את המדריך.
אני מקווה שיעזור לי.