צ'אט שבניתי עם ספריית MooApi בJava

[adiel666]

הא?

 

[adiel666]

../images/Emo32.gif צ'אט שבניתי עם ספריית MooApi בJava

הצ'אט בנוי עם ספריית הרשת MooAPI (שנודעה בעקרון לפיתוח משחקי מחשב מרובי משתתפים) את הספריה עצמה, אדם רימון(חבר, שהוא גאון בכל הקשור לתכנות) תיקן על ידי Decompile ותיקון הקידוד לUTF-8 כך שניתן לשלוח ולקבל מחרוזות גם בעברית. כתובת גרסת הנסיון של הצ'אט: http://adiel666.no-ip.org תכונות ומגבלות: הצ'אט מסוגל להחזיק כ100 חיבורים על המחשב שלי בקשר TCP ללא בעיה(וההעלאה שלי ממש לא משהו) במידה וחלון הדפדפן Minimized ונשלחה הודעה בצ'אט תשמעו קול מעצבן שכזה כמו במסנג'ר כמו שאמרתי למעלה, ניתן להתחבר עם שם משתמש/לשלוח הודעות בכל שפה שהיא(כמעט) - UTF8. במידה והצ'אט והשרת שלו, יחזיקו ללא בעיה במשך שבוע אוכל להכניס אותו למשחק שלי. תודה לכל מי שיעזור ויתחבר. תיקונים ותוספות עתידיות לצ'אט: אפשרות בחירה אם יושמע קול או לא בהודעה שהתקבלה בצ'אט, כאשר חלון הדפדפן minimized. שליחת הודעות פרטיות. אפשרות הצגה של סמיילים בחלון הצ'אט.

 

[somebodddy]

אני יודע שהבטחתי לעזור עם הבדיקות

אבל אני חייב ללכת עכשיו, אז אני אכנס יותר מאוחר בלילה. סבבה?

 

[adiel666]

בכיף, גם אני הייתי עסוק

מה שכן הוספתי את הCheckBox שדיברת עליו בקשר לצליל

 

[adiel666]

סידרתי sound + הודעות פרטיות

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

 

[somebodddy]

חשבתי שאתה עושה את זה בתור מבחן עומס

לספריית השרת שאתה משתמש בה למשחק שלך.

 

[adiel666]

לא בדיוק

רק לצ'אט, זה לא פרקטי לעשות לזה מבחן עומס כשזה סה"כ צ'אט שמשתמש בפונקציונליות שלה... המשחק עצמו מתוכנן לשלוח הרבה יותר packets מכל client מאשר צ'אט פשוט. מה שכן קשר האינטרנט העלוב שלי הצליח להשתלט על 150 Connections לפני שהתחיל לנתק clients בגלל timeout, ומשום שזה על פרוטוקול TCP זה פחות קטע של Packets שהם בכל מקרה מעט מאוד נתונים(40-200 bytes ממוצע לכל שליחה) ויותר קטע של "להחזיק" את הקשר. נראה לי שזה עובד טוב כמו שזה, אני אמשיך כבר עם שאר הClasses למשחק שלי... תודה על העזרה בכל אופן, ומי שזה מעניין אותו השרת עדין פתוח(אני בוחן את היציבות שלו).

 

[voguemaster]

זה לא קטע של להחזיק את החיבורים

כי TCP עצמו שולח KEEP ALIVE בתדירות די נמוכה. גם אם תכפיל אותה ב-150 חיבורים זה לא יהווה מספיק "בשר" כדי לגרום ל-TIMEOUTים. צוואר הבקבוק שלך כנראה נמצא במקום אחר... או, שיש בעיה אחרת שאתה אולי לא מודע אליה..

 

[adiel666]

הפרוטוקול עובד כך שהוא שולח בעצמו Packet ריק

כל 5 שניות בערך, על "subchannel"(וירטואלי) 1000. ברגע שעברו כ10 שניות מאז שהpacket הקודם נשלח מהclient לשרת והשרת לא קיבל עדין packet חדש על אותו ה"ערוץ" מאותו הקליינט, הוא ישמיד את הSocket אל אותו הClient... וכן, 150 חיבורים הם השיא כרגע לחיבור האינטרנט שלי, בלי קשר להאם הם שולחים נתונים או לא כי השרת לא יספיק לקבל תוך 10 שניות את הpacket הנחוץ מכל קליינט ספציפי והוא יתחיל לנתק חיבורים. אני משער שסרבר מקצועי בעל חיבור של 10MBIT העלאה יחזיק קצת יותר מה96KBIT העלאה שלי, יחס של 1:100 כמעט.

 

[somebodddy]

פי 2 מקצב השליחה זה לא מעט מדי?

נראה לי כדאי להעלות את זה לפי 6 - כלומר חצי דקה.

 

[IdleThought]

מעניין אם יש פרוטוקולים כאלה אבל מבוססי UDP

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

 

[somebodddy]

הספרייה הזו בעצמה מבוססת UDP, לא?

 

[somebodddy]

לאמשנה, לא קראתי עד הסוף...

 

[adiel666]

ובכן

לא מדובר רק ב"צ'אט מסחרי" אלא במשחק MMORPG שיפעל כApplet בתוך הדפדפן. ואני לא רוצה לבדוק רק כל כמה דקות אם הבנאדם יצא, אלא לפנות את הSLOT שלו ב10 השניות מקסימום בהן הוא מתנתק לי מהשרת בכל צורה שהיא(ניתוק רגיל יגרום בכל מקרה להתנתקות המיידית שלו, בערך 1-2 שניות).

 

[voguemaster]

הצעה נוספת

לא יודע אם ראית את ההודעה שלי לגבי JAVA WEBSTART או לא אבל אני ממליץ לך בחום רב לעבוד עם הטכנולוגיה הזו לעומת APPLETים.

 

[voguemaster]

אם אתם עובדים עם TCP, מה ההגיון בפאקט ריק ?

תכלס אני לא כ"כ מבין איך חישבת 150 (או שלא חישבת, פשוט ראית שזו המגבלה). כלומר, מה הקשר בין מגבלת 150 החיבורים לאותן 10 שניות ? אותן 10 שניות זה TIMEOUT שאתה מגדיר אצלך באפליקציה כדי למנוע מצב שיש מישהו שלא שולח נתונים הרבה זמן. איך זה גורם לכך שיהיו רק 150 חיבורים ? מסורתית TIMEOUT צריך להיות גבוה יותר גדי להתגבר על בעיות רשת "זמניות" (איתחול של נתב בנתיב שבו עוברות הפאקטות, לדוגמא). לא ברור לי למה אתם עושים כזה OVERKILL מבחינת תקשורת.

 

[adiel666]

אסביר

פאקט ריק מנצל כמה שפחות Bandwidth וכשמדובר בחיבור TCP שבכל מקרה פועל על STREAM, זה כמעט ולא פוגע בBandwidth בין הClients לServer, ככה שזאת בדיקה טובה. שוב, אני מזכיר שלא אני יצרתי את הפרוטוקול, הוא נוצר לפני הרבה שנים לMMF1.5 ולאחר מכן קיבל PORT משלו לJAVA כך שיישומים שנוצרו בMMF2 יוכלו לתקשר עם שרת שפותח בJAVA(ולא תחת סביבת הריצה של MMF). מצאתי לנכון להשתמש בפרוטוקול זה משום שאני מכיר אותו על כל היבטיו(קיבלתי מקליקטים את הSOURCE לC++ פעם בשביל להכניס לו תמיכה בUDP). הפרוטוקול בJAVA נוצר מחדש, ולא Wrapper בשימוש עם JNI, עם זאת הוסיפו לו את הקטע של ההודעה הריקה בשביל למנוע לאג מאסיבי מהשחקנים על השרת, זה סה"כ יגרום לאנשים בעלי Latency של מעל 5 שניות לשרת להתנתק(כי ההודעה שלהם לא תגיע לשרת בזמן, והשרת ינתק אותם). הפרוטוקול קליל ונועד לפיתוח משחקי מחשב מכל סוג שנועדו להיות Multiplayer Online. כיום מישהו מסיים גם לייצר את הפרוטוקול הזה(Moo- Multiplayer online object) לPython. 150 חיבורים - זה הנסיון שעשינו(וזאת ממש לא בדיקה מושלמת), החיבורים מעל התחילו להזרק על ידי השרת(בגלל שההודעה שלהם כנראה לא הגיעה בזמן). ושוב, זה לא קשור לשחקן שבמצב idle, את זה אני יכול לבדוק בעצמי ולהחליט שאני מעיף אותו... קישור לכל המעוניין לראות את הפרוטוקול מיושם בJava: www.gwerdy.com

 

[voguemaster]

כלומר אין קשר בין כמות החיבורים ל-TIMEOUTים

תשמע, מה שאתה אומר פה זה שחיבורים נזרקים ע"י השרת כי לא הגיעה הודעה מעבר ל-5 שניות. אם אנחנו יודעים שפאקט ריק לא ממש לוקח לנו הרבה רוחב פס זה קצת לא הגיוני כי הרי כל קליינט אמור לשלוח HEARBEAT כזה כל כמה שניות, לא ? אני לא להעביר עליך ביקורת או משהו, פשוט לציין שיש מצב שאתם לא מודעים למה יש לכם מגבלת חיבורים. זה פשוט לא מסתדר. אם השרת זורק חיבורים הייתי ממליץ לכם לבדוק למה. זה יכול להיות בגלל מגבלות שיש לתוכנה של השרת ע"י מערכת ההפעלה, זה יכול להיגרם בגלל מגבלות זיכרון של הנתב בדרך (במיוחד אם אצלך בבית יש רשת אלחוטית לדוגמא, שם הבעיות האלה הרבה יותר משמעותיות מאשר ברשת קווית). במקרה של שחקן שיש לו LATENCY של 5 שניות, סבבה, את זה אני מבין והניתוק הגיוני, אבל אם אתה עובד בסביבה מבוקרת כנראה שאין לך בעיה של שחקן שמאבד תקשורת אל השרת אלא משהו אחר. בכל מקרה, אני אשמח לעידכונים אם יהיו לך...

 

[adiel666]

לא נראה לי שהבנת את זה בדיוק

הקשר בין כמות החיבורים לtimeout הוא בעצם העומס על השרת. החיבור עצמו מעמיס על השרת(מבחינת Bandwidth). לא אמרתי שזה קבוע של 150, אני פשוט אומר שמעל לכך החיבורים מתחילים להתנתק משום שהשרת כל כך "איטי" שהוא לא מספיק לקבל את הפאקט הריק מהמשתמשים כבר, אחרי 150 חיבורים - וזה נובע מכך שיש לי רק 96KB העלאה. הבדיקה בוצעה כך שמישהו התחבר עם לולאה מאותו המחשב כמעל ל-150 חיבורים, בסופו של דבר הLatency שלו רק הלך וגדל ועבר את ה5 שניות, ואז החיבורים החלו להתנתק עד שהLatency שלו היה קטן מ5 שניות(בסביבות 150 חיבורים יציבים) וכל הפאקטים הריקים הגיעו מכל הClients שיצר. הגיוני?

 

[voguemaster]

זה כבר נשמע שזה תלוי בקוד של הספריה

וגם בקוד של מי שעשה את הבדיקה. אם לדוגמא אני פותח כמה מאות חיבורי TCP בלולאה ואני לא מאפשר תוך כדי קריאה מה-SOCKET לכל דבר שמגיע מהשרת (או לחלופין, אני לא מאפשר לעצמי לשלוח HEARTBEAT) אז הלולאה הזו תוקעת את כל החיבורים. השאלה היא האם בתוך הלולאה יש גם שליחה של KEEP ALIVE מהסוג שאתם משתמשים בו וקבלת תשובה מהשרת כי כל עוד אתה בתוך הלולאה, אתה די תוקע את העבודה של כולם (כמובן, אם הם ב-THREADים נפרדים אז זה לא יקרה אבל זו כבר סוגיה אחרת...)