משחקי ענן בקוד פתוח ב-WebRTC: p2p, מרובה משתתפים, אפס השהייה

תוכנה כשירות, תשתית כשירות, פלטפורמה כשירות, פלטפורמת תקשורת כשירות, ועידות וידאו כשירות, מה לגבי משחקי ענן כשירות? כבר היו מספר ניסיונות ליצור משחקי ענן (Cloud Gaming), כמו Stadia, שהושקה לאחרונה על ידי גוגל. סטדיה לא חדש ב-WebRTC, אבל האם אחרים יכולים להשתמש ב-WebRTC באותו אופן?

Thanh Nguyen החליט לבדוק את ההזדמנות הזו בפרויקט הקוד הפתוח שלו CloudRetro. CloudRetro מבוסס על פיון, פופולרי ספריית WebRTC מבוססת על Go (תודה מוצג מצוות הפיתוח של Pion על סיועם בהכנת מאמר זה). במאמר זה, Thanh מספק סקירה כללית של הארכיטקטורה של הפרויקט שלו, וגם מדבר על אילו דברים שימושיים הוא למד ואילו אתגרים הוא נתקל במהלך עבודתו.

כניסה

בשנה שעברה, כשגוגל הכריזה על סטאדיה, זה הצחיק אותי. הרעיון כל כך ייחודי וחדשני שכל הזמן תהיתי איך זה בכלל אפשרי עם הטכנולוגיה הקיימת. הרצון להבין טוב יותר את הנושא הזה הניע אותי ליצור גרסה משלי למשחק ענן בקוד פתוח. התוצאה הייתה פשוט פנטסטית. להלן אני רוצה לשתף בתהליך העבודה על השנה שלי פּרוֹיֶקט.

TLDR: גרסת שקופיות קצרות עם דגשים

מדוע משחקי ענן הם העתיד

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

Google Stadia בעצם מאפשר לך לשחק משחקי AAA (כלומר משחקי שוברי קופות מתקדמים) בממשק כמו יוטיוב. ניתן ליישם את אותה מתודולוגיה על יישומים לא מקוונים כבדים אחרים כגון מערכת הפעלה או עיצוב גרפי דו-ממדי/תלת-ממדי וכו'. כדי שנוכל להפעיל אותם באופן עקבי במכשירים בעלי מפרט נמוך על פני מספר פלטפורמות.

העתיד של טכנולוגיה זו: תאר לעצמך אם Microsoft Windows 10 פעל על דפדפן כרום?

משחק בענן הוא מאתגר מבחינה טכנית

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

תבנית משחק ענן כללי

פרויקט קוד פתוח CloudRetro

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

פרויקט CloudRetro.io הוא שירות משחקי ענן בקוד פתוח למשחקי רטרו. מטרת הפרויקט היא להביא את חווית המשחק הנוחה ביותר למשחקי רטרו מסורתיים ולהוסיף מרובה משתתפים.
תוכל ללמוד עוד על הפרויקט כאן: https://github.com/giongto35/cloud-game.

פונקציונליות CloudRetro

CloudRetro משתמש במשחקי רטרו כדי להדגים את הכוח של משחקי ענן. מה שמאפשר לך לקבל חוויות משחק ייחודיות רבות.

• ניידות המשחק
  • השמעה מיידית בעת פתיחת עמוד; אין צורך בהורדה או התקנה
  • עובד בדפדפן נייד, כך שאין צורך בתוכנה כדי להפעיל אותו

• ניתן לשתף הפעלות משחק על פני מספר מכשירים ולאחסן בענן לפעם הבאה שתתחבר
• ניתן להזרים את המשחק או לשחק בו על ידי מספר משתמשים בו-זמנית:
  • משחק המונים כמו TwitchPlayPokemon, רק יותר חוצה פלטפורמות ויותר בזמן אמת
  • משחקים לא מקוונים באינטרנט. משתמשים רבים יכולים לשחק מבלי להגדיר רשת. כעת ניתן לשחק Samurai Shodown על ידי 2 שחקנים ברשת CloudRetro

  
  גרסת הדגמה של משחק מרובה משתתפים מקוון במכשירים שונים

  תשתית

  דרישות וערימת טכנולוגיה

  להלן רשימת הדרישות שהצבתי לפני תחילת הפרויקט.

  1. שחקן אחד
  הדרישה הזו אולי לא נראית חשובה או ברורה מדי כאן, אבל היא אחת מנקודות המפתח שלי, היא מאפשרת לגיימינג בענן להתרחק ככל האפשר משירותי סטרימינג מסורתיים. אם נתמקד במשחק של שחקן יחיד, נוכל להיפטר משרת מרכזי או CDN כי אנחנו לא צריכים להזרים להמונים. במקום להעלות זרמים לשרת סינק או העברת מנות לשרת WebSocket מרכזי, זרמי שירות מועברים ישירות למשתמש באמצעות חיבור WebRTC עמית לעמית.

  2. זרם מדיה עם חביון נמוך
  כשקוראים על Stadia, אני רואה לעתים קרובות את WebRTC מוזכר בכמה מאמרים. הבנתי ש-WebRTC היא טכנולוגיה יוצאת דופן והיא מושלמת לשימוש במשחקי ענן. WebRTC הוא פרויקט המספק לדפדפני אינטרנט ויישומים ניידים תקשורת בזמן אמת באמצעות ממשק API פשוט. הוא מספק קישוריות עמית לעמית, מותאם למדיה, וכולל קודקים סטנדרטיים מובנים כגון VP8 ו-H264.

  העדפתי להבטיח את חווית המשתמש הטובה ביותר האפשרית על פני שמירה על גרפיקה באיכות גבוהה. כמה הפסדים מקובלים באלגוריתם. ל-Google Stadia יש שלב נוסף של הקטנת גודל התמונה בשרת, והפריים מוגדלים לאיכות גבוהה יותר לפני שהם משודרים לעמיתים.

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

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

  5. הפרדה ברורה של ממשק המשחק והשירות
  אני רואה את שירות המשחקים בענן כפלטפורמה. כל אחד צריך להיות מסוגל לחבר כל דבר לפלטפורמה. עכשיו השתלבתי LibRetro עם שירות משחקי ענן כי LibRetro מציע ממשק אמולטור משחק יפהפה למשחקי רטרו כגון SNES, GBA, PS.

  6. חדרים לרב משתתפים, משחק קהל וקישור חיצוני (עמוק) עם המשחק
  CloudRetro תומך במשחקים חדשים רבים כגון CrowdPlay ו-MultiPlayer מקוון עבור משחקי רטרו. אם מספר משתמשים יפתחו את אותו קישור עמוק במחשבים שונים, הם יראו את אותו משחק פועל ואף יוכלו להצטרף אליו.

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

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

  8. אין חיבור לענן אחד
  התשתית של CloudRetro מתארחת אצל ספקי ענן שונים (Digital Ocean, Alibaba, ספק מותאם אישית) עבור אזורים שונים. אני מאפשר הפעלה בקונטיינר של Docker עבור התשתית ומגדיר את הגדרות הרשת באמצעות סקריפט bash כדי להימנע מנעילת ספק ענן יחיד. על ידי שילוב זה עם NAT Traversal ב-WebRTC, אנו יכולים לקבל את הגמישות לפרוס את CloudRetro על כל פלטפורמת ענן ואפילו על מחשבים של כל משתמש.

  עיצוב אדריכלי

  עוֹבֵד: (או שרת הסטרימינג שהוזכר לעיל) מכפיל את המשחקים, מפעיל את צינור הקידוד ומזרים את המדיה המקודדת למשתמשים. מופעי עובדים מופצים ברחבי העולם, וכל עובד יכול לטפל במספר הפעלות של משתמשים בו-זמנית.

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

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

  
  ארכיטקטורה ברמה העליונה של CloudRetro

  סקריפט מותאם אישית

  כאשר משתמש חדש פותח את CloudRetro בשלבים 1 ו-2 המוצגים באיור למטה, הרכז יחד עם רשימת העובדים הזמינים מתבקש לעמוד הראשון. לאחר מכן, בשלב 3 הלקוח מחשב את העיכובים עבור כל המועמדים באמצעות בקשת פינג HTTP. רשימת העיכובים הזו נשלחת לאחר מכן חזרה לרכז כדי שיוכל לקבוע את העובד המתאים ביותר לשרת את המשתמש. שלב 4 להלן יוצר את המשחק. נוצר חיבור סטרימינג של WebRTC בין המשתמש לעובד שהוקצה.
  
  סקריפט משתמש לאחר קבלת גישה

  מה יש בתוך העובד

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

  
  אינטראקציה של מרכיבי עובד

  רכיבים עיקריים:

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

  Реализация

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

  WebRTC

  WebRTC נועד לספק חיבורי עמית לעמית באיכות גבוהה באפליקציות ודפדפנים מקוריים לנייד באמצעות ממשקי API פשוטים.

  מעבר NAT

  WebRTC ידועה בפונקציונליות ה-NAT Traversal שלה. WebRTC מיועד לתקשורת עמית לעמית. מטרתו היא למצוא את המסלול הישיר המתאים ביותר, הימנעות משערי NAT ​​וחומות אש לתקשורת עמית לעמית באמצעות תהליך הנקרא קרח. כחלק מתהליך זה, ממשקי ה-API של WebRTC מוצאים את כתובת ה-IP הציבורית שלך באמצעות שרתי STUN ומעבירים אותה לשרת הממסר (תור) כאשר לא ניתן ליצור חיבור ישיר.

  עם זאת, CloudRetro אינו מנצל תכונה זו במלואה. חיבורי ה-peer-to-peer שלו אינם קיימים בין משתמשים, אלא בין משתמשים לשרתי ענן. בצד השרת של הדגם יש פחות הגבלות תקשורת ישירה מאשר מכשיר משתמש טיפוסי. זה מאפשר לך לפתוח מראש יציאות נכנסות או להשתמש ישירות בכתובות IP ציבוריות, מכיוון שהשרת אינו מאחורי NAT.

  בעבר רציתי להפוך את הפרויקט לפלטפורמת הפצת משחקים עבור Cloud Gaming. הרעיון היה לאפשר ליוצרי משחקים לספק משחקים ומשאבי סטרימינג. ומשתמשים יתקשרו ישירות עם ספקים. באופן מבוזר זה, CloudRetro הוא רק מסגרת לחיבור משאבי סטרימינג של צד שלישי למשתמשים, מה שהופך אותה לניתנת להרחבה כאשר היא כבר לא מתארחת. התפקיד של WebRTC NAT Traversal כאן חשוב מאוד כדי להקל על אתחול חיבור עמית לעמית במשאבי סטרימינג של צד שלישי, מה שמקל על היוצר להתחבר לרשת.

  דחיסת וידאו

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

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

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

  
  השוואה של מסגרות וידאו באמצעות Pacman כדוגמה

  דחיסת אודיו

  באופן דומה, אלגוריתם דחיסת השמע משמיט נתונים שלא ניתן לתפוס על ידי בני אדם. Opus הוא כרגע קודק האודיו בעל הביצועים הטובים ביותר. הוא נועד לשדר גל שמע על פרוטוקול דאטהגרם מסודר כגון RTP (Real Time Transport Protocol). זמן ההשהיה שלו נמוך מ-mp3 ו-aac, והאיכות גבוהה יותר. השהיה בדרך כלל בסביבות 5~66,5ms.

  Pion, WebRTC בגולנג

  פיון הוא פרויקט קוד פתוח שמביא את WebRTC לגולאנג. במקום המעטפת הרגילה של ספריות C++ WebRTC מקוריות, Pion היא יישום מקורי של Golang של WebRTC עם ביצועים טובים יותר, שילוב Go ובקרת גרסאות בפרוטוקולי WebRTC.

  הספרייה גם מאפשרת סטרימינג עם הרבה מובנים מובנים עם חביון של תת-שנייה. יש לו יישום משלו של STUN, DTLS, SCTP וכו '. וכמה ניסויים עם QUIC ו-WebAssembly. ספריית הקוד הפתוח הזו עצמה היא משאב למידה ממש טוב עם תיעוד מעולה, הטמעות של פרוטוקול רשת ודוגמאות מגניבות.

  קהילת Pion, בראשות יוצר נלהב מאוד, תוססת למדי, עם הרבה דיונים איכותיים שמתקיימים על WebRTC. אם אתה מעוניין בטכנולוגיה זו, הצטרף http://pion.ly/slack - תלמדו הרבה דברים חדשים.

  כתיבת CloudRetro בגולנג

  
  הטמעת עובד בגו

  עבור לערוצים בפעולה

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

  func (e *gameEmulator) gameUpdate() {
  for {
  	select {
  		case <-e.saveOperation:
  			e.saveGameState()
  		case key := <-e.input:
  			e.updateGameState(key)
  		case <-e.done:
  			e.close()
  			return
  	}
      }
  }

  מאוורר פנימה / מניפה החוצה

  תבנית Golang זו מתאימה באופן מושלם למקרה השימוש שלי ב-CrowdPlay ו-Multiple Player. לפי דפוס זה, כל כניסות המשתמש בחדר אחד מובנות בערוץ הכניסה המרכזי. מדיית המשחק נפרסת לאחר מכן לכל המשתמשים באותו חדר. בדרך זו, אנו משיגים את חלוקת מצב המשחק בין מספר הפעלות משחק של משתמשים שונים.

  
  סנכרון בין הפעלות שונות

  חסרונות של גולנג

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

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

  שֵׁן

  הפרויקט משתמש בספריית הקוד הפתוח הקיימת Golang VP8/H264 עבור דחיסת מדיה ו-Libretro עבור אמולטורים של משחקים. כל הספריות הללו הן פשוט עטיפות של ספריית C בשימוש ב-Go שֵׁן. חלק מהחסרונות מפורטים ב פוסט זה של דייב צ'ייני. בעיות שנתקלתי בהן:

  • חוסר יכולת לתפוס התרסקות ב-CGO, אפילו עם Golang RecoveryCrash;
  • כישלון בזיהוי צווארי בקבוק בביצועים כאשר איננו מסוגלים לזהות בעיות מפורטות ב-CGO.

  מסקנה

  השגתי את המטרה שלי להבין שירותי משחק בענן וליצור פלטפורמה שעוזרת לי לשחק משחקי רטרו נוסטלגיים עם החברים שלי באינטרנט. פרויקט זה לא היה מתאפשר ללא ספריית פיון ותמיכת קהילת פיון. אני אסיר תודה על ההתפתחות האינטנסיבית שלו. ממשקי ה-API הפשוטים שסופקו על ידי WebRTC ו-Pion הבטיחו אינטגרציה חלקה. ההוכחה הראשונה שלי לקונספט שוחררה באותו שבוע, למרות שלא היה לי ידע מוקדם בתקשורת עמית לעמית (P2P).

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

  CloudRetro עונה על כל מקרי השימוש שציפיתי להם מנקודת המבט שלי בתור גיימר רטרו. עם זאת, אני חושב שיש הרבה תחומים בפרויקט שאני יכול לשפר, כמו הפיכת הרשת ליותר אמינה וביצועית, מתן גרפיקת משחק באיכות גבוהה יותר, או היכולת לשתף משחקים בין משתמשים. אני עובד קשה על זה. עקוב בבקשה פּרוֹיֶקט ותתמוך בו אם אתה אוהב את זה.

מקור: www.habr.com