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

DadleFish

New member
ממשיך את הדיון בעניין ה-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 במקרה של תקלה. זהו. הערות?
 

אמיר ט

New member
רק דבר אחד

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

vinney

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

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

Lasro

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

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

DadleFish

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

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

DadleFish

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

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

codec

New member
נשמע טוב

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

DadleFish

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

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

selalerer

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

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

DadleFish

New member
אין מצב ל-TCP

יש לי 100,000 לקוחות לטפל בהם. פשוט נגמרים לך הפורטים בכזה מצב
. אני מניח שאם הוא לא מאחורי NAT ובהנחה שלא התנתק והתחבר מחדש, אז אין לי בעיה והוא עדיין מולי. אם הוא לא מאחורי NAT, זו אחריותו לבדוק את הרשת והאם הוא מחובר אליה עדיין. ה-TO הסטנדרטי לפי RFC 2663 (שמתבטא בצורה של "זה עשוי לעבוד אבל לפעמים זה לא עובד"
) הוא "כמה דקות" לתקשורת NON-TCP.
 

selalerer

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

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

DadleFish

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

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

codec

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

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