ממשיך את הדיון בעניין ה-UDP NAT

[DadleFish]

ממשיך את הדיון בעניין ה-UDP NAT

1. כשמחשב פנימי יוצא מהרשת החוצה לשרת חיצוני, נוצר מיפוי NAT אוטומטית ברמת הראוטר שלו. בצורה כזו, השרת יכול להגיב לפניה הנ"ל, והתגובה תגיע אל המחשב הפנימי. זה נכון גם ל-UDP, למרות שב-UDP אין CONNECTION. 2. הלכה למעשה, חלק מהראוטרים מעלימים את המיפוי הנ"ל אחרי זמן מה. עד כאן העובדות. הפתרון שאני איישם ככל הנראה, שהוא הפתרון שהיה לי מראש אבל רציתי לראות אם מישהו יחדש לי משהו פה או בפורום רשתות, הוא כזה - בגדול, ה-CLIENT הולך ללמוד לבד מה הזמן המקסימלי שמותר לו לקחת בין KA אחד לשני, בהינתן שרת מסוים שעובד מולו. בתור התחלה, כל CLIENT יעבוד עם 30 דקות זמן KA. בנוסף יפותח ב-SERVER מיני פרוטוקול פשוט של PING ו-PONG אל ה-CLIENT, על מנת שה-SERVER יידע האם בזמן מסוים X יש לו או אין לו קשר מול ה-CLIENT הנ"ל. ה-SERVER ישלח PING ל-CLIENT זמן קצר לפני קבלת ה-KA הבא מאותו CLIENT (הנתון הזה יהיה ידוע ל-SERVER), וכך ל-SERVER תהיה אינדיקציה האם יש או אין קשר מול ה-CLIENT. ב-KA הבא ידווח ה-SERVER ל-CLIENT האם הקשר נשמר או לא. אם הקשר לא נשמר, ה-CLIENT יצמצם פי 2 את האינטרוול, ואם הקשר נשמר - ה-CLIENT יגדיל פי 2 את האינטרוול. הטווח של האינטרוול יוגבל להיות בין 8 שעות לבין 5 דקות, על מנת למנוע מצב שבו CLIENT מסוים יפציץ את ה-SERVER במקרה של תקלה. זהו. הערות?

 

[אמיר ט]

רק דבר אחד

נגיד אתה במצב התחלתי של KA כל 30 דקות, אתה מגלה שזה זמן גדול מדי והראוטר סוגר את המיפוי עד אז, אז אתה מצמצם את זמן הKA בחצי. עכשיו אתה על KA כל 15 דקות הכל יפה וטוב, ואתה מנסה להעלות שוב את הKA, לפי מה שרשמת פי 2 - אתה חוזר ל 30 דקות ושוב זה בעייתי. לדעתי אחרי שאתה מזהה זמן מסוים שהראוטר לא סוגר את המיפוי אתה צריך להעלות את זמן הKA פי 1.5 (או כל מספר אחר, העיקר לא פי 2) אם אתה מחלק ומכפיל באותו פקטור אתה יכול להגיע למצב שאתה משחק בין 2 זמנים תמידית.

 

[vinney]

../images/Emo45.gif

 

[DadleFish]

צודק במאה אחוז, תודה.

 

[vinney]

הרעיון של חיפוש בינארי

הוא תמיד ללכת על חצי טווח, לא משנה אם זה לצימצום או הגדלה... המקדם צריך להיות תמיד 1/2 - או להוריד חצי מהזמן או להוסיף חצי מהזמן, אחרת אתה הולך בסיבובים. סתם שאלה, מאיפה הבאת 30 דקות? אין איזה הגדרת TIMEOUT סטנדרטית לפרוטוקול?

 

[Lasro]

זה תלוי בהגדרה של הראוטר.

זה לא קשור לפרוטוקול , זה timeout של הרואטר / מודם / OS ה30 דקות זה בגלל שהוא בן אדם אופטימי.

 

[vinney]

../images/Emo6.gif

 

[DadleFish]

למה אופטימי? ../images/Emo13.gif

שמע, נתקלתי רק בראוטר אחד שעשה בעיות כאלו, והוא סגר אחרי שעה...

 

[voguemaster]

טוב, פסימי ../images/Emo3.gif

 

[DadleFish]

לא, זה תלוי בראוטר

הבאתי חצי שעה כי הזמן שאני נתקלתי בו הוא שעה... לא הצלחתי למצוא משהו סטנדרטי לסיפור הזה.

 

[codec]

נשמע טוב

מעניין, שהרבה סטנדרטים ואפליקציות ניתקלו בבעיה הזאת (חיפוש קצר באינטרנט העלה אפליקציות P2P, IPSEC ועוד), אבל אף אחד לא הציע פיתרון סטנדרטי לבעיה. מה שכן, אני מציע לך "לאמץ" חלק מהפיתרון ב-IPSEC, שנועד לגלות אם בכלל יש NAT בין המחשבים - במקרה כזה KEEPALIVE הוא מיותר לחלוטין (אם אתה מתעלם, כמובן, מאובדן "טבעי" של הודעות UDP ברשת...) ולבסוף, מהתוצאות שאני מצאתי (ולא מדובר במדגם סטטיסטי סביר) נראה שהמציאות היום היא, שה-TIMEOUT הזה הוא די נמוך - 30 שניות, משיקולי זיכרון...

 

[DadleFish]

וואלה, אתה צודק

יכול להיות שרוב הלקוחות בכלל לא יחזיקו NAT... יפה, תודה. מצד שני, עוד בעיה שיכולה כן לקרות היא אובדן תקשורת של ה-CLIENT לרשת, וחזרה שלה. במקרה כזה אני לא אצליח לתקשר עם ה-CLIENT עד שהוא יעשה רגיסטרציה מחדש. איפה מצאת את ה-30 שניות האלו? זה משנה לי את התמונה.

 

[selalerer]

../images/Emo13.gif ברור שצריך לבדוק אם יש NAT.

הדרך הפשוטה ביותר היא שהוא ישלח לך את הIP שלו ואתה תשווה את זה עם זה של הsource של הpacket שהגיע אליך. אם הTO הסטנדרטי, הוא 30 שניות, אז יכול להיות שלהקים מולו קשר TCP ייקח לך את אותה כמות משאבים או אפילו פחות. בכל מקרה עדיין יש לך בעיה של לקוח נפל. אין לך ממש דרך לדעת אם אתה מדבר אליו באופן חד צדדי. הוא צריך או לתת לך אישור "קיבלתי" או לשלוח KA בכל מקרה, גם אם הוא לא מאחורי NAT.

 

[DadleFish]

אין מצב ל-TCP

יש לי 100,000 לקוחות לטפל בהם. פשוט נגמרים לך הפורטים בכזה מצב

. אני מניח שאם הוא לא מאחורי NAT ובהנחה שלא התנתק והתחבר מחדש, אז אין לי בעיה והוא עדיין מולי. אם הוא לא מאחורי NAT, זו אחריותו לבדוק את הרשת והאם הוא מחובר אליה עדיין. ה-TO הסטנדרטי לפי RFC 2663 (שמתבטא בצורה של "זה עשוי לעבוד אבל לפעמים זה לא עובד"

) הוא "כמה דקות" לתקשורת NON-TCP.

 

[selalerer]

אם ללקוח יש הפסקת חשמל.....

...וגם שהוא חוזר להתחבר, הוא לא מפעיל התוכנת לקוח שלך, אז מתיי הserver שלך יוריד אותו מהרשימות שלו. חבל לבזבז עליו משאבים.

 

[DadleFish]

נכון, חבל לבזבז עליו משאבים,

אבל מדובר במשאבים מינימליים ביותר. ממילא אני מחזיק את ה-CLIENT ב-DATABASE, וההבדל בין "רשום" לבין "לא רשום" מתבטא בתוכן שדה ב-DB. היות ה-CLIENT רשום "בטעות" אומר בסה"כ טיפה יותר עבודה ל-SERVER, עוד מעט מאוד הודעות UDP, וזה הכל. לעומת זאת, אם אני בונה מנגנון KEEP ALIVE רק בשביל זה - זה כבר מאוד מעמיס לי על ה-SERVER.

 

[codec]

לא "מצאתי" - זה לא משהו רשמי

זאת התמונה שקיבלתי מדיונים שונים באינטרנט, שדיברו על נושאים דומים וקשורים למה שאתה עושה (UDP, NAT וכל המשפחה).

 

[ירון כהן טל]

הצעה

אני נתקלתי באותה הבעיה פעם... אני לא מכיר פתרון, אבל שווה לך לנסות בפורום רשתות של GameDev http://www.gamedev.net/community/forums/forum.asp?forum_id=15