בהרבה אפליקציות שמפתחים נדרש לשתף נתונים בין ה server ל client וגם בין מספר clients ל server אחד.
ככל שמספר ה clients גודל – כך העומס על השרת עולה , Azure פותר אולי את הבעיה ברמה הטכנית , אבל יש צורך לשלם על זה...
עם הזמן שמתי לב שיש דפוס כמעט קבוע שחוזר על עצמו בהרבה אפליקציות:
כשה client עולה הוא מסתנכרן מול ה server , וכך כל client נוסף שעולה חוזר על הפעולה.
כשיש שינוי באחד מה clients הוא מעדכן את ה server ומשם יש שתי אופציות:
1. או שה clients עושים pooling ל server כדי לקבל עדכונים.
2. או שה server שולח הודעה (למשל ב WCF ע"י מימוש Pub/Sub) לשאר ה clients.
לכאורה הפתרון השני הוא המועדף – אבל יש איתו מספר בעיות:
1. אם ה clients נמצאים מאחורי NAT או Firewall שמונע מה server שליחת הודעות ב callback אליהם , חייבים להחזיק socket פתוח אל ה server , ואז ככל שכמות ה clients עולה – כך כמות ה sockets הפתוחים בצד ה server.
2. בכמויות גדולות של clients ה server צריך לשלוח את אותה הודעה לכולם מה שיוצר אצלו ג"כ צוואר בקבוק מבחינת ביצועים.
אני מציג כאן תשתית שכתבתי המשתמשת ב PeerChannel (טכנולוגית P2P של מייקרוסופט מבוססת WCF) , כדי לבצע את אותו מנגנון סינכרון , כתבתי גם אפליקציה לטסטים ולדוגמא כיצד לעבוד עם התשתית.
חלק מהרעיונות למדתי מ Kevin Hoffman שפירסם מאמר ב msdn magazine
בעיות קיימות (מקווה לפתור בגרסה נוספת):
1. זמן פתיחה ארוך של ה proxy , וזמן נוסף שעובר לאחר שנוסף peer ל mesh עד ל online event ולתחילת הסנכרון.
2. בסיטואציות מסויימות יכול להיות mesh אחד שמכיל מספר peers אבל מספר קבוצות של peers כך שכל peer חושב שהוא Online ומסונכרן עם כל ה mesh , אבל הסנכרון שלו הוא רק עם התת קבוצה שאליה הוא מחובר , הפיתרון כרגע מבוסס על refresh שנעשה ב interval שניתן לשלוט בו (default 30 שניות בכל peer)
הקוד עדיין בתחילת הדרך , אשמח לקבל הערות ושיפורים.
ניתן להוריד אותו מכאן.
הסבר על האפליקציה לדוגמא:
כל חלון מייצג peer אחד ב mesh , ויש לו name ו data שניתן לערוך:
א. לאחר שלוחצים על connect ה peer פותח channel וה communication status שלו עובר ל opening ולאחר מכן opened, ברגע שה peer עובר לסטטוס opened הוא מכניס ל grid את הפרטים שלו , ועדיין לא מסונכרן מול peerים אחרים.
בדוגמא peer A ו peer B עברו ל Opened והכניסו את המידע על עצמם – עדיין ללא סנכרון , peer C עדיין לא נפתח ונמצא בסטטוס created
ב. אם הוא מוצא peer נוסף הוא עובר לסטטוס online , ומתחיל תהליך סנכרון מול ה peerים האחרים – שולח להם בקשה לסנכרון , מקבל את המידע ומציג אותו ב grid , אותו דבר קורה ב peerים האחרים שעברו למצב online
בדוגמא A ו B במצב Online ומסונכרנים ביניהם
ג. לחיצה על send update of own details תעדכן את כל ה peers האחרים בנתונים שיש באיזור ה user details.
בדוגמא D מעדכן את A B ו C ב "some new data":
ד. לחיצה על disconnect תשלח הודעה ל peerים האחרים על יציאה – והם ינקו את השורה שמייצגת את ה peer שירד.
אין תגובות:
הוסף רשומת תגובה