મેગાપૅક: ફેક્ટરિયોએ 200-પ્લેયર મલ્ટિપ્લેયર સમસ્યા કેવી રીતે ઉકેલી

આ વર્ષના મે મહિનામાં મેં એક ખેલાડી તરીકે ભાગ લીધો હતો MMO ઇવેન્ટ્સ KatherineOfSky. મેં નોંધ્યું છે કે જ્યારે ખેલાડીઓની સંખ્યા ચોક્કસ સંખ્યા સુધી પહોંચે છે, ત્યારે દર થોડી મિનિટોમાં તેમાંથી કેટલાક “પડ્યા”. સદભાગ્યે તમારા માટે (પરંતુ મારા માટે નહીં), હું તે ખેલાડીઓમાંથી એક હતો જેણે ડિસ્કનેક્ટ કર્યું દર વખતે, સારા જોડાણ સાથે પણ. મેં આને વ્યક્તિગત પડકાર તરીકે લીધો અને સમસ્યાના કારણો શોધવાનું શરૂ કર્યું. ત્રણ અઠવાડિયાના ડિબગીંગ, ટેસ્ટિંગ અને ફિક્સ કર્યા પછી, આખરે બગ ઠીક કરવામાં આવ્યો, પરંતુ આ મુસાફરી એટલી સરળ ન હતી.

મલ્ટિપ્લેયર ગેમ્સ સાથેની સમસ્યાઓને ટ્રેક કરવી ખૂબ જ મુશ્કેલ છે. તે સામાન્ય રીતે ખૂબ જ ચોક્કસ નેટવર્ક પરિમાણો અને ખૂબ જ ચોક્કસ રમત પરિસ્થિતિઓ (આ કિસ્સામાં, 200 થી વધુ ખેલાડીઓ ધરાવતા) ​​હેઠળ થાય છે. અને જ્યારે સમસ્યાનું પુનઃઉત્પાદન થઈ શકે છે, ત્યારે પણ તે યોગ્ય રીતે ડીબગ કરી શકાતું નથી કારણ કે બ્રેકપોઈન્ટ દાખલ કરવાથી રમત અટકી જાય છે, ટાઈમર ગૂંચવાઈ જાય છે અને સામાન્ય રીતે કનેક્શન સમય સમાપ્ત થઈ જાય છે. પરંતુ દ્રઢતા માટે આભાર અને એક અદ્ભુત સાધન કહેવાય છે અણઘડ હું શું થઈ રહ્યું છે તે શોધવામાં સફળ થયો.

ટૂંકમાં, બગ અને લેટન્સી સ્ટેટ સિમ્યુલેશનના અપૂર્ણ અમલીકરણને કારણે, ક્લાયંટ કેટલીકવાર પોતાને એવી પરિસ્થિતિમાં શોધે છે કે જ્યાં તેને એક ઘડિયાળ ચક્રમાં આશરે 400 ગેમ એન્ટિટીની પ્લેયરની ઇનપુટ સિલેક્શન ક્રિયાઓ ધરાવતું નેટવર્ક પેકેટ મોકલવું પડતું હતું ( અમે તેને "મેગા-પેકેટ" કહીએ છીએ). સર્વરે પછી આ બધી ઇનપુટ ક્રિયાઓ યોગ્ય રીતે પ્રાપ્ત કરવી જ જોઈએ નહીં, પરંતુ તે અન્ય તમામ ક્લાયન્ટ્સને પણ મોકલવી જોઈએ. જો તમારી પાસે 200 ગ્રાહકો છે, તો આ ઝડપથી સમસ્યા બની જાય છે. સર્વરની લિંક ઝડપથી ભરાઈ જાય છે, જે પેકેટની ખોટ તરફ દોરી જાય છે અને ફરીથી વિનંતી કરાયેલા પેકેટોનો કાસ્કેડ થાય છે. ઇનપુટ ક્રિયામાં વિલંબ થવાથી વધુ ક્લાયંટ મેગાપેકેટ્સ મોકલવા માટેનું કારણ બને છે, જેના કારણે હિમપ્રપાત વધુ મોટો થાય છે. નસીબદાર ગ્રાહકો પુનઃપ્રાપ્ત કરવામાં વ્યવસ્થાપિત થાય છે; બાકીના બધા પડી જાય છે.


સમસ્યા એકદમ મૂળભૂત હતી અને તેને ઠીક કરવામાં મને 2 અઠવાડિયા લાગ્યાં. તે ખૂબ તકનીકી છે, તેથી હું નીચે રસદાર તકનીકી વિગતો સમજાવીશ. પરંતુ પ્રથમ, તમારે જાણવાની જરૂર છે કે વર્ઝન 0.17.54, 4 જૂનના રોજ રીલીઝ થયું હોવાથી, અસ્થાયી કનેક્શન સમસ્યાઓનો સામનો કરીને, મલ્ટિપ્લેયર વધુ સ્થિર બન્યું છે, અને વિલંબ છુપાવવાથી ઘણી ઓછી બગડી (ઓછી મંદી અને ટેલિપોર્ટિંગ) થઈ ગઈ છે. મેં કોમ્બેટ લેગ છુપાવવાની રીત પણ બદલી છે અને હું આશા રાખું છું કે આ તેને થોડું સરળ બનાવશે.

મલ્ટિપ્લેયર મેગા પેક - ટેકનિકલ વિગતો

સરળ શબ્દોમાં કહીએ તો, રમતમાં મલ્ટિપ્લેયર આ રીતે કાર્ય કરે છે: બધા ક્લાયંટ રમતની સ્થિતિનું અનુકરણ કરે છે, ફક્ત પ્લેયર ઇનપુટ પ્રાપ્ત કરે છે અને મોકલે છે (જેને "ઇનપુટ ક્રિયાઓ" કહેવાય છે, ઇનપુટ ક્રિયાઓ). સર્વરનું મુખ્ય કાર્ય ટ્રાન્સમિટ કરવાનું છે ઇનપુટ ક્રિયાઓ અને નિયંત્રણ કરે છે કે બધા ક્લાયન્ટ એક જ ઘડિયાળ ચક્રમાં સમાન ક્રિયાઓ કરે છે. તમે પોસ્ટમાં આ વિશે વધુ વાંચી શકો છો FFF-149.

સર્વરે કઈ ક્રિયાઓ કરવી તે અંગે નિર્ણયો લેવાના હોવાથી, ખેલાડીની ક્રિયાઓ લગભગ આ પાથ પર આગળ વધે છે: પ્લેયર એક્શન -> ગેમ ક્લાયંટ -> નેટવર્ક -> સર્વર -> નેટવર્ક -> ગેમ ક્લાયંટ. આનો અર્થ એ છે કે દરેક ખેલાડીની ક્રિયા સમગ્ર નેટવર્કમાં રાઉન્ડ ટ્રીપ કર્યા પછી જ કરવામાં આવે છે. આને કારણે, રમત ખૂબ જ ધીમી લાગશે, તેથી રમતમાં મલ્ટિપ્લેયરની રજૂઆત પછી તરત જ, વિલંબને છુપાવવા માટે એક પદ્ધતિ રજૂ કરવામાં આવી હતી. છુપાવવામાં વિલંબ અન્ય ખેલાડીઓની ક્રિયાઓ અને સર્વરના નિર્ણયોને ધ્યાનમાં લીધા વિના પ્લેયર ઇનપુટનું અનુકરણ કરે છે.

ફેક્ટરીઓમાં રમતની સ્થિતિ છે રમત રાજ્ય કાર્ડ, પ્લેયર, એન્ટિટી અને અન્ય દરેક વસ્તુની સંપૂર્ણ સ્થિતિ છે. સર્વર તરફથી મળેલી ક્રિયાઓના આધારે તે તમામ ક્લાયંટમાં નિશ્ચિતપણે સિમ્યુલેટેડ છે. ગેમ સ્ટેટ પવિત્ર છે, અને જો તે ક્યારેય સર્વર અથવા અન્ય ક્લાયંટથી અલગ થવાનું શરૂ કરે છે, તો પછી ડિસિંક થાય છે.

સિવાય રમત રાજ્ય અમારી પાસે વિલંબની સ્થિતિ છે વિલંબ સ્થિતિ. તેમાં ગ્રાઉન્ડ સ્ટેટનો એક નાનો સબસેટ છે. વિલંબ સ્થિતિ પવિત્ર નથી અને પ્લેયર ઇનપુટ્સના આધારે ભવિષ્યમાં રમતની સ્થિતિ કેવી દેખાશે તેનું ચિત્ર ફક્ત રજૂ કરે છે ઇનપુટ ક્રિયાઓ.

આ હેતુ માટે, અમે બનાવેલ એક નકલ સંગ્રહિત કરીએ છીએ ઇનપુટ ક્રિયાઓ વિલંબની કતારમાં.

એટલે કે, ક્લાયંટ બાજુ પર પ્રક્રિયાના અંતે ચિત્ર કંઈક આના જેવું દેખાય છે:

1. અમે અરજી કરીએ છીએ ઇનપુટ ક્રિયાઓ બધા ખેલાડીઓ માટે રમત રાજ્ય જે રીતે સર્વર તરફથી આ ઇનપુટ ક્રિયાઓ પ્રાપ્ત થઈ હતી.
2. અમે વિલંબની કતારમાંથી બધું દૂર કરીએ છીએ ઇનપુટ ક્રિયાઓ, જે, સર્વર મુજબ, પહેલાથી જ લાગુ કરવામાં આવી છે રમત રાજ્ય.
3. કા .ી નાખો વિલંબ સ્થિતિ અને તેને ફરીથી સેટ કરો જેથી તે બરાબર જેવું જ દેખાય રમત રાજ્ય.
4. અમે વિલંબ કતારથી તમામ ક્રિયાઓ લાગુ કરીએ છીએ વિલંબ સ્થિતિ.
5. ડેટાના આધારે રમત રાજ્ય и વિલંબ સ્થિતિ અમે ખેલાડીને રમત રેન્ડર કરીએ છીએ.

આ બધું દરેક માપમાં પુનરાવર્તિત થાય છે.

ખૂબ મુશ્કેલ? આરામ કરશો નહીં, આ બધું નથી. અવિશ્વસનીય ઇન્ટરનેટ કનેક્શન્સની ભરપાઈ કરવા માટે, અમે બે મિકેનિઝમ્સ બનાવી છે:

• ચૂકી ગયેલ ટીક્સ: જ્યારે સર્વર તે નક્કી કરે છે ઇનપુટ ક્રિયાઓ રમતના બીટ પર ચલાવવામાં આવશે, પછી જો તેણે પ્રાપ્ત ન કર્યું ઇનપુટ ક્રિયાઓ કેટલાક ખેલાડી (ઉદાહરણ તરીકે, વિલંબમાં વધારો થવાને કારણે), તે રાહ જોશે નહીં, પરંતુ આ ક્લાયન્ટને જાણ કરશે "મેં તમારા ધ્યાનમાં લીધું નથી ઇનપુટ ક્રિયાઓ, હું તેમને આગામી બારમાં ઉમેરવાનો પ્રયત્ન કરીશ." આ એટલા માટે કરવામાં આવે છે કે એક પ્લેયરના કનેક્શન (અથવા કોમ્પ્યુટર) સાથેની સમસ્યાઓને કારણે, નકશા અપડેટ દરેક વ્યક્તિ માટે ધીમું ન થાય. તે નોંધવું યોગ્ય છે ઇનપુટ ક્રિયાઓ અવગણવામાં આવે છે, પરંતુ ખાલી કોરે મૂકી.
• સંપૂર્ણ રાઉન્ડ-ટ્રીપ લેટન્સી: સર્વર દરેક ક્લાયંટ માટે ક્લાયંટ અને સર્વર વચ્ચેની રાઉન્ડ-ટ્રીપ લેટન્સી શું છે તે અનુમાન કરવાનો પ્રયાસ કરે છે. દર 5 સેકન્ડે, જો જરૂરી હોય તો તે ક્લાયન્ટ સાથે નવી લેટન્સીની વાટાઘાટ કરે છે (ભૂતકાળમાં કનેક્શન કેવી રીતે વર્તે છે તેના આધારે), અને તે મુજબ રાઉન્ડ-ટ્રીપ લેટન્સીમાં વધારો અથવા ઘટાડો કરે છે.

તેમના પોતાના પર, આ મિકેનિઝમ્સ એકદમ સરળ છે, પરંતુ જ્યારે તેનો એકસાથે ઉપયોગ કરવામાં આવે છે (જે ઘણીવાર કનેક્શન સમસ્યાઓ સાથે થાય છે), ત્યારે કોડના તર્કનું સંચાલન કરવું મુશ્કેલ બને છે અને ઘણા કિસ્સાઓ સાથે. વધુમાં, જ્યારે આ મિકેનિઝમ્સ અમલમાં આવે છે, ત્યારે સર્વર અને વિલંબ કતારને યોગ્ય રીતે વિશેષ અમલીકરણ કરવું આવશ્યક છે. ઇનપુટ ક્રિયા કહેવાય છે Stop MovementInTheNextTick. આનો આભાર, જો કનેક્શનમાં સમસ્યા હોય, તો પાત્ર તેના પોતાના પર ચાલશે નહીં (ઉદાહરણ તરીકે, ટ્રેનની સામે).

હવે અમારે તમને સમજાવવાની જરૂર છે કે એન્ટિટી સિલેક્શન કેવી રીતે કાર્ય કરે છે. પ્રસારિત પ્રકારોમાંથી એક ઇનપુટ ક્રિયા એન્ટિટી પસંદગી સ્થિતિમાં ફેરફાર છે. તે દરેકને કહે છે કે ખેલાડી કઈ એન્ટિટી પર ફરે છે. જેમ તમે કલ્પના કરી શકો છો, આ ક્લાયન્ટ દ્વારા મોકલવામાં આવતી સૌથી સામાન્ય ઇનપુટ ક્રિયાઓ પૈકીની એક છે, તેથી બેન્ડવિડ્થ બચાવવા માટે, અમે શક્ય તેટલી ઓછી જગ્યા લેવા માટે તેને ઑપ્ટિમાઇઝ કર્યું છે. તે જે રીતે કાર્ય કરે છે તે એ છે કે દરેક એન્ટિટી પસંદ કરવામાં આવે છે, નિરપેક્ષ, ઉચ્ચ-ચોકસાઇવાળા નકશા કોઓર્ડિનેટ્સને સંગ્રહિત કરવાને બદલે, રમત અગાઉની પસંદગીથી ઓછી-ચોકસાઇ સંબંધિત ઑફસેટ સ્ટોર કરે છે. આ સારી રીતે કાર્ય કરે છે કારણ કે માઉસ પસંદગીઓ અગાઉની પસંદગીની ખૂબ નજીક હોય છે. આ બે મહત્વપૂર્ણ આવશ્યકતાઓ ઉભા કરે છે: ઇનપુટ ક્રિયાઓ તેમને ક્યારેય છોડવું જોઈએ નહીં અને યોગ્ય ક્રમમાં પૂર્ણ થવું જોઈએ. માટે આ જરૂરિયાતો પૂરી થાય છે રમત રાજ્ય. પરંતુ કાર્ય થી વિલંબ સ્થિતિ ખેલાડી માટે "પર્યાપ્ત સારા દેખાતા" માં, તેઓ વિલંબની સ્થિતિમાં સંતુષ્ટ નથી. વિલંબ સ્થિતિ ધ્યાનમાં લેતા નથી ઘણા કિસ્સાઓ, ઘડિયાળના ચક્રને છોડવા અને રાઉન્ડ-ટ્રીપ ટ્રાન્સમિશન વિલંબમાં ફેરફાર સાથે સંકળાયેલ.

તમે પહેલેથી જ અનુમાન કરી શકો છો કે આ ક્યાં જઈ રહ્યું છે. અમે આખરે મેગાપેક સમસ્યાના કારણો જોવાનું શરૂ કરી રહ્યાં છીએ. સમસ્યાનું મૂળ એ છે કે એન્ટિટી પસંદગીના તર્ક પર આધાર રાખે છે વિલંબ સ્થિતિ, અને આ સ્થિતિમાં હંમેશા સાચી માહિતી હોતી નથી. તેથી, મેગાપેકેટ આના જેવું કંઈક જનરેટ થાય છે:

1. ખેલાડીને કનેક્શન સમસ્યાઓ છે.
2. ઘડિયાળના ચક્રને છોડવા અને રાઉન્ડ-ટ્રીપ ટ્રાન્સમિશનના વિલંબને નિયંત્રિત કરવા માટેની પદ્ધતિઓ અમલમાં આવે છે.
3. વિલંબની સ્થિતિ કતાર આ પદ્ધતિઓને ધ્યાનમાં લેતી નથી. આના કારણે કેટલીક ક્રિયાઓ અકાળે દૂર કરવામાં આવે છે અથવા ખોટા ક્રમમાં કરવામાં આવે છે, પરિણામે ખોટી વિલંબ સ્થિતિ.
4. પ્લેયરને કનેક્શનની સમસ્યા છે અને, સર્વર સાથે પકડવા માટે, 400 સાયકલ સુધીનું અનુકરણ કરે છે.
5. દરેક ટિક પર, એક નવી ક્રિયા, એન્ટિટીની પસંદગીમાં ફેરફાર કરીને, જનરેટ કરવામાં આવે છે અને સર્વરને મોકલવા માટે તૈયાર કરવામાં આવે છે.
6. ક્લાયંટ સર્વર પર 400+ એન્ટિટી પસંદગી ફેરફારોની મેગા-બેચ મોકલે છે (અને અન્ય ક્રિયાઓ સાથે: શૂટિંગ સ્ટેટ્સ, વૉકિંગ સ્ટેટ્સ, વગેરે પણ આ સમસ્યાથી પીડાય છે).
7. સર્વર 400 ઇનપુટ ક્રિયાઓ મેળવે છે. તેને કોઈપણ ઇનપુટ ક્રિયાઓ છોડવાની મંજૂરી ન હોવાથી, તે તમામ ક્લાયન્ટ્સને તે ક્રિયાઓ કરવા માટે આદેશ આપે છે અને તેમને સમગ્ર નેટવર્ક પર મોકલે છે.

વિડંબના એ છે કે બેન્ડવિડ્થ બચાવવા માટે રચાયેલ મિકેનિઝમ વિશાળ નેટવર્ક પેકેટ્સ બનાવવાનું સમાપ્ત થયું.

અમે અપડેટ અને બેકલોગ કતાર સપોર્ટના તમામ કિસ્સાઓને ઠીક કરીને આ સમસ્યાને સંબોધિત કરી છે. જોકે તેમાં ઘણો સમય લાગ્યો હતો, અંતે ઝડપી હેક્સ પર આધાર રાખવાને બદલે તેને યોગ્ય રીતે મેળવવું યોગ્ય હતું.

સોર્સ: www.habr.com