Сүүлийн хоёр долоо хоногийн турш би тоглоомондоо зориулж онлайн хөдөлгүүр дээр ажиллаж байна. Үүнээс өмнө би тоглоомын сүлжээний талаар огт мэддэггүй байсан тул бүх ойлголтыг ойлгож, өөрийн сүлжээний хөдөлгүүрийг бичих чадвартай болохын тулд маш олон нийтлэл уншиж, олон туршилт хийсэн.
Энэхүү гарын авлагад би та бүхэнтэй өөрийн тоглоомын хөдөлгүүрээ бичихээсээ өмнө сурах хэрэгтэй янз бүрийн ухагдахуунууд болон тэдгээрийг сурах хамгийн сайн эх сурвалж, нийтлэлүүдийг хуваалцахыг хүсч байна.
Ерөнхийдөө сүлжээний архитектурын хоёр үндсэн төрөл байдаг: peer-to-peer ба клиент-сервер. Peer-to-peer (p2p) архитектурт өгөгдөл нь холбогдсон дурын хос тоглогчдын хооронд дамждаг бол клиент-серверийн архитектурт өгөгдөл зөвхөн тоглогч болон серверийн хооронд дамждаг.
Хэдийгээр үе тэнгийн архитектур нь зарим тоглоомд ашиглагдаж байгаа ч клиент-сервер нь стандарт юм: хэрэгжүүлэхэд хялбар, бага сувгийн өргөн шаарддаг, хууран мэхлэхээс хамгаалахад хялбар болгодог. Тиймээс энэ зааварт бид үйлчлүүлэгч-серверийн архитектурт анхаарлаа хандуулах болно.
Ялангуяа бид авторитар серверүүдийг хамгийн их сонирхдог: ийм системд сервер үргэлж зөв байдаг. Жишээлбэл, хэрэв тоглогч өөрийгөө координат (10, 5) дээр байгаа гэж бодож, сервер түүнд (5, 3) байгаа гэж хэлбэл, үйлчлүүлэгч өөрийн байрлалыг серверийн мэдээлсэн байрлалаар солих ёстой, харин дэд зүйл биш. эсрэгээр. Эрх мэдэл бүхий серверүүдийг ашиглах нь хууран мэхлэгчдийг илрүүлэхэд хялбар болгодог.
Сүлжээний тоглоомын систем нь гурван үндсэн бүрэлдэхүүн хэсэгтэй.
- Тээврийн протокол: үйлчлүүлэгч болон серверийн хооронд өгөгдөл хэрхэн дамждаг.
- Хэрэглээний протокол: үйлчлүүлэгчээс сервер рүү, серверээс үйлчлүүлэгч рүү юу, ямар форматаар дамждаг.
- Програмын логик: шилжүүлсэн өгөгдлийг үйлчлүүлэгч болон серверийн төлөвийг шинэчлэхэд хэрхэн ашигладаг.
Хэсэг бүрийн үүрэг, тэдгээртэй холбоотой бэрхшээлүүдийг ойлгох нь маш чухал юм.
Тээврийн протокол
Эхний алхам бол сервер болон үйлчлүүлэгчдийн хооронд өгөгдөл дамжуулах протоколыг сонгох явдал юм. Үүний тулд хоёр интернет протокол байдаг: и . Гэхдээ та тэдгээрийн аль нэгэнд тулгуурлан өөрийн тээврийн протокол үүсгэж эсвэл тэдгээрийг ашигладаг номын санг ашиглаж болно.
TCP болон UDP-ийн харьцуулалт
TCP болон UDP аль аль нь дээр суурилдаг . IP нь пакетыг эх сурвалжаас хүлээн авагч руу дамжуулах боломжийг олгодог боловч илгээсэн пакет эрт орой хэзээ нэгэн цагт хүлээн авагчид хүрч, дор хаяж нэг удаа хүрч, багцын дараалал зөв байх болно гэдгийг баталгаажуулдаггүй. захиалга. Түүнчлэн, багц нь зөвхөн утгаараа өгөгдсөн хязгаарлагдмал хэмжээний өгөгдлийг агуулж болно .
UDP бол зүгээр л IP дээр байдаг нимгэн давхарга юм. Тиймээс энэ нь ижил хязгаарлалттай байдаг. Үүний эсрэгээр TCP нь олон онцлог шинж чанартай байдаг. Энэ нь алдаа шалгах хоёр зангилааны хооронд найдвартай, эмх цэгцтэй холболтыг хангадаг. Тиймээс TCP нь маш тохиромжтой бөгөөд бусад олон протоколуудад ашиглагддаг, жишээлбэл. , и . Гэхдээ эдгээр бүх боломжууд үнээр ирдэг: .
Эдгээр функцууд яагаад хоцрогдол үүсгэж болохыг ойлгохын тулд TCP хэрхэн ажилладагийг ойлгох хэрэгтэй. Илгээх зангилаа нь хүлээн авагч зангилаа руу пакет дамжуулах үед энэ нь хүлээн зөвшөөрөгдсөн (ACK) хүлээн авна гэж найдаж байна. Хэрэв тодорхой хугацааны дараа тэр үүнийг хүлээж авахгүй бол (багц эсвэл хүлээн авалт алдагдсан эсвэл өөр шалтгааны улмаас) пакетыг дахин илгээнэ. Түүнчлэн, TCP нь пакетуудыг зөв дарааллаар хүлээн авахыг баталгаажуулдаг тул алдагдсан пакет хүлээн авах хүртэл хүлээн авагч хост хүлээн авсан байсан ч бусад бүх пакетуудыг боловсруулах боломжгүй.
Гэхдээ таны төсөөлж байгаачлан олон тоглогчтой тоглоомын хоцролт, ялангуяа FPS гэх мэт адал явдалт төрөлд маш чухал байдаг. Тийм ч учраас олон тоглоом UDP-г өөрийн протоколоор ашигладаг.
Төрөл бүрийн шалтгааны улмаас UDP-д суурилсан протокол нь TCP-ээс илүү үр дүнтэй байж болно. Жишээлбэл, энэ нь зарим пакетуудыг итгэмжлэгдсэн, заримыг нь найдваргүй гэж тэмдэглэж болно. Тиймээс, найдваргүй пакет хүлээн авагчид хүрэх эсэх нь хамаагүй. Эсвэл энэ нь олон өгөгдлийн урсгалыг боловсруулах боломжтой бөгөөд ингэснээр нэг урсгал дахь алдагдсан пакет үлдсэн дамжуулалтыг удаашруулахгүй. Жишээлбэл, тоглогчийн оролт, чатын мессежийн өөр хэлхээ байж болно. Яаралтай биш чатын мессеж алга болсон тохиолдолд яаралтай оруулахыг удаашруулахгүй. Эсвэл өмчлөлийн протокол нь видео тоглоомын орчинд илүү үр дүнтэй байхын тулд найдвартай байдлыг TCP-ээс өөрөөр хэрэгжүүлж болно.
Тэгэхээр, хэрэв TCP маш их сордог бол бид UDP дээр суурилсан тээврийн протоколыг бий болгох уу?
Энэ нь арай илүү төвөгтэй юм. Хэдийгээр TCP нь тоглоомын сүлжээний системд бараг тохиромжгүй байдаг ч энэ нь таны тодорхой тоглоомд маш сайн ажиллаж, үнэ цэнэтэй цагийг хэмнэх болно. Жишээлбэл, ээлжинд суурилсан тоглоом эсвэл зөвхөн LAN сүлжээнд тоглох боломжтой тоглоомын хоцролт, багцын алдагдал нь интернетээс хамаагүй бага байдаг тоглоомын хувьд асуудал биш байж болно.
World of Warcraft, Minecraft, Terraria зэрэг олон амжилттай тоглоомууд TCP ашигладаг. Гэсэн хэдий ч ихэнх FPS-ууд өөрсдийн UDP-д суурилсан протоколуудыг ашигладаг тул бид тэдгээрийн талаар доор дэлгэрэнгүй ярих болно.
Хэрэв та TCP ашиглахаар шийдсэн бол үүнийг идэвхгүй болгосон эсэхийг шалгаарай , учир нь илгээхээсээ өмнө пакетуудыг буфер болгодог бөгөөд энэ нь хоцролтыг нэмэгдүүлдэг гэсэн үг юм.
Олон тоглогчтой тоглоомын хүрээнд UDP ба TCP хоёрын ялгааны талаар илүү ихийг мэдэхийг хүсвэл Гленн Фидлерийн нийтлэлийг уншиж болно. .
Өөрийн гэсэн протокол
Тиймээс та өөрийн тээврийн протокол үүсгэхийг хүсч байгаа ч хаанаас эхлэхээ мэдэхгүй байна уу? Гленн Фидлер энэ талаар хоёр гайхалтай нийтлэл бичсэн тул та азтай байна. Тэднээс та маш олон ухаалаг бодлыг олох болно.
Эхний нийтлэл 2008 он, хоёр дахь нь илүү хялбар, 2016 он. Би танд хуучин нэгээс нь эхлэхийг зөвлөж байна.
Гленн Фидлер бол UDP дээр суурилсан тусгай протоколыг ашиглах томоохон дэмжигч гэдгийг анхаарна уу. Түүний нийтлэлүүдийг уншсаны дараа та TCP нь видео тоглоомуудад ноцтой дутагдалтай гэсэн түүний үзэл бодлыг хүлээн зөвшөөрч, өөрийн протоколыг хэрэгжүүлэхийг хүсэх болно.
Гэхдээ хэрэв та сүлжээнд шинээр орж байгаа бол өөртөө сайн зүйл хийж, TCP эсвэл номын санг ашигла. Өөрийн тээврийн протоколыг амжилттай хэрэгжүүлэхийн тулд та өмнө нь маш их зүйлийг сурах хэрэгтэй.
Сүлжээний сангууд
Хэрэв танд TCP-ээс илүү үр дүнтэй зүйл хэрэгтэй байгаа ч өөрийн протоколыг хэрэгжүүлэх, нарийн ширийн зүйлд орохыг хүсэхгүй байгаа бол сүлжээний номын санг ашиглаж болно. Тэд маш олон байдаг:
- Гленн Фидлер
- , энэ нь цаашид дэмжигдэхгүй, харин түүний сэрээ Энэ нь идэвхтэй хэвээр байх шиг байна.
- нь олон тоглогчийн FPS-д зориулагдсан номын сан юм
- Хавхлага
Би бүгдийг нь туршиж үзээгүй ч хэрэглэхэд хялбар, найдвартай учраас ENet-ийг илүүд үздэг. Нэмж дурдахад энэ нь тодорхой баримт бичиг, эхлэгчдэд зориулсан зааварчилгаатай.
Тээврийн протокол: Дүгнэлт
Дүгнэж хэлэхэд: TCP ба UDP гэсэн хоёр үндсэн тээврийн протокол байдаг. TCP нь олон ашигтай шинж чанартай байдаг: найдвартай байдал, багцын дарааллыг хадгалах, алдаа илрүүлэх. UDP-д энэ бүхэн байхгүй, гэхдээ TCP нь мөн чанараараа хоцролтыг ихэсгэсэн бөгөөд энэ нь зарим тоглоомын хувьд хүлээн зөвшөөрөгдөхгүй юм. Өөрөөр хэлбэл, бага хоцрогдолтой байлгахын тулд та UDP дээр суурилсан өөрийн протокол үүсгэх эсвэл UDP дээр тээврийн протокол хэрэгжүүлдэг, олон тоглогчийн видео тоглоомд тохирсон номын санг ашиглаж болно.
TCP, UDP болон номын сангийн хоорондох сонголт нь хэд хэдэн хүчин зүйлээс хамаарна. Нэгдүгээрт, тоглоомын хэрэгцээ шаардлагаас: түүнд бага хоцрогдол хэрэгтэй юу? Хоёрдугаарт, хэрэглээний протоколын шаардлагаас: найдвартай протокол хэрэгтэй юу? Бид дараагийн хэсэгт үзэх болно, энэ нь найдваргүй протокол нь нэлээд тохиромжтой програмын протокол үүсгэх боломжтой юм. Эцэст нь та сүлжээний хөдөлгүүр хөгжүүлэгчийн туршлагыг анхаарч үзэх хэрэгтэй.
Надад хоёр зөвлөгөө байна:
- Бүх кодыг дахин бичихгүйгээр хялбархан сольж болохын тулд бусад програмаас тээврийн протоколыг аль болох товчил.
- Хэт оновчтой болгох хэрэггүй. Хэрэв та сүлжээний мэргэжилтэн биш бөгөөд танд UDP-д суурилсан тээврийн протокол хэрэгтэй эсэхээ мэдэхгүй байгаа бол TCP эсвэл найдвартай байдлыг хангадаг номын сангаас эхэлж, гүйцэтгэлийг шалгаж, хэмжиж болно. Хэрэв асуудал үүсч, шалтгаан нь тээврийн протокол гэдэгт итгэлтэй байгаа бол өөрийн тээврийн протоколыг бий болгох цаг болжээ.
Энэ хэсгийн төгсгөлд уншихыг зөвлөж байна Энд яригдсан олон сэдвийг багтаасан Брайн Хук.
Хэрэглээний протокол
Одоо бид үйлчлүүлэгч болон серверийн хооронд өгөгдөл солилцох боломжтой болсон тул ямар өгөгдөл, ямар форматаар дамжуулахаа шийдэх хэрэгтэй.
Сонгодог схем нь үйлчлүүлэгчид сервер рүү оролт эсвэл үйлдэл илгээдэг бөгөөд сервер нь одоогийн тоглоомын төлөвийг үйлчлүүлэгчид рүү илгээдэг.
Сервер нь бүтэн төлөвийг биш, харин тоглуулагчийн ойролцоо байрладаг аж ахуйн нэгж бүхий шүүсэн төлөвийг илгээдэг. Тэр үүнийг гурван шалтгаанаар хийдэг. Нэгдүгээрт, бүрэн төлөв нь өндөр давтамжтайгаар дамжуулахад хэтэрхий том байж болно. Хоёрдугаарт, үйлчлүүлэгчид ихэвчлэн визуал болон аудио мэдээллийг сонирхдог, учир нь ихэнх тоглоомын логикийг тоглоомын сервер дээр дуурайлган хийдэг. Гуравдугаарт, зарим тоглоомонд тоглогч тодорхой өгөгдлийг, жишээлбэл, газрын зургийн нөгөө талд байгаа дайсны байрлалыг мэдэх шаардлагагүй, эс тэгвээс тэр пакетуудыг үнэрлэж, түүнийг алахын тулд хаашаа нүүхээ мэдэж болно.
Цувралчлал
Эхний алхам бол бидний илгээхийг хүссэн өгөгдлийг (оролт эсвэл тоглоомын төлөв) дамжуулахад тохиромжтой формат руу хөрвүүлэх явдал юм. Энэ процессыг нэрлэдэг .
JSON эсвэл XML гэх мэт хүний унших боломжтой форматыг ашиглах нь нэн даруй санаанд орж ирдэг бодол юм. Гэхдээ энэ нь бүрэн үр дүнгүй бөгөөд ихэнх сувгийг дэмий үрэх болно.
Үүний оронд хоёртын форматыг ашиглахыг зөвлөж байна, энэ нь илүү нягт юм. Өөрөөр хэлбэл, пакетууд хэдхэн байт агуулах болно. Энд анхаарах асуудал байна , өөр өөр компьютер дээр ялгаатай байж болно.
Өгөгдлийг цуваа болгохын тулд та номын санг ашиглаж болно, жишээлбэл:
- Элсэн шуурга компани
- Шейн Грант, Рандолф Воорхи нар
Номын сан нь зөөврийн архив үүсгэж, эндианизмд санаа тавьдаг эсэхийг шалгаарай.
Альтернатив шийдэл бол үүнийг өөрөө хэрэгжүүлэх явдал бөгөөд энэ нь тийм ч хэцүү биш, ялангуяа та коддоо өгөгдөл төвтэй хандлагыг ашигладаг бол. Нэмж дурдахад энэ нь номын санг ашиглах үед үргэлж боломжгүй байдаг оновчлолыг хийх боломжийг танд олгоно.
Гленн Фидлер цувралын талаар хоёр нийтлэл бичсэн: и .
Шахалт
Үйлчлүүлэгч болон серверийн хооронд дамжуулах өгөгдлийн хэмжээ нь сувгийн зурвасын өргөнөөр хязгаарлагддаг. Өгөгдлийн шахалт нь хормын хувилбар бүрт илүү их мэдээлэл дамжуулах, шинэчлэлтийн давтамжийг нэмэгдүүлэх эсвэл сувгийн шаардлагыг багасгах боломжийг олгоно.
Бит савлагаа
Эхний техник бол бит савлагаа юм. Энэ нь хүссэн утгыг тодорхойлоход шаардлагатай хэдэн битийг ашиглахаас бүрдэнэ. Жишээлбэл, хэрэв танд 16 өөр утгатай тоолол байгаа бол бүхэл байт (8 бит) биш, та ердөө 4 бит ашиглаж болно.
Үүнийг хэрхэн хэрэгжүүлэх талаар Гленн Фидлер өгүүллийн хоёрдугаар хэсэгт тайлбарлав .
Битийн баглаа боодол нь түүвэрлэлтийн хувьд ялангуяа сайн ажилладаг бөгөөд энэ нь дараагийн хэсгийн сэдэв байх болно.
Дээж авах
нь утгыг кодлохын тулд боломжит утгуудын зөвхөн дэд багцыг ашигладаг алдагдалтай шахалтын техник юм. Дискретацийг хэрэгжүүлэх хамгийн хялбар арга бол хөвөгч цэгийн тоог дугуйлах явдал юм.
Гленн Фидлер (дахин!) Өөрийн нийтлэлдээ дээж авах аргыг хэрхэн хэрэгжүүлэх талаар харуулсан .
Шахалтын алгоритмууд
Дараагийн техник нь алдагдалгүй шахалтын алгоритмууд байх болно.
Миний бодлоор таны мэдэх ёстой хамгийн сонирхолтой гурван алгоритм энд байна.
- урьдчилан тооцоолсон кодтой бөгөөд энэ нь маш хурдан бөгөөд сайн үр дүнд хүргэдэг. Энэ нь Quake3 сүлжээний хөдөлгүүрт пакетуудыг шахахад ашигласан.
- нь өгөгдлийн хэмжээг хэзээ ч нэмэгдүүлдэггүй ерөнхий зориулалтын шахалтын алгоритм юм. Яаж харж чадаж байна аа , энэ нь янз бүрийн хэрэглээнд ашиглагдаж ирсэн. Энэ нь төлөвийг шинэчлэхэд шаардлагагүй байж магадгүй юм. Гэхдээ серверээс үйлчлүүлэгч рүү хөрөнгө, урт текст эсвэл газар нутгийг илгээх шаардлагатай бол энэ нь ашигтай байж болно.
- - Энэ нь магадгүй хамгийн энгийн шахалтын алгоритм боловч тодорхой төрлийн өгөгдөлд маш үр дүнтэй бөгөөд zlib-ээс өмнө урьдчилан боловсруулах алхам болгон ашиглаж болно. Энэ нь олон зэргэлдээ элементүүд давтагддаг хавтанцар эсвэл вокселээс бүрдсэн газрыг шахахад тохиромжтой.
Дельта шахалт
Сүүлийн шахалтын арга бол дельта шахалт юм. Энэ нь зөвхөн одоогийн тоглоомын төлөв болон үйлчлүүлэгчийн хүлээн авсан сүүлчийн төлөвийн хоорондох ялгааг дамжуулж байгаа явдал юм.
Энэ нь анх Quake3 сүлжээний хөдөлгүүрт ашиглагдаж байсан. Үүнийг хэрхэн ашиглахыг тайлбарласан хоёр нийтлэл энд байна:
- Брайан Хук
- Фабиен Сангларс [ Habré дээрх нийтлэлүүд, "Сүлжээний загвар" хэсгийг үзнэ үү]
Гленн Фидлер мөн нийтлэлийнхээ хоёрдугаар хэсэгт үүнийг ашигласан .
Шифрлэлт
Үүнээс гадна, та үйлчлүүлэгч болон серверийн хооронд мэдээлэл дамжуулахыг шифрлэх шаардлагатай байж магадгүй юм. Үүнд хэд хэдэн шалтгаан бий:
- нууцлал/нууцлал: мессежийг зөвхөн хүлээн авагч унших боломжтой бөгөөд сүлжээг үнэрлэж буй өөр хэн ч тэдгээрийг унших боломжгүй.
- баталгаажуулалт: тоглогчийн дүрд тоглохыг хүссэн хүн түүний түлхүүрийг мэддэг байх ёстой.
- Хууран мэхлэлтээс урьдчилан сэргийлэх: Хорлонтой тоглогчид өөрсдийн хууран мэхлэлтийн багцыг бий болгох нь илүү хэцүү байх болно, тэд шифрлэлтийн схемийг хуулбарлаж, түлхүүрийг олох хэрэгтэй болно (холболт бүрт өөрчлөгддөг).
Үүний тулд номын сан ашиглахыг зөвлөж байна. Би ашиглахыг санал болгож байна , учир нь энэ нь маш энгийн бөгөөд маш сайн заавартай. Ялангуяа сонирхолтой нь зааварчилгаа юм , энэ нь танд шинэ холболт бүрт шинэ түлхүүр үүсгэх боломжийг олгодог.
Өргөдөл гаргах протокол: Дүгнэлт
Энэ нь бидний өргөдлийн протоколыг дуусгаж байна. Шахах нь бүрэн сонголттой бөгөөд үүнийг ашиглах шийдвэр нь зөвхөн тоглоом болон шаардлагатай зурвасын өргөнөөс хамаарна гэдэгт би итгэдэг. Шифрлэлт нь миний бодлоор заавал байх ёстой, гэхдээ эхний прототип дээр та үүнгүйгээр хийж болно.
Хэрэглээний логик
Бид одоо үйлчлүүлэгчийн төлөвийг шинэчлэх боломжтой ч хоцролттой холбоотой асуудал гарч болзошгүй. Тоглогч оролтыг бөглөсний дараа тоглоомын төлөвийг серверээс шинэчлэхийг хүлээх хэрэгтэй бөгөөд энэ нь дэлхийд ямар нөлөө үзүүлснийг харах хэрэгтэй.
Түүгээр ч барахгүй хоёр улсын шинэчлэлийн хооронд дэлхий бүрэн хөдөлгөөнгүй байдаг. Хэрэв муж улсын шинэчлэлтийн хурд бага байвал хөдөлгөөнүүд маш хурцадмал байх болно.
Энэ асуудлын нөлөөллийг бууруулах хэд хэдэн арга байдаг бөгөөд би тэдгээрийг дараагийн хэсэгт авч үзэх болно.
Хоцролтыг гөлгөр болгох арга техник
Энэ хэсэгт тайлбарласан бүх техникийг цувралд нарийвчлан авч үзсэн болно Габриэль Гамбетта. Би энэ гайхалтай цуврал нийтлэлүүдийг уншихыг зөвлөж байна. Энэ нь мөн эдгээр аргууд практик дээр хэрхэн ажилладагийг харах боломжийг олгодог интерактив демо-г агуулдаг.
Эхний техник нь серверээс хариу хүлээхгүйгээр оролтын үр дүнг шууд хэрэглэх явдал юм. гэж нэрлэдэг үйлчлүүлэгч талын таамаглал. Гэсэн хэдий ч, үйлчлүүлэгч серверээс шинэчлэлт хүлээн авахдаа түүний таамаг зөв эсэхийг шалгах ёстой. Хэрэв тийм биш бол сервер нь авторитар байдаг тул серверээс хүлээн авсан зүйлийнхээ дагуу түүний төлөвийг өөрчлөх хэрэгтэй. Энэ аргыг анх Quake-д ашигласан. Та энэ талаар дэлгэрэнгүйг нийтлэлээс уншиж болно Фабиен Сангларс [ Хабре дээр].
Хоёрдахь багц техникийг хоёр улсын шинэчлэлийн хооронд бусад байгууллагуудын хөдөлгөөнийг жигд болгоход ашигладаг. Энэ асуудлыг шийдэх хоёр арга бий: интерполяци ба экстраполяци. Интерполяцийн хувьд сүүлийн хоёр төлөвийг авч, нэгээс нөгөөд шилжих шилжилтийг харуулав. Үүний сул тал нь үйлчлүүлэгч урьд нь юу болсныг үргэлж хардаг тул бага зэрэг саатал үүсгэдэг. Экстраполяци гэдэг нь үйлчлүүлэгчийн хүлээн авсан сүүлийн төлөвт тулгуурлан аж ахуйн нэгжүүд хаана байх ёстойг урьдчилан таамаглах явдал юм. Үүний сул тал нь хэрэв аж ахуйн нэгж хөдөлгөөний чиглэлийг бүрэн өөрчилвөл урьдчилсан мэдээ болон бодит байрлалын хооронд том алдаа гарах болно.
Зөвхөн FPS-д хэрэг болох хамгийн сүүлийн үеийн дэвшилтэт техник хоцрогдлын нөхөн олговор. Хоцролын нөхөн олговрыг ашиглахдаа сервер нь бай руу буудах үед үйлчлүүлэгчийн саатлыг харгалзан үздэг. Жишээлбэл, хэрэв тоглогч дэлгэцэн дээрээ толгойн буудлага хийсэн боловч бодит байдал дээр саатсаны улмаас тэдний бай өөр байршилд байсан бол хожимдсоны улмаас тоглогчийг алах эрхийг үгүйсгэх нь шударга бус хэрэг болно. Тиймээс сервер нь тоглогчийн дэлгэцэн дээр харсан зүйлийг дуурайж, түүний цохилт болон байны хооронд мөргөлдөөн байгаа эсэхийг шалгахын тулд тоглогчийн буудсан мөч хүртэлх хугацааг буцааж эргүүлнэ.
Гленн Фидлер (үргэлж байсан шигээ!) 2004 онд нийтлэл бичсэн , үүнд тэрээр сервер болон үйлчлүүлэгчийн хооронд физикийн симуляцийг синхрончлох үндэс суурийг тавьсан. 2014 онд тэрээр шинэ цуврал нийтлэл бичсэн , физикийн симуляцийг синхрончлох бусад аргуудыг тодорхойлсон.
Valve вики дээр бас хоёр нийтлэл байна, и хоцрогдлын нөхөн төлбөрийг авч үздэг.
Хууран мэхлэхээс урьдчилан сэргийлэх
Хууран мэхлэхээс урьдчилан сэргийлэх хоёр үндсэн арга байдаг.
Нэгдүгээрт: хууран мэхлэгчид хортой пакет илгээхэд хэцүү болгодог. Дээр дурдсанчлан үүнийг хэрэгжүүлэх сайн арга бол шифрлэлт юм.
Хоёрдугаарт: авторитар сервер нь зөвхөн тушаал/оролт/үйлдлүүдийг хүлээн авах ёстой. Үйлчлүүлэгч нь оролт илгээхээс өөр сервер дээрх төлөвийг өөрчлөх боломжгүй байх ёстой. Дараа нь сервер оролт хүлээн авах бүрдээ үүнийг ашиглахаасаа өмнө хүчинтэй эсэхийг шалгах ёстой.
Хэрэглээний логик: дүгнэлт
Үйлчлүүлэгч болон сервер нь нэг компьютер дээр ажиллаж байсан ч муу нөхцөлд тоглоомынхоо үйлдлийг шалгахын тулд өндөр хоцролт, бага сэргээх хурдыг дуурайлган хийх аргыг хэрэгжүүлэхийг танд зөвлөж байна. Энэ нь хойшлуулах гөлгөр техникийг хэрэгжүүлэхэд ихээхэн хялбарчлах болно.
Бусад ашигтай эх сурвалжууд
Хэрэв та сүлжээний загваруудын бусад эх сурвалжуудыг судлахыг хүсвэл эндээс олж болно:
- – Түүний блог бүхэлдээ уншихад үнэ цэнэтэй, тэнд маш олон сайхан нийтлэл бий. Сүлжээний технологийн талаархи бүх нийтлэлийг цуглуулсан.
- M. Fatih MAR бол онлайн видео тоглоомын хөдөлгүүрүүдийн талаархи нийтлэл, видео бичлэгийн дэлгэрэнгүй жагсаалт юм.
- В Мөн олон хэрэгтэй холбоосууд байдаг.
Эх сурвалж: www.habr.com