פֿאַר די לעצטע צוויי וואָכן איך האָבן ארבעטן אויף די אָנליין מאָטאָר פֿאַר מיין שפּיל. איידער דעם, איך געוואוסט גאָרנישט וועגן נעטוואָרקינג אין שפּילערייַ, אַזוי איך לייענען אַ פּלאַץ פון אַרטיקלען און האט אַ פּלאַץ פון יקספּעראַמאַנץ צו פֿאַרשטיין אַלע די קאַנסעפּס און קענען צו שרייַבן מיין אייגן נעטוואָרקינג מאָטאָר.

אין דעם פירער, איך וואָלט ווי צו טיילן מיט איר די פאַרשידן קאַנסעפּס איר דאַרפֿן צו לערנען איידער איר שרייַבן דיין אייגענע שפּיל מאָטאָר, ווי געזונט ווי די בעסטער רעסורסן און אַרטיקלען צו לערנען זיי.

אין אַלגעמיין, עס זענען צוויי הויפּט טייפּס פון נעץ אַרקאַטעקטשערז: ייַנקוקנ-צו-ייַנקוקנ און קליענט-סערווער. אין אַ ייַנקוקנ-צו-ייַנקוקנ (פּ2פּ) אַרקאַטעקטשער, דאַטן זענען טראַנספערד צווישן קיין פּערז פון קאָננעקטעד פּלייַערס, בשעת אין אַ קליענט-סערווער אַרקאַטעקטשער, דאַטן זענען טראַנספערד בלויז צווישן פּלייַערס און די סערווער.

כאָטש ייַנקוקנ-צו-ייַנקוקנ אַרקאַטעקטשער איז נאָך געניצט אין עטלעכע שפּילערייַ, קליענט-סערווער איז דער נאָרמאַל: עס איז גרינגער צו ינסטרומענט, ריקווייערז אַ קלענערער קאַנאַל ברייט און מאכט עס גרינגער צו באַשיצן קעגן טשיטינג. דעריבער, אין דעם טוטאָריאַל מיר וועלן פאָקוס אויף דער קליענט-סערווער אַרקאַטעקטשער.

אין באַזונדער, מיר זענען מערסט אינטערעסירט אין אַטאָראַטעריאַן סערווערס: אין אַזאַ סיסטעמען, דער סערווער איז שטענדיק רעכט. פֿאַר בייַשפּיל, אויב אַ שפּילער מיינט אַז ער איז אין קאָואָרדאַנאַץ (10, 5), און דער סערווער דערציילט אים אַז ער איז ביי (5, 3), דער קליענט זאָל פאַרבייַטן זיין שטעלע מיט דער איינער געמאלדן דורך די סערווער, און נישט וויצע. ווערסאַ. ניצן אַטאָראַטייטיוו סערווערס מאכט עס גרינגער צו ידענטיפיצירן טשיטערס.

נעץ גיימינג סיסטעמען האָבן דריי הויפּט קאַמפּאָונאַנץ:

• אַריבערפירן פּראָטאָקאָל: ווי דאַטן זענען טראַנספערד צווישן קלייאַנץ און סערווערס.
• אַפּפּליקאַטיאָן פּראָטאָקאָל: וואָס איז טראַנסמיטטעד פון קלייאַנץ צו די סערווער און פון די סערווער צו קלייאַנץ און אין וואָס פֿאָרמאַט.
• אַפּפּליקאַטיאָן לאָגיק: ווי די טראַנספערד דאַטן זענען געניצט צו דערהייַנטיקן די שטאַט פון די קלייאַנץ און סערווערס.

עס איז זייער וויכטיק צו פֿאַרשטיין די ראָלע פון ​​יעדער טייל און די טשאַלאַנדזשיז פֿאַרבונדן מיט זיי.

אַריבערפירן פּראָטאָקאָל

דער ערשטער שריט איז צו אויסקלייַבן אַ פּראָטאָקאָל פֿאַר טראַנספּאָרטינג דאַטן צווישן די סערווער און קלייאַנץ. עס זענען צוויי אינטערנעט פּראָטאָקאָלס פֿאַר דעם: טקפּ и ודפּ. אָבער איר קענען מאַכן דיין אייגענע אַריבערפירן פּראָטאָקאָל באזירט אויף איינער פון זיי אָדער נוצן אַ ביבליאָטעק וואָס ניצט זיי.

פאַרגלייַך פון TCP און UDP

ביידע TCP און UDP זענען באזירט אויף IP. IP אַלאַוז אַ פּאַקאַט צו זיין טראַנסמיטטעד פון אַ מקור צו אַ באַקומער, אָבער טוט נישט גאַראַנטירן אַז די געשיקט פּאַקאַט וועט גיכער אָדער שפּעטער דערגרייכן דעם באַקומער, אַז עס וועט דערגרייכן עס בייַ מינדסטער אַמאָל, און אַז די סיקוואַנס פון פּאַקיץ וועט אָנקומען אין די ריכטיק סדר. דערצו, אַ פּאַקאַט קענען בלויז אַנטהאַלטן אַ לימיטעד סומע פון ​​דאַטן, געגעבן דורך מטו.

UDP איז בלויז אַ דין שיכטע אויף שפּיץ פון IP. דעריבער, עס האט די זעלבע לימיטיישאַנז. אין קאַנטראַסט, TCP האט פילע פֿעיִקייטן. עס גיט אַ פאַרלאָזלעך, אָרדערלי קשר צווישן צוויי נאָודז מיט טעות קאָנטראָלירונג. דעריבער, TCP איז זייער באַקוועם און איז געניצט אין פילע אנדערע פּראָטאָקאָלס, למשל. הטטפּ, פטפּ и סמטפּ. אָבער אַלע די פֿעיִקייטן האָבן אַ פּרייַז: פאַרהאַלטן.

צו פֿאַרשטיין וואָס די פאַנגקשאַנז קענען גרונט לייטאַנסי, מיר דאַרפֿן צו פֿאַרשטיין ווי TCP אַרבעט. ווען אַ שיקט נאָדע טראַנסמיטט אַ פּאַקאַט צו אַ ריסיווינג נאָדע, עס יקספּעקץ צו באַקומען אַ דערקענטעניש (ACK). אויב נאָך אַ געוויסע צייט עס קען נישט באַקומען עס (ווייַל די פּאַקאַט אָדער דערקענטעניש איז פאַרפאַלן, אָדער פֿאַר עטלעכע אנדערע סיבה), עס רעסענדז די פּאַקאַט. דערצו, TCP געראַנטיז אַז פּאַקיץ זענען באקומען אין די ריכטיק סדר, אַזוי ביז די פאַרפאַלן פּאַקאַט איז באקומען, אַלע אנדערע פּאַקיץ קענען ניט זיין פּראַסעסט, אפילו אויב זיי האָבן שוין באקומען דורך די ריסיווינג באַלעבאָס.

אָבער ווי איר קענען מיסטאָמע ימאַדזשאַן, לייטאַנסי אין מולטיפּלייַער שפּילערייַ איז זייער וויכטיק, ספּעציעל אין קאַמף-פּאַקט זשאַנראַז ווי FPS. דאָס איז וואָס פילע שפּילערייַ נוצן UDP מיט זייער אייגענע פּראָטאָקאָל.

א געבוירן ודפּ-באזירט פּראָטאָקאָל קענען זיין מער עפעקטיוו ווי TCP פֿאַר פאַרשידן סיבות. פֿאַר בייַשפּיל, עס קענען צייכן עטלעכע פּאַקיץ ווי טראַסטיד און אנדערע ווי אַנטראַסטיד. דעריבער, עס טוט נישט זאָרגן צי די אַנטראַסטיד פּאַקאַט ריטשאַז די באַקומער. אָדער עס קענען פּראָצעס קייפל דאַטן סטרימז אַזוי אַז אַ פאַרפאַלן פּאַקאַט אין איין טייַך קען נישט פּאַמעלעך די רוען סטרימז. פֿאַר בייַשפּיל, עס קען זיין אַ פאָדעם פֿאַר שפּילער אַרייַנשרייַב און אן אנדער פאָדעם פֿאַר שמועסן אַרטיקלען. אויב אַ שמועס אָנזאָג וואָס איז נישט דרינגלעך איז פאַרפאַלן, עס וועט נישט פּאַמעלעך די אַרייַנשרייַב וואָס איז דרינגלעך. אָדער אַ פּראַפּרייאַטערי פּראָטאָקאָל קען ינסטרומענט רילייאַבילאַטי אַנדערש ווי TCP צו זיין מער עפעקטיוו אין אַ ווידעא שפּיל סוויווע.

אַזוי, אויב TCP סאַקס אַזוי פיל, מיר וועלן מאַכן אונדזער אייגענע אַריבערפירן פּראָטאָקאָל באזירט אויף UDP?

עס איז אַ ביסל מער קאָמפּליצירט. כאָטש TCP איז כּמעט סובאָפּטימאַל פֿאַר גיימינג נעץ סיסטעמען, עס קען אַרבעט גאַנץ גוט פֿאַר דיין ספּעציפיש שפּיל און שפּאָרן איר ווערטפול צייט. למשל, לייטאַנסי קען נישט זיין אַן אַרויסגעבן פֿאַר אַ קער-באזירט שפּיל אָדער אַ שפּיל וואָס קענען זיין פּלייַעד בלויז אויף לאַן נעטוואָרקס, ווו לייטאַנסי און פּאַקאַט אָנווער זענען פיל נידעריקער ווי אויף דער אינטערנעץ.

פילע מצליח שפּילערייַ, אַרייַנגערעכנט World of Warcraft, Minecraft און Terraria, נוצן TCP. אָבער, רובֿ FPSs נוצן זייער אייגענע UDP-באזירט פּראָטאָקאָלס, אַזוי מיר וועלן רעדן מער וועגן זיי אונטן.

אויב איר באַשליסן צו נוצן TCP, מאַכן זיכער אַז עס איז פאַרקריפּלט Nagle ס אַלגערידאַם, ווייַל עס באַפערז פּאַקיץ איידער שיקט, וואָס מיטל עס ינקריסיז לייטאַנסי.

צו לערנען מער וועגן די דיפעראַנסיז צווישן UDP און TCP אין דעם קאָנטעקסט פון מולטיפּלייַער שפּילערייַ, איר קענט לייענען דעם אַרטיקל פון Glenn Fiedler UDP ווס. TCP.

אײגענעם פראטאקאל

אַזוי איר ווילן צו שאַפֿן דיין אייגענע אַריבערפירן פּראָטאָקאָל, אָבער טאָן ניט וויסן ווו צו אָנהייבן? איר האָט גליק ווייַל Glenn Fiedler האט געשריבן צוויי אַמייזינג אַרטיקלען וועגן דעם. איר וועט געפֿינען אַ פּלאַץ פון קלוג געדאנקען אין זיי.

דער ערשטער אַרטיקל נעטוואָרקינג פֿאַר שפּיל פּראָוגראַמערז 2008, גרינגער ווי די צווייטע, בויען אַ שפּיל נעטוואָרק פּראָטאָקאָל 2016. איך רעקאָמענדירן אַז איר אָנהייבן מיט די עלטערע.

באַמערקונג אַז Glenn Fiedler איז אַ גרויס פּראַפּאָונאַנט פון ניצן אַ מנהג פּראָטאָקאָל באזירט אויף UDP. און נאָך לייענען זיין אַרטיקלען, איר וועט מיסטאָמע אַדאַפּט זיין מיינונג אַז TCP האט ערנסט כיסאָרן אין ווידעא שפּילערייַ, און איר וועט וועלן צו ינסטרומענט דיין אייגענע פּראָטאָקאָל.

אָבער אויב איר ניטאָ נייַ צו נעטוואָרקינג, טאָן זיך אַ טויווע און נוצן TCP אָדער אַ ביבליאָטעק. צו הצלחה ינסטרומענט דיין אייגענע אַריבערפירן פּראָטאָקאָל, איר דאַרפֿן צו לערנען אַ פּלאַץ פריער.

נעץ לייברעריז

אויב איר דאַרפֿן עפּעס מער עפעקטיוו ווי TCP, אָבער טאָן נישט וועלן צו דורכגיין די כאַסאַל פון ימפּלאַמענינג דיין אייגענע פּראָטאָקאָל און גיין אין אַ פּלאַץ פון דעטאַל, איר קענען נוצן אַ נעטוואָרקינג ביבליאָטעק. עס זענען פילע פון ​​זיי:

• יאָדזשימבאָ גלן פידלער
• RakNet, װעלכע ר װער ט שוי ן ניש ט געשטיצט , נא ר א גאָפּל SLikeNet עס קוקט ווי עס איז נאָך אַקטיוו.
• ENet איז אַ ביבליאָטעק באשאפן פֿאַר מולטיפּלייַער FPS קוב
• שפּיל נעטוואָרקינג סאָקקעץ וואַלוו

איך האב נישט געפרוווט זיי אַלע, אָבער איך בעסער וועלן ENet ווייַל עס איז גרינג צו נוצן און פאַרלאָזלעך. אין אַדישאַן, עס האט קלאָר דאַקיומענטיישאַן און אַ טוטאָריאַל פֿאַר ביגינערז.

אַריבערפירן פּראָטאָקאָל: מסקנא

צו סאַמערייז: עס זענען צוויי הויפּט אַריבערפירן פּראָטאָקאָלס: TCP און UDP. TCP האט פילע נוציק פֿעיִקייטן: רילייאַבילאַטי, פּאַקאַט סדר פּרעזערוויישאַן, טעות דיטעקשאַן. UDP האט ניט אַלע דעם, אָבער TCP דורך זיין נאַטור האט געוואקסן לייטאַנסי, וואָס איז אַנאַקסעפּטאַבאַל פֿאַר עטלעכע שפּילערייַ. דאָס איז, צו ענשור נידעריק לייטאַנסי, איר קענען מאַכן דיין אייגענע פּראָטאָקאָל באזירט אויף UDP אָדער נוצן אַ ביבליאָטעק וואָס ימפּלאַמאַנץ אַ אַריבערפירן פּראָטאָקאָל אויף UDP און איז צוגעפאסט פֿאַר מולטיפּלייַער ווידעא שפּילערייַ.

די ברירה צווישן TCP, UDP און די ביבליאָטעק דעפּענדס אויף עטלעכע סיבות. ערשטער, פֿון די דאַרף פון די שפּיל: דאַרף עס נידעריק לייטאַנסי? צווייטנס, פֿון די אַפּלאַקיישאַן פּראָטאָקאָל רעקווירעמענץ: דאַרף עס אַ פאַרלאָזלעך פּראָטאָקאָל? ווי מיר וועלן זען אין דער ווייַטער טייל, עס איז מעגלעך צו שאַפֿן אַ אַפּלאַקיישאַן פּראָטאָקאָל פֿאַר וואָס אַ אַנטראַסטיד פּראָטאָקאָל איז גאַנץ פּאַסיק. צום סוף, איר אויך דאַרפֿן צו נעמען אין חשבון די דערפאַרונג פון די נעץ מאָטאָר דעוועלאָפּער.

איך האב צוויי עצות:

• אַבסטראַקט די אַריבערפירן פּראָטאָקאָל פון די רעשט פון די אַפּלאַקיישאַן אַזוי פיל ווי מעגלעך אַזוי אַז עס קענען זיין ריפּלייסט לייכט אָן רירייטינג אַלע די קאָד.
• דו זאלסט נישט איבער-אַפּטאַמייז. אויב איר זענט נישט אַ נעטוואָרקינג מומחה און איר זענט נישט זיכער צי איר דאַרפֿן אַ מנהג ודפּ-באזירט אַריבערפירן פּראָטאָקאָל, איר קענען אָנהייבן מיט TCP אָדער אַ ביבליאָטעק וואָס גיט רילייאַבילאַטי, און דערנאָך פּרובירן און מעסטן פאָרשטעלונג. אויב עס זענען פּראָבלעמס און איר זענט זיכער אַז די סיבה איז דער אַריבערפירן פּראָטאָקאָל, עס קען זיין צייט צו שאַפֿן דיין אייגענע אַריבערפירן פּראָטאָקאָל.

אין די סוף פון דעם טייל, איך רעקאָמענדירן איר לייענען הקדמה צו מולטיפּלייַער שפּיל פּראָגראַממינג דורך Brian Hook, וואָס קאָווערס פילע פון ​​די טעמעס דיסקאַסט דאָ.

אַפּפּליקאַטיאָן פּראָטאָקאָל

איצט אַז מיר קענען וועקסל דאַטן צווישן קלייאַנץ און סערווערס, מיר דאַרפֿן צו באַשליסן וואָס דאַטן צו אַריבערפירן און אין וואָס פֿאָרמאַט.

דער קלאַסיש סכעמע איז אַז קלייאַנץ שיקן אַרייַנשרייַב אָדער אַקשאַנז צו די סערווער, און דער סערווער סענדז די קראַנט שפּיל שטאַט צו די קלייאַנץ.

דער סערווער סענדז נישט די פול שטאַט, אָבער אַ פילטערד שטאַט מיט ענטיטיז וואָס זענען ליגן לעבן די שפּילער. ער טוט דאָס פֿאַר דרייַ סיבות. ערשטער, די גאַנץ שטאַט קען זיין צו גרויס צו זיין טראַנסמיטטעד אין הויך אָפטקייַט. צווייטנס, קלייאַנץ זענען דער הויפּט אינטערעסירט אין וויזשאַוואַל און אַודיאָ דאַטן, ווייַל רובֿ פון די שפּיל לאָגיק איז סימיאַלייטיד אויף די שפּיל סערווער. דריטנס, אין עטלעכע שפּילערייַ, דער שפּילער דאַרף נישט וויסן זיכער דאַטן, למשל די שטעלע פון ​​די פייַנט אויף די אנדערע זייַט פון די מאַפּע, אַנדערש ער קענען צושמעקן פּאַקיץ און וויסן פּונקט ווו צו רירן צו טייטן אים.

סיריאַליזאַטיאָן

דער ערשטער שריט איז צו בייַטן די דאַטן וואָס מיר ווילן צו שיקן (אַרייַן אָדער שפּיל שטאַט) אין אַ פֿאָרמאַט פּאַסיק פֿאַר טראַנסמיסיע. דעם פּראָצעס איז גערופן סיריאַליזאַטיאָן.

דער געדאַנק אַז גלייך קומט צו מיינונג איז צו נוצן אַ מענטש-לייענען פֿאָרמאַט, אַזאַ ווי JSON אָדער XML. אָבער דאָס וועט זיין גאָר יניפעקטיוו און וועט וויסט רובֿ פון די קאַנאַל.

עס איז רעקאַמענדיד צו נוצן די ביינערי פֿאָרמאַט אַנשטאָט, וואָס איז פיל מער סאָליד. אַז איז, די פּאַקיץ וועט בלויז אַנטהאַלטן אַ ביסל ביטעס. עס איז אַ פּראָבלעם צו באַטראַכטן דאָ בייט סדר, וואָס קען זיין אַנדערש אויף פאַרשידענע קאָמפּיוטערס.

צו סיריאַליזירן דאַטן, איר קענען נוצן אַ ביבליאָטעק, למשל:

• פלאַטבופפערס גוגל
• קאַפּ'ן פּראָטאָ סאַנדסטאָרם פירמע
• קאַשע שיין גראַנט און ראַנדאָלף וואָאָרהעעס

נאָר מאַכן זיכער אַז די ביבליאָטעק קריייץ פּאָרטאַטיוו אַרקייווז און זאָרגן וועגן ענדיינאַנס.

אַן אָלטערנאַטיוו לייזונג איז צו ינסטרומענט עס זיך; עס איז נישט דער הויפּט שווער, ספּעציעל אויב איר נוצן אַ דאַטן-סענטריק צוגאַנג צו דיין קאָד. אין אַדישאַן, עס וועט לאָזן איר צו דורכפירן אַפּטאַמאַזיישאַנז וואָס זענען ניט שטענדיק מעגלעך ווען איר נוצן די ביבליאָטעק.

Glenn Fiedler געשריבן צוויי אַרטיקלען וועגן סיריאַליזיישאַן: לייענען און שרייבן פּאַקאַץ и סיריאַליזאַטיאָן סטראַטעגיעס.

צוזאמקוועטשן

די סומע פון ​​דאַטן טראַנספערד צווישן קלייאַנץ און סערווערס איז לימיטעד דורך די קאַנאַל ס באַנדווידט. דאַטאַ קאַמפּרעשאַן וועט לאָזן איר צו אַריבערפירן מער דאַטן אין יעדער מאָמענטבילד, פאַרגרעסערן די דערהייַנטיקן אָפטקייַט אָדער פשוט רעדוצירן די קאַנאַל רעקווירעמענץ.

ביסל פּאַקקאַגינג

דער ערשטער טעכניק איז ביסל פּאַקינג. עס באשטייט פון ניצן פּונקט די נומער פון ביטן וואָס זענען נייטיק צו באַשרייַבן די געבעטן ווערט. פֿאַר בייַשפּיל, אויב איר האָבן אַ ענום וואָס קענען האָבן 16 פאַרשידענע וואַלועס, אַנשטאָט פון אַ גאַנץ בייט (8 ביץ), איר קענען נוצן בלויז 4 ביץ.

Glenn Fiedler דערקלערט ווי צו ינסטרומענט דעם אין די רגע טייל פון דעם אַרטיקל לייענען און שרייבן פּאַקאַץ.

ביט פּאַקינג אַרבעט ספּעציעל גוט מיט מוסטערונג, וואָס וועט זיין די טעמע פון ​​​​דער ווייַטער אָפּטיילונג.

מוסטערונג

מוסטערונג איז אַ לאָססי קאַמפּרעשאַן טעכניק וואָס ניצט בלויז אַ סאַבסעט פון מעגלעך וואַלועס צו ענקאָוד אַ ווערט. די יזיאַסט וועג צו ינסטרומענט דיסקרעטיזאַטיאָן איז דורך ראָונדינג פלאָוטינג פונט נומערן.

גלן פידלער (ווידער!) ווייזט ווי אַזוי צו פירן מוסטערונג אין זיין אַרטיקל מאָמענטבילד קאַמפּרעשאַן.

קאַמפּרעשאַן אַלגערידאַמז

דער ווייַטער טעכניק וועט זיין לאָססלעסס קאַמפּרעשאַן אַלגערידאַמז.

דאָ, אין מיין מיינונג, זענען די דריי מערסט טשיקאַווע אַלגערידאַמז איר דאַרפֿן צו וויסן:

• האפמאַן קאָדירונג מיט פאַר-קאָמפּיוטיד קאָד, וואָס איז גאָר שנעל און קענען פּראָדוצירן גוט רעזולטאַטן. עס איז געניצט צו קאָמפּרעס פּאַקיץ אין די Quake3 נעטוואָרקינג מאָטאָר.
• זליב איז אַ גענעראַל-ציל קאַמפּרעשאַן אַלגערידאַם וואָס קיינמאָל ינקריסיז די סומע פון ​​דאַטן. ווי קענען איר זען דאָ, עס איז געניצט אין אַ פאַרשיידנקייַט פון אַפּלאַקיישאַנז. עס קען זיין יבעריק פֿאַר אַפּדייטינג שטאַטן. אָבער עס קען זיין נוציק אויב איר דאַרפֿן צו שיקן אַסעץ, לאַנג טעקסטן אָדער טעריין צו קאַסטאַמערז פֿון די סערווער.
• קאַפּיינג לויפן לענגקטס - דאָס איז מיסטאָמע די סימפּלאַסט קאַמפּרעשאַן אַלגערידאַם, אָבער עס איז זייער עפעקטיוו פֿאַר זיכער טייפּס פון דאַטן, און קענען זיין געוויינט ווי אַ פאַר-פּראַסעסינג שריט איידער זליב. עס איז דער הויפּט פּאַסיק פֿאַר קאַמפּרעסינג טעריין קאַמפּאָוזד פון טיילז אָדער וואָקסאַלז אין וואָס פילע שכייניש עלעמענטן זענען ריפּיטיד.

דעלטאַ קאַמפּרעשאַן

די לעצטע קאַמפּרעשאַן טעכניק איז דעלטאַ קאַמפּרעשאַן. עס באשטייט אין דעם פאַקט אַז בלויז די דיפעראַנסיז צווישן די קראַנט שפּיל שטאַט און די לעצטע שטאַט באקומען דורך דער קליענט זענען טראַנסמיטטעד.

עס איז געווען ערשטער געניצט אין די Quake3 נעץ מאָטאָר. דאָ זענען צוויי אַרטיקלען וואָס דערקלערן ווי צו נוצן עס:

• די Quake3 נעטוואָרקינג מאָדעל ברייאַן האָאָק
• קוואַקע 3 מקור קאָוד איבערבליק: נעטוואָרק מאָדעל Fabien Sanglars [איבערזעצונג אַרטיקלען אויף Habré, זען אָפּטיילונג "נעטוואָרק מאָדעל"]

גלן פידלער האָט עס אויך גענוצט אינעם צווייטן טייל פון זיין אַרטיקל מאָמענטבילד קאַמפּרעשאַן.

ענקריפּשאַן

אין אַדישאַן, איר קען דאַרפֿן צו ענקריפּט די אַריבערפירן פון אינפֿאָרמאַציע צווישן קלייאַנץ און די סערווער. עס זענען עטלעכע סיבות פֿאַר דעם:

• פּריוואַטקייט / קאַנפאַדענשיאַלאַטי: אַרטיקלען קענען זיין לייענען בלויז דורך די באַקומער, און קיין אנדערע מענטש וואָס סניפינג די נעץ וועט קענען צו לייענען זיי.
• אָטענטאַקיישאַן: אַ מענטש וואס וויל צו שפּילן די ראָלע פון ​​אַ שפּילער מוזן וויסן זיין שליסל.
• אָפּנאַרן פאַרהיטונג: עס וועט זיין פיל מער שווער פֿאַר בייזע פּלייַערס צו שאַפֿן זייער אייגענע אָפּנאַרן פּאַקאַדזשאַז, זיי וועלן האָבן צו רעפּראָדוצירן די ענקריפּשאַן סכעמע און געפֿינען די שליסל (וואָס ענדערונגען מיט יעדער קשר).

איך שטארק רעקאָמענדירן ניצן אַ ביבליאָטעק פֿאַר דעם. איך פֿאָרשלאָגן ניצן ליבסאָדיום, ווייַל עס איז ספּעציעל פּשוט און האט ויסגעצייכנט טוטאָריאַלז. ספּעציעל טשיקאַווע איז די טוטאָריאַל אויף שליסל וועקסל, וואָס אַלאַוז איר צו דזשענערייט נייַע שליסלען מיט יעדער נייַע קשר.

אַפּפּליקאַטיאָן פּראָטאָקאָל: מסקנא

דאָס ענדיקט אונדזער אַפּלאַקיישאַן פּראָטאָקאָל. איך גלויבן אַז קאַמפּרעשאַן איז גאָר אַפּשאַנאַל און דער באַשלוס צו נוצן עס דעפּענדס בלויז אויף די שפּיל און די פארלאנגט באַנדווידט. ענקריפּשאַן, אין מיין מיינונג, איז מאַנדאַטאָרי, אָבער אין דער ערשטער פּראָוטאַטייפּ איר קענען טאָן אָן עס.

אַפּפּליקאַטיאָן לאָגיק

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

דערצו, צווישן צוויי שטאַט דערהייַנטיקונגען, די וועלט איז גאָר סטאַטיק. אויב די שטאַט דערהייַנטיקן קורס איז נידעריק, די מווומאַנץ וועט זיין זייער דזשערקי.

עס זענען עטלעכע טעקניקס צו רעדוצירן די פּראַל פון דעם פּראָבלעם, און איך וועט דעקן זיי אין דער ווייַטער אָפּטיילונג.

לייטאַנס סמאָאָטהינג טעקניקס

אַלע טעקניקס דיסקרייבד אין דעם אָפּטיילונג זענען דיסקאַסט אין דעטאַל אין די סעריע שנעל-פּייסט מולטיפּלייַער גאַבריעל גאַמבעטאַ. איך רעקאָמענדירן לייענען דעם ויסגעצייכנט סעריע פון ​​אַרטיקלען. עס אויך כולל אַן ינטעראַקטיוו דעמאָ וואָס אַלאַוז איר צו זען ווי די טעקניקס אַרבעט אין פיר.

דער ערשטער טעכניק איז צו צולייגן די אַרייַנשרייַב רעזולטאַט גלייַך אָן ווארטן פֿאַר אַ ענטפער פון די סערווער. עס איז גערופן קליענט-זייַט פאָרויסזאָגן. אָבער, ווען דער קליענט באקומט אַ דערהייַנטיקן פון די סערווער, עס מוזן באַשטעטיקן אַז זיין פּראָגנאָז איז ריכטיק. אויב דאָס איז נישט דער פאַל, דעמאָלט ער נאָר דאַרפֿן צו טוישן זיין שטאַט לויט וואָס ער באקומען פון די סערווער, ווייַל דער סערווער איז אַטאָראַטעריאַן. די טעכניק איז געווען ערשטער געניצט אין קוואַקע. איר קענען לייענען מער וועגן אים אין דעם אַרטיקל קוואַקע ענגינע קאָד רעצענזיע Fabien Sanglars [איבערזעצונג אויף Habré].

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

די לעצטע, מערסט אַוואַנסירטע טעכניק נוציק בלויז אין FPS איז אָפּשטיי פאַרגיטיקונג. ווען איר נוצן אָפּשטיי פאַרגיטיקונג, דער סערווער נעמט אין חשבון די דילייז פון דעם קליענט ווען ער שוץ אויף די ציל. פֿאַר בייַשפּיל, אויב אַ שפּילער האָט דורכגעקאָכט אַ העאַדשאָט אויף זייער פאַרשטעלן, אָבער אין פאַקט, זייער ציל איז געווען אין אַ אַנדערש אָרט רעכט צו פאַרהאַלטן, עס וואָלט זיין ומיוישערדיק צו לייקענען די שפּילער די רעכט צו טייטן רעכט צו פאַרהאַלטן. דעריבער, דער סערווער ריוויינדז די צייט צוריק צו דעם מאָמענט ווען די שפּילער פייערד צו סימולירן וואָס די שפּילער געזען אויף זייער פאַרשטעלן און קאָנטראָלירן פֿאַר אַ צונויפשטויס צווישן זייער שאָס און די ציל.

גלן פידלער (ווי שטענדיק!) האָט געשריבן אַן אַרטיקל אין 2004 נעץ פיזיק (2004), אין וואָס ער געלייגט דעם יסוד פֿאַר סינגקראַנאַזיישאַן פון פיזיק סימיאַליישאַנז צווישן סערווער און קליענט. אין 2014 האָט ער אָנגעשריבן אַ נײַע סעריע אַרטיקלען נעטוואָרקינג פיזיק, וואָס דיסקרייבד אנדערע טעקניקס פֿאַר סינגקראַנאַזיישאַן פון פיזיק סימיאַליישאַנז.

עס זענען אויך צוויי אַרטיקלען אויף די וואַלוו וויקי, מקור מולטיפּלייַער נעטוואָרקינג и לייטאַנס קאַמפּאַנסייטינג מעטהאָדס אין קליענט / סערווער אין-שפּיל פּראָטאָקאָל פּלאַן און אָפּטימיזאַטיאָן וואָס באַטראַכטן פאַרגיטיקונג פֿאַר דילייז.

פּרעווענטינג טשיטינג

עס זענען צוויי הויפּט טעקניקס פֿאַר פּרעווענטינג טשיטינג.

ערשטער: מאכן עס מער שווער פֿאַר טשיטערז צו שיקן בייזע פּאַקיץ. ווי דערמאנט אויבן, אַ גוט וועג צו ינסטרומענט דעם איז ענקריפּשאַן.

רגע: אַ אַטאָראַטעריאַן סערווער זאָל נאָר באַקומען קאַמאַנדז / אַרייַנשרייַב / אַקשאַנז. דער קליענט זאָל נישט קענען צו טוישן די שטאַט אויף די סערווער אנדערע ווי דורך שיקן אַרייַנשרייַב. דערנאָך, יעדער מאָל ווען דער סערווער באקומט אַרייַנשרייַב, עס מוזן קאָנטראָלירן צי עס איז גילטיק איידער איר נוצן עס.

אַפּפּליקאַטיאָן לאָגיק: מסקנא

איך רעקאָמענדירן אַז איר ינסטרומענט אַ וועג צו סימולירן הויך לייטאַנסיז און נידעריק דערפרישן רייץ אַזוי אַז איר קענען פּרובירן די נאַטור פון דיין שפּיל אין נעבעך טנאָים, אפילו ווען דער קליענט און סערווער לויפן אויף דער זעלביקער קאָמפּיוטער. דעם וועט זייער פאַרפּאָשעטערן די ימפּלאַמענטיישאַן פון פאַרהאַלטן סמודינג טעקניקס.

אנדערע נוציק רעסורסן

אויב איר ווילט צו ויספאָרשן אנדערע רעסורסן אויף נעץ מאָדעלס, איר קענען געפֿינען זיי דאָ:

• Glenn Fiedler ס בלאָג - זיין גאנצע בלאָג איז ווערט לייענען, עס זענען פילע גרויס אַרטיקלען דאָרט. דאָ אַלע אַרטיקלען אויף נעץ טעקנאַלאַדזשיז זענען געזאמלט.
• אָסאַם שפּיל נעטוואָרקינג דורך M. Fatih MAR איז אַ פולשטענדיק רשימה פון אַרטיקלען און ווידיאס אויף אָנליין ווידעא שפּיל ענדזשאַנז.
• В וויקי פון די r/gamedev סוברעדדיט עס זענען אויך פילע נוציק לינקס.

מקור: www.habr.com