מבוא

החברה שלנו Leaning Technologies מספק פתרונות להעברת יישומי שולחן עבודה מסורתיים לאינטרנט. מהדר C++ שלנו לשמח יוצר שילוב של WebAssembly ו-JavaScript, המספק את שניהם אינטראקציה פשוטה בדפדפן, וביצועים גבוהים.

כדוגמה ליישום שלו, החלטנו להעביר משחק מרובה משתתפים לרשת ובחרנו Teeworlds. Teeworlds הוא משחק רטרו דו מימדי מרובה משתתפים עם קהילה קטנה אך פעילה של שחקנים (כולל אני!). הוא קטן הן מבחינת משאבים שהורדו והן מבחינת דרישות מעבד ו-GPU - מועמד אידיאלי.

פועל בדפדפן Teeworlds

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

• XMLHttpRequest/אחזור, אם חלק הרשת מורכב רק מבקשות HTTP, או
• WebSockets.

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

יש דרך שלישית - השתמש ברשת מהדפדפן: WebRTC.

RTCDataChannel הוא תומך גם בשידור אמין וגם לא אמין (במקרה האחרון הוא מנסה להשתמש ב-UDP כפרוטוקול תעבורה במידת האפשר), וניתן להשתמש בו גם עם שרת מרוחק וגם בין דפדפנים. זה אומר שאנחנו יכולים להעביר את כל האפליקציה לדפדפן, כולל רכיב השרת!

עם זאת, זה בא עם קושי נוסף: לפני ששני עמיתים של WebRTC יכולים לתקשר, הם צריכים לבצע לחיצת יד מורכבת יחסית כדי להתחבר, מה שמצריך כמה ישויות של צד שלישי (שרת איתות ושרת אחד או יותר לְזַעזֵעַ/תור).

באופן אידיאלי, נרצה ליצור ממשק API לרשת שמשתמש ב-WebRTC באופן פנימי, אך קרוב ככל האפשר לממשק UDP Sockets שאינו צריך ליצור חיבור.

זה יאפשר לנו לנצל את היתרונות של WebRTC מבלי לחשוף פרטים מורכבים לקוד האפליקציה (שרצינו לשנות כמה שפחות בפרויקט שלנו).

מינימום WebRTC

WebRTC הוא קבוצה של ממשקי API הזמינים בדפדפנים המספקים שידור עמית לעמית של אודיו, וידאו ונתונים שרירותיים.

החיבור בין עמיתים נוצר (גם אם יש NAT באחד הצדדים או בשני הצדדים) באמצעות שרתי STUN ו/או TURN באמצעות מנגנון הנקרא ICE. עמיתים מחליפים מידע ICE ופרמטרים של ערוץ באמצעות הצעה ותשובה של פרוטוקול SDP.

וואו! כמה קיצורים בבת אחת? בואו נסביר בקצרה מה משמעות המונחים האלה:

• כלי עזר למעבר הפעלה עבור NAT (לְזַעזֵעַ) - פרוטוקול לעקוף NAT וקבלת זוג (IP, יציאה) להחלפת נתונים ישירות עם המארח. אם הוא מצליח להשלים את המשימה שלו, אז עמיתים יכולים להחליף נתונים זה עם זה באופן עצמאי.
• מעבר באמצעות ממסרים סביב NAT (תור) משמש גם למעבר NAT, אך הוא מיישם זאת על ידי העברת נתונים דרך פרוקסי הגלוי לשני העמיתים. זה מוסיף חביון ויקר יותר ליישום מאשר STUN (מכיוון שהוא מיושם לאורך כל סשן התקשורת), אבל לפעמים זו האפשרות היחידה.
• הקמת קישוריות אינטראקטיבית (קרח) משמש לבחירת השיטה הטובה ביותר לחיבור שני עמיתים בהתבסס על מידע המתקבל מחיבור עמיתים ישירות, כמו גם מידע המתקבל על ידי כל מספר של שרתי STUN ו-TURN.
• פרוטוקול תיאור הפעלה (SDP) הוא פורמט לתיאור פרמטרים של ערוצי חיבור, למשל, מועמדי ICE, קודקים מולטימדיה (במקרה של ערוץ אודיו/וידאו) וכו'... אחד מהעמיתים שולח הצעת SDP, והשני מגיב ב-SDP Answer . לאחר מכן, נוצר ערוץ.

כדי ליצור חיבור כזה, עמיתים צריכים לאסוף את המידע שהם מקבלים משרתי STUN ו-TURN ולהחליף אותו זה עם זה.

הבעיה היא שעדיין אין להם את היכולת לתקשר ישירות, ולכן חייב להתקיים מנגנון מחוץ לפס כדי להחליף את הנתונים האלה: שרת איתות.

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

דיאגרמת רצף לחיצת יד WebRTC פשוטה

סקירת מודלים של רשת Teeworlds

ארכיטקטורת הרשת של Teeworlds היא פשוטה מאוד:

• רכיבי הלקוח והשרת הם שתי תוכניות שונות.
• לקוחות נכנסים למשחק על ידי חיבור לאחד מכמה שרתים, שכל אחד מהם מארח רק משחק אחד בכל פעם.
• כל העברת הנתונים במשחק מתבצעת דרך השרת.
• שרת ראשי מיוחד משמש לאיסוף רשימה של כל השרתים הציבוריים המוצגים בלקוח המשחק.

הודות לשימוש ב-WebRTC להחלפת נתונים, אנו יכולים להעביר את רכיב השרת של המשחק לדפדפן בו נמצא הלקוח. זה נותן לנו הזדמנות מצוינת...

היפטר משרתים

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

עם זאת, כדי שהמערכת תעבוד, אנחנו עדיין צריכים להשתמש בארכיטקטורה חיצונית:

• שרת STUN אחד או יותר: יש לנו כמה אפשרויות חינמיות לבחירה.
• לפחות שרת TURN אחד: אין כאן אפשרויות חינמיות, אז אנחנו יכולים להגדיר משלנו או לשלם עבור השירות. למרבה המזל, רוב הזמן ניתן ליצור את החיבור דרך שרתי STUN (ולספק p2p אמיתי), אבל יש צורך ב-TURN כאפשרות סתירה.
• שרת איתות: בניגוד לשני ההיבטים האחרים, האיתות אינו סטנדרטי. על מה שרת האיתות יהיה אחראי בפועל תלוי במידה מסוימת באפליקציה. במקרה שלנו, לפני יצירת חיבור, יש צורך להחליף כמות קטנה של נתונים.
• Teeworlds Master Server: הוא משמש על ידי שרתים אחרים כדי להכריז על קיומם ועל ידי לקוחות כדי למצוא שרתים ציבוריים. אמנם זה לא הכרחי (לקוחות יכולים תמיד להתחבר לשרת שהם מכירים ידנית), זה יהיה נחמד כדי ששחקנים יוכלו להשתתף במשחקים עם אנשים אקראיים.

החלטנו להשתמש בשרתי STUN החינמיים של גוגל, ופרסנו שרת TURN אחד בעצמנו.

עבור שתי הנקודות האחרונות השתמשנו Firebase:

• שרת המאסטר של Teeworlds מיושם בצורה פשוטה מאוד: כרשימה של אובייקטים המכילים מידע (שם, IP, מפה, מצב,...) של כל שרת פעיל. שרתים מפרסמים ומעדכנים את האובייקט שלהם, ולקוחות לוקחים את כל הרשימה ומציגים אותה לנגן. אנחנו גם מציגים את הרשימה בדף הבית כ-HTML כך ששחקנים יכולים פשוט ללחוץ על השרת ולהילקח ישר למשחק.
• איתות קשור קשר הדוק ליישום השקעים שלנו, המתואר בסעיף הבא.

רשימת השרתים בתוך המשחק ובדף הבית

יישום שקעים

אנחנו רוצים ליצור API שקרוב ככל האפשר ל-Posix UDP Sockets כדי למזער את מספר השינויים הדרושים.

אנחנו גם רוצים ליישם את המינימום הנדרש לחילופי הנתונים הפשוטים ביותר ברשת.

לדוגמה, אנחנו לא צריכים ניתוב אמיתי: כל העמיתים נמצאים באותו "LAN וירטואלי" המשויך למופע מסד נתונים ספציפי של Firebase.

לכן, אנחנו לא צריכים כתובות IP ייחודיות: ערכי מפתח ייחודיים של Firebase (בדומה לשמות דומיין) מספיקים לזיהוי ייחודי של עמיתים, וכל עמית מקצה באופן מקומי כתובות IP "מזויפות" לכל מפתח שצריך לתרגם. זה מבטל לחלוטין את הצורך בהקצאת כתובת IP גלובלית, שהיא משימה לא טריוויאלית.

הנה ה-API המינימלי שאנחנו צריכים ליישם:

// Create and destroy a socket
int socket();
int close(int fd);
// Bind a socket to a port, and publish it on Firebase
int bind(int fd, AddrInfo* addr);
// Send a packet. This lazily create a WebRTC connection to the 
// peer when necessary
int sendto(int fd, uint8_t* buf, int len, const AddrInfo* addr);
// Receive the packets destined to this socket
int recvfrom(int fd, uint8_t* buf, int len, AddrInfo* addr);
// Be notified when new packets arrived
int recvCallback(Callback cb);
// Obtain a local ip address for this peer key
uint32_t resolve(client::String* key);
// Get the peer key for this ip
String* reverseResolve(uint32_t addr);
// Get the local peer key
String* local_key();
// Initialize the library with the given Firebase database and 
// WebRTc connection options
void init(client::FirebaseConfig* fb, client::RTCConfiguration* ice);

ה-API פשוט ודומה ל-Posix Sockets API, אך יש לו כמה הבדלים חשובים: רישום התקשרויות חוזרות, הקצאת כתובות IP מקומיות וחיבורים עצלים.

רישום התקשרויות חוזרות

גם אם התוכנה המקורית משתמשת ב-I/O לא חוסם, יש לשנות את הקוד להפעלה בדפדפן אינטרנט.

הסיבה לכך היא שלולאת האירועים בדפדפן מוסתרת מהתוכנה (בין אם זה JavaScript או WebAssembly).

בסביבה המקומית נוכל לכתוב קוד כזה

while(running) {
  select(...); // wait for I/O events
  while(true) {
    int r = readfrom(...); // try to read
    if (r < 0 && errno == EWOULDBLOCK) // no more data available
      break;
    ...
  }
  ...
}

אם לולאת האירוע מוסתרת לנו, אז אנחנו צריכים להפוך אותה למשהו כזה:

auto cb = []() { // this will be called when new data is available
  while(true) {
    int r = readfrom(...); // try to read
    if (r < 0 && errno == EWOULDBLOCK) // no more data available
      break;
    ...
  }
  ...
};
recvCallback(cb); // register the callback

הקצאת IP מקומית

מזהי הצומת ב"רשת" שלנו אינם כתובות IP, אלא מפתחות Firebase (אלה מחרוזות שנראות כך: -LmEC50PYZLCiCP-vqde ).

זה נוח כי אנחנו לא צריכים מנגנון להקצאת כתובות IP ובדיקת הייחודיות שלהן (כמו גם סילוקן לאחר שהלקוח מתנתק), אבל לרוב יש צורך לזהות עמיתים לפי ערך מספרי.

בדיוק בשביל זה הפונקציות משמשות. resolve и reverseResolve: האפליקציה מקבלת איכשהו את ערך המחרוזת של המפתח (באמצעות קלט משתמש או דרך השרת הראשי), ויכולה להמיר אותו לכתובת IP לשימוש פנימי. גם שאר ה-API מקבל את הערך הזה במקום מחרוזת לשם הפשטות.

זה דומה לחיפוש DNS, אך מבוצע באופן מקומי בלקוח.

כלומר, לא ניתן לשתף כתובות IP בין לקוחות שונים, ואם יש צורך במזהה גלובלי כלשהו, ​​יהיה צורך להפיק אותו בצורה אחרת.

חיבור עצלן

UDP לא צריך חיבור, אבל כפי שראינו, WebRTC דורש תהליך חיבור ארוך לפני שהוא יכול להתחיל להעביר נתונים בין שני עמיתים.

אם אנחנו רוצים לספק את אותה רמת הפשטה, (sendto/recvfrom עם עמיתים שרירותיים ללא חיבור קודם), אז עליהם לבצע חיבור "עצלן" (מעוכב) בתוך ה-API.

זה מה שקורה במהלך תקשורת רגילה בין ה"שרת" ל"לקוח" בעת שימוש ב-UDP, ומה שהספרייה שלנו צריכה לעשות:

• שיחות שרת bind()לומר למערכת ההפעלה שהיא רוצה לקבל מנות ביציאה שצוינה.

במקום זאת, נפרסם יציאה פתוחה ל-Firebase מתחת למפתח השרת ונקשיב לאירועים בתת-עץ שלו.

• שיחות שרת recvfrom(), מקבל מנות שמגיעות מכל מארח ביציאה זו.

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

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

השיחה אינה חוסמת, אז אם אין מנות, אנחנו פשוט מחזירים -1 ומגדירים errno=EWOULDBLOCK.

• הלקוח מקבל את ה-IP והיציאה של השרת באמצעים חיצוניים, ומתקשר sendto(). זה גם מבצע שיחה פנימית. bind(), ולכן לאחר מכן recvfrom() יקבל את התגובה מבלי לבצע binding במפורש.

במקרה שלנו, הלקוח מקבל מבחוץ את מפתח המחרוזת ומשתמש בפונקציה resolve() כדי לקבל כתובת IP.

בשלב זה, אנו יוזמים לחיצת יד של WebRTC אם שני העמיתים עדיין לא מחוברים זה לזה. חיבורים ליציאות שונות של אותו עמית משתמשים באותו WebRTC DataChannel.

אנחנו גם מבצעים בעקיפין bind()כדי שהשרת יוכל להתחבר מחדש בפעם הבאה sendto() למקרה שהוא נסגר מסיבה כלשהי.

השרת מקבל הודעה על החיבור של הלקוח כאשר הלקוח כותב את הצעת ה-SDP שלו מתחת למידע על יציאת השרת ב-Firebase, והשרת מגיב עם תגובתו שם.

התרשים שלהלן מציג דוגמה של זרימת הודעות עבור ערכת שקעים והעברת ההודעה הראשונה מהלקוח לשרת:

תרשים שלם של שלב החיבור בין הלקוח לשרת

מסקנה

אם קראתם עד כאן, כנראה שאתם מעוניינים לראות את התיאוריה בפעולה. ניתן לשחק במשחק teeworlds.leaningtech.com, נסה זאת!

משחק ידידות בין עמיתים

קוד ספריית הרשת זמין בחינם בכתובת GitHub. הצטרפו לשיחה בערוץ שלנו ב- רשת!

מקור: www.habr.com