கடந்த இரண்டு வாரங்களாக எனது விளையாட்டுக்கான ஆன்லைன் இன்ஜினில் வேலை செய்து வருகிறேன். இதற்கு முன், கேம்களில் நெட்வொர்க்கிங் பற்றி எனக்கு எதுவும் தெரியாது, எனவே நான் நிறைய கட்டுரைகளைப் படித்தேன் மற்றும் அனைத்து கருத்துகளையும் புரிந்துகொள்வதற்கும் எனது சொந்த நெட்வொர்க்கிங் இயந்திரத்தை எழுதுவதற்கும் நிறைய சோதனைகள் செய்தேன்.
இந்த வழிகாட்டியில், உங்கள் சொந்த கேம் இன்ஜினை எழுதுவதற்கு முன் நீங்கள் கற்றுக் கொள்ள வேண்டிய பல்வேறு கருத்துகளையும், அவற்றைக் கற்றுக்கொள்வதற்கான சிறந்த ஆதாரங்களையும் கட்டுரைகளையும் உங்களுடன் பகிர்ந்து கொள்ள விரும்புகிறேன்.
பொதுவாக, பிணைய கட்டமைப்புகளில் இரண்டு முக்கிய வகைகள் உள்ளன: பியர்-டு-பியர் மற்றும் கிளையன்ட்-சர்வர். ஒரு பியர்-டு-பியர் (p2p) கட்டமைப்பில், இணைக்கப்பட்ட எந்த ஜோடி பிளேயர்களுக்கும் இடையில் தரவு பரிமாற்றப்படுகிறது, அதே நேரத்தில் கிளையன்ட்-சர்வர் கட்டமைப்பில், பிளேயர்கள் மற்றும் சேவையகத்திற்கு இடையே மட்டுமே தரவு மாற்றப்படும்.
சில கேம்களில் பியர்-டு-பியர் கட்டிடக்கலை இன்னும் பயன்படுத்தப்படுகிறது என்றாலும், கிளையன்ட்-சர்வர் நிலையானது: செயல்படுத்த எளிதானது, சிறிய சேனல் அகலம் தேவைப்படுகிறது, மேலும் மோசடிக்கு எதிராக பாதுகாப்பதை எளிதாக்குகிறது. எனவே, இந்த டுடோரியலில் கிளையன்ட்-சர்வர் கட்டமைப்பில் கவனம் செலுத்துவோம்.
குறிப்பாக, சர்வர் சர்வர்களில் நாங்கள் மிகவும் ஆர்வமாக உள்ளோம்: அத்தகைய அமைப்புகளில், சர்வர் எப்போதும் சரியாக இருக்கும். எடுத்துக்காட்டாக, ஒரு வீரர் தான் ஆயத்தொகுப்புகளில் இருப்பதாக நினைத்தால் (10, 5), மற்றும் சர்வர் அவர் (5, 3) இல் இருப்பதாகச் சொன்னால், கிளையன்ட் தனது நிலையை சேவையகத்தால் புகாரளிக்கப்பட்ட நிலையில் மாற்ற வேண்டும், துணைக்கு அல்ல. மாறாக. அதிகாரப்பூர்வ சேவையகங்களைப் பயன்படுத்துவது ஏமாற்றுக்காரர்களைக் கண்டறிவதை எளிதாக்குகிறது.
நெட்வொர்க் கேமிங் அமைப்புகள் மூன்று முக்கிய கூறுகளைக் கொண்டுள்ளன:
- போக்குவரத்து நெறிமுறை: வாடிக்கையாளர்களுக்கும் சேவையகத்திற்கும் இடையில் தரவு எவ்வாறு மாற்றப்படுகிறது.
- பயன்பாட்டு நெறிமுறை: வாடிக்கையாளர்களிடமிருந்து சேவையகத்திற்கும் சேவையகத்திலிருந்து கிளையண்டுகளுக்கும் மற்றும் எந்த வடிவத்தில் அனுப்பப்படுகிறது.
- பயன்பாட்டு தர்க்கம்: கிளையன்ட்கள் மற்றும் சேவையகத்தின் நிலையைப் புதுப்பிக்க, மாற்றப்பட்ட தரவு எவ்வாறு பயன்படுத்தப்படுகிறது.
ஒவ்வொரு பகுதியின் பங்கு மற்றும் அவற்றுடன் தொடர்புடைய சவால்களைப் புரிந்துகொள்வது மிகவும் முக்கியம்.
போக்குவரத்து நெறிமுறை
சேவையகத்திற்கும் வாடிக்கையாளர்களுக்கும் இடையில் தரவைக் கொண்டு செல்வதற்கான நெறிமுறையைத் தேர்ந்தெடுப்பது முதல் படி. இதற்கு இரண்டு இணைய நெறிமுறைகள் உள்ளன: и . ஆனால் அவற்றில் ஒன்றை அடிப்படையாகக் கொண்டு உங்கள் சொந்த போக்குவரத்து நெறிமுறையை உருவாக்கலாம் அல்லது அவற்றைப் பயன்படுத்தும் நூலகத்தைப் பயன்படுத்தலாம்.
TCP மற்றும் UDP ஆகியவற்றின் ஒப்பீடு
TCP மற்றும் UDP இரண்டும் அடிப்படையாக கொண்டது . ஐபி ஒரு பாக்கெட்டை ஒரு மூலத்திலிருந்து பெறுநருக்கு அனுப்ப அனுமதிக்கிறது, ஆனால் அனுப்பப்பட்ட பாக்கெட் விரைவில் அல்லது பின்னர் பெறுநரை சென்றடையும் என்றும், அது ஒரு முறையாவது அதை அடையும் என்றும், பாக்கெட்டுகளின் வரிசை சரியாக வரும் என்றும் உத்தரவாதம் அளிக்காது. உத்தரவு. மேலும், ஒரு பாக்கெட் ஒரு குறிப்பிட்ட அளவு தரவை மட்டுமே கொண்டிருக்க முடியும், மதிப்பால் கொடுக்கப்பட்டிருக்கும் .
யுடிபி என்பது ஐபியின் மேல் உள்ள மெல்லிய அடுக்கு. எனவே, இது அதே வரம்புகளைக் கொண்டுள்ளது. மாறாக, TCP பல அம்சங்களைக் கொண்டுள்ளது. இது பிழை சரிபார்ப்புடன் இரண்டு முனைகளுக்கு இடையே நம்பகமான, ஒழுங்கான இணைப்பை வழங்குகிறது. எனவே, TCP மிகவும் வசதியானது மற்றும் பல நெறிமுறைகளில் பயன்படுத்தப்படுகிறது, எ.கா. , и . ஆனால் இந்த அம்சங்கள் அனைத்தும் விலையில் வருகின்றன: .
இந்த செயல்பாடுகள் ஏன் தாமதத்தை ஏற்படுத்தும் என்பதை புரிந்து கொள்ள, TCP எவ்வாறு செயல்படுகிறது என்பதை நாம் புரிந்து கொள்ள வேண்டும். அனுப்பும் முனை ஒரு பாக்கெட்டை பெறும் முனைக்கு அனுப்பும் போது, அது ஒப்புகை (ACK) பெறும் என எதிர்பார்க்கிறது. ஒரு குறிப்பிட்ட நேரத்திற்குப் பிறகு அது அதைப் பெறவில்லை என்றால் (பாக்கெட் அல்லது ஒப்புகை தொலைந்துவிட்டதால் அல்லது வேறு சில காரணங்களால்), அது பாக்கெட்டை மீண்டும் அனுப்புகிறது. மேலும், TCP, சரியான வரிசையில் பாக்கெட்டுகளைப் பெறுவதற்கு உத்தரவாதம் அளிக்கிறது, எனவே தொலைந்த பாக்கெட்டைப் பெறும் வரை, மற்ற அனைத்து பாக்கெட்டுகளும் ஏற்கனவே பெறும் ஹோஸ்ட்டால் பெறப்பட்டிருந்தாலும், அவற்றைச் செயல்படுத்த முடியாது.
ஆனால் நீங்கள் கற்பனை செய்வது போல், மல்டிபிளேயர் கேம்களில் தாமதம் மிகவும் முக்கியமானது, குறிப்பாக FPS போன்ற அதிரடி-நிரம்பிய வகைகளில். அதனால்தான் பல விளையாட்டுகள் UDP ஐ தங்கள் சொந்த நெறிமுறையுடன் பயன்படுத்துகின்றன.
ஒரு சொந்த UDP-அடிப்படையிலான நெறிமுறை பல்வேறு காரணங்களுக்காக TCP ஐ விட திறமையானதாக இருக்கும். எடுத்துக்காட்டாக, இது சில பாக்கெட்டுகளை நம்பகமானதாகவும் மற்றவற்றை நம்பத்தகாததாகவும் குறிக்கலாம். எனவே, நம்பத்தகாத பாக்கெட் பெறுநரை சென்றடைகிறதா என்பது கவலையில்லை. அல்லது இது பல தரவு ஸ்ட்ரீம்களை செயலாக்க முடியும், இதனால் ஒரு ஸ்ட்ரீமில் தொலைந்த பாக்கெட் மீதமுள்ள ஸ்ட்ரீம்களை மெதுவாக்காது. எடுத்துக்காட்டாக, பிளேயர் உள்ளீட்டிற்கான ஒரு தொடரிழை மற்றும் அரட்டை செய்திகளுக்கு மற்றொரு தொடரிழை இருக்கலாம். அவசரமில்லாத அரட்டைச் செய்தி தொலைந்துவிட்டால், அது அவசரமான உள்ளீட்டைக் குறைக்காது. அல்லது ஒரு தனியுரிம நெறிமுறையானது, வீடியோ கேம் சூழலில் மிகவும் திறமையானதாக இருக்கும் வகையில் TCPயை விட வித்தியாசமாக நம்பகத்தன்மையை செயல்படுத்தலாம்.
எனவே, TCP மிகவும் சக்கையாக இருந்தால், UDP அடிப்படையில் எங்கள் சொந்த போக்குவரத்து நெறிமுறையை உருவாக்குவோம்?
இது இன்னும் கொஞ்சம் சிக்கலானது. கேமிங் நெட்வொர்க் அமைப்புகளுக்கு டிசிபி கிட்டத்தட்ட துணையாக இருந்தாலும், அது உங்கள் குறிப்பிட்ட கேமிற்கு நன்றாக வேலை செய்து, மதிப்புமிக்க நேரத்தை மிச்சப்படுத்தும். எடுத்துக்காட்டாக, டர்ன்-அடிப்படையிலான கேம் அல்லது லேன் நெட்வொர்க்குகளில் மட்டுமே விளையாடக்கூடிய கேமுக்கு தாமதம் ஒரு சிக்கலாக இருக்காது, அங்கு தாமதம் மற்றும் பாக்கெட் இழப்பு இணையத்தை விட மிகக் குறைவாக இருக்கும்.
World of Warcraft, Minecraft மற்றும் Terraria உட்பட பல வெற்றிகரமான விளையாட்டுகள் TCP ஐப் பயன்படுத்துகின்றன. இருப்பினும், பெரும்பாலான FPSகள் அவற்றின் சொந்த UDP அடிப்படையிலான நெறிமுறைகளைப் பயன்படுத்துகின்றன, எனவே அவற்றைப் பற்றி கீழே விரிவாகப் பேசுவோம்.
நீங்கள் TCP ஐப் பயன்படுத்த முடிவு செய்தால், அது முடக்கப்பட்டுள்ளதா என்பதை உறுதிப்படுத்தவும் , ஏனெனில் இது அனுப்பும் முன் பாக்கெட்டுகளை பஃபர் செய்கிறது, அதாவது இது தாமதத்தை அதிகரிக்கிறது.
மல்டிபிளேயர் கேம்களின் சூழலில் UDP மற்றும் TCP இடையே உள்ள வேறுபாடுகளைப் பற்றி மேலும் அறிய, நீங்கள் Glenn Fiedler இன் கட்டுரையைப் படிக்கலாம். .
சொந்த நெறிமுறை
எனவே உங்கள் சொந்த போக்குவரத்து நெறிமுறையை உருவாக்க விரும்புகிறீர்கள், ஆனால் எங்கு தொடங்குவது என்று தெரியவில்லையா? க்ளென் ஃபீட்லர் இதைப் பற்றி இரண்டு அற்புதமான கட்டுரைகளை எழுதியிருப்பதால் நீங்கள் அதிர்ஷ்டசாலி. அவற்றில் நிறைய புத்திசாலித்தனமான எண்ணங்களைக் காண்பீர்கள்.
முதல் கட்டுரை 2008, இரண்டாவது விட எளிதாக, 2016. நீங்கள் பழையதைத் தொடங்க பரிந்துரைக்கிறேன்.
UDP அடிப்படையிலான தனிப்பயன் நெறிமுறையைப் பயன்படுத்துவதில் கிளென் ஃபீட்லர் ஒரு பெரிய ஆதரவாளர் என்பதை நினைவில் கொள்க. அவரது கட்டுரைகளைப் படித்த பிறகு, வீடியோ கேம்களில் TCP கடுமையான குறைபாடுகளைக் கொண்டுள்ளது என்ற அவரது கருத்தை நீங்கள் ஏற்றுக்கொள்வீர்கள், மேலும் உங்கள் சொந்த நெறிமுறையை நீங்கள் செயல்படுத்த விரும்புவீர்கள்.
ஆனால் நீங்கள் நெட்வொர்க்கிங்கிற்கு புதியவராக இருந்தால், நீங்களே ஒரு உதவி செய்து, TCP அல்லது நூலகத்தைப் பயன்படுத்தவும். உங்கள் சொந்த போக்குவரத்து நெறிமுறையை வெற்றிகரமாக செயல்படுத்த, நீங்கள் முன்பே நிறைய கற்றுக்கொள்ள வேண்டும்.
பிணைய நூலகங்கள்
உங்களுக்கு TCPயை விட திறமையான ஒன்று தேவைப்பட்டால், ஆனால் உங்கள் சொந்த நெறிமுறையை செயல்படுத்துவதில் சிரமப்பட வேண்டாம் மற்றும் நிறைய விவரங்களுக்குச் செல்ல விரும்பவில்லை என்றால், நீங்கள் நெட்வொர்க்கிங் நூலகத்தைப் பயன்படுத்தலாம். அவற்றில் நிறைய உள்ளன:
- க்ளென் ஃபீட்லர்
- , இது இனி ஆதரிக்கப்படவில்லை, ஆனால் அதன் ஒரு முட்கரண்டி அது இன்னும் செயலில் உள்ளது போல் தெரிகிறது.
- மல்டிபிளேயர் FPSக்காக உருவாக்கப்பட்ட நூலகம்
- அடைப்பான்
நான் அனைத்தையும் முயற்சி செய்யவில்லை, ஆனால் நான் ENet ஐ விரும்புகிறேன், ஏனெனில் இது பயன்படுத்த எளிதானது மற்றும் நம்பகமானது. கூடுதலாக, இது தெளிவான ஆவணங்கள் மற்றும் ஆரம்பநிலைக்கான பயிற்சியைக் கொண்டுள்ளது.
போக்குவரத்து நெறிமுறை: முடிவு
சுருக்கமாக: இரண்டு முக்கிய போக்குவரத்து நெறிமுறைகள் உள்ளன: TCP மற்றும் UDP. TCP பல பயனுள்ள அம்சங்களைக் கொண்டுள்ளது: நம்பகத்தன்மை, பாக்கெட் ஆர்டர் பாதுகாப்பு, பிழை கண்டறிதல். UDP இல் இதெல்லாம் இல்லை, ஆனால் TCP அதன் இயல்பிலேயே தாமதத்தை அதிகரித்துள்ளது, இது சில கேம்களுக்கு ஏற்றுக்கொள்ள முடியாதது. அதாவது, குறைந்த தாமதத்தை உறுதிப்படுத்த, நீங்கள் UDP அடிப்படையில் உங்கள் சொந்த நெறிமுறையை உருவாக்கலாம் அல்லது UDP இல் போக்குவரத்து நெறிமுறையை செயல்படுத்தும் மற்றும் மல்டிபிளேயர் வீடியோ கேம்களுக்கு ஏற்ற நூலகத்தைப் பயன்படுத்தலாம்.
TCP, UDP மற்றும் நூலகத்திற்கு இடையேயான தேர்வு பல காரணிகளைப் பொறுத்தது. முதலில், விளையாட்டின் தேவைகளிலிருந்து: குறைந்த தாமதம் தேவையா? இரண்டாவதாக, பயன்பாட்டு நெறிமுறை தேவைகளிலிருந்து: இதற்கு நம்பகமான நெறிமுறை தேவையா? அடுத்த பகுதியில் நாம் பார்ப்பது போல், ஒரு பயன்பாட்டு நெறிமுறையை உருவாக்குவது சாத்தியமாகும், அதற்காக நம்பத்தகாத நெறிமுறை மிகவும் பொருத்தமானது. இறுதியாக, நெட்வொர்க் என்ஜின் டெவலப்பரின் அனுபவத்தையும் நீங்கள் கணக்கில் எடுத்துக்கொள்ள வேண்டும்.
எனக்கு இரண்டு ஆலோசனைகள் உள்ளன:
- மற்ற பயன்பாட்டிலிருந்து போக்குவரத்து நெறிமுறையை முடிந்தவரை சுருக்கவும், இதனால் அனைத்து குறியீடுகளையும் மீண்டும் எழுதாமல் எளிதாக மாற்றலாம்.
- மிகைப்படுத்தாதீர்கள். நீங்கள் ஒரு நெட்வொர்க்கிங் நிபுணராக இல்லாவிட்டால் மற்றும் உங்களுக்கு தனிப்பயன் UDP அடிப்படையிலான போக்குவரத்து நெறிமுறை தேவையா எனத் தெரியவில்லை என்றால், நீங்கள் TCP அல்லது நம்பகத்தன்மையை வழங்கும் நூலகத்துடன் தொடங்கலாம், பின்னர் செயல்திறனைச் சோதித்து அளவிடலாம். சிக்கல்கள் ஏற்பட்டால் மற்றும் போக்குவரத்து நெறிமுறைதான் காரணம் என்று நீங்கள் உறுதியாக நம்பினால், உங்கள் சொந்த போக்குவரத்து நெறிமுறையை உருவாக்குவதற்கான நேரம் இதுவாக இருக்கலாம்.
இந்த பகுதியின் முடிவில், நீங்கள் படிக்க பரிந்துரைக்கிறேன் பிரையன் ஹூக் எழுதியது, இது இங்கு விவாதிக்கப்பட்ட பல தலைப்புகளை உள்ளடக்கியது.
பயன்பாட்டு நெறிமுறை
இப்போது க்ளையன்ட்டுகளுக்கும் சர்வருக்கும் இடையில் தரவைப் பரிமாறிக் கொள்ள முடியும், எந்தத் தரவை எந்த வடிவத்தில் மாற்ற வேண்டும் என்பதை நாங்கள் தீர்மானிக்க வேண்டும்.
கிளாசிக் திட்டம் என்னவென்றால், வாடிக்கையாளர்கள் உள்ளீடு அல்லது செயல்களை சேவையகத்திற்கு அனுப்புகிறார்கள், மேலும் சர்வர் தற்போதைய கேம் நிலையை வாடிக்கையாளர்களுக்கு அனுப்புகிறது.
சேவையகம் முழு நிலையை அல்ல, ஆனால் பிளேயருக்கு அருகில் உள்ள நிறுவனங்களுடன் வடிகட்டப்பட்ட நிலையை அனுப்புகிறது. அவர் மூன்று காரணங்களுக்காக இதைச் செய்கிறார். முதலாவதாக, முழு நிலையும் அதிக அதிர்வெண்ணில் அனுப்ப முடியாத அளவுக்கு பெரியதாக இருக்கலாம். இரண்டாவதாக, வாடிக்கையாளர்கள் முக்கியமாக காட்சி மற்றும் ஆடியோ தரவுகளில் ஆர்வமாக உள்ளனர், ஏனெனில் பெரும்பாலான கேம் லாஜிக் கேம் சர்வரில் உருவகப்படுத்தப்படுகிறது. மூன்றாவதாக, சில விளையாட்டுகளில், வீரர் குறிப்பிட்ட தரவுகளை அறியக்கூடாது, உதாரணமாக, வரைபடத்தின் மறுபுறத்தில் எதிரியின் நிலை, இல்லையெனில் அவர் பாக்கெட்டுகளை மோப்பம் செய்து, அவரைக் கொல்ல எங்கு செல்ல வேண்டும் என்பதைத் தெரிந்துகொள்ளலாம்.
வரிசையாக்கம்
முதல் படி, நாம் அனுப்ப விரும்பும் தரவை (உள்ளீடு அல்லது விளையாட்டு நிலை) பரிமாற்றத்திற்கு ஏற்ற வடிவமைப்பாக மாற்ற வேண்டும். இந்த செயல்முறை அழைக்கப்படுகிறது .
JSON அல்லது XML போன்ற மனிதர்கள் படிக்கக்கூடிய வடிவமைப்பைப் பயன்படுத்துவதே உடனடியாக நினைவுக்கு வரும் எண்ணம். ஆனால் இது முற்றிலும் பயனற்றதாக இருக்கும் மற்றும் பெரும்பாலான சேனலை வீணடிக்கும்.
அதற்கு பதிலாக பைனரி வடிவமைப்பைப் பயன்படுத்த பரிந்துரைக்கப்படுகிறது, இது மிகவும் கச்சிதமானது. அதாவது, பாக்கெட்டுகளில் சில பைட்டுகள் மட்டுமே இருக்கும். இங்கே கருத்தில் கொள்ள வேண்டிய சிக்கல் உள்ளது , இது வெவ்வேறு கணினிகளில் வேறுபடலாம்.
தரவை வரிசைப்படுத்த, நீங்கள் ஒரு நூலகத்தைப் பயன்படுத்தலாம், எடுத்துக்காட்டாக:
- கூகிள்
- மணல் புயல் நிறுவனம்
- ஷேன் கிராண்ட் மற்றும் ராண்டால்ஃப் வூர்ஹீஸ்
நூலகம் கையடக்கக் காப்பகங்களை உருவாக்குகிறது மற்றும் இறுதித்தன்மையைப் பற்றி அக்கறை கொண்டுள்ளது என்பதை உறுதிப்படுத்தவும்.
ஒரு மாற்று தீர்வு, அதை நீங்களே செயல்படுத்துவது; குறிப்பாக உங்கள் குறியீட்டிற்கு தரவு மைய அணுகுமுறையைப் பயன்படுத்தினால், இது மிகவும் கடினம் அல்ல. கூடுதலாக, நூலகத்தைப் பயன்படுத்தும் போது எப்போதும் சாத்தியமில்லாத மேம்படுத்தல்களைச் செய்ய இது உங்களை அனுமதிக்கும்.
க்ளென் ஃபீட்லர் வரிசையாக்கம் பற்றி இரண்டு கட்டுரைகளை எழுதினார்: и .
சுருக்க
கிளையன்ட் மற்றும் சர்வர் இடையே பரிமாற்றப்படும் தரவு அளவு சேனலின் அலைவரிசையால் வரையறுக்கப்படுகிறது. தரவு சுருக்கமானது ஒவ்வொரு ஸ்னாப்ஷாட்டிலும் அதிக தரவை மாற்றவும், புதுப்பிப்பு அதிர்வெண்ணை அதிகரிக்கவும் அல்லது சேனல் தேவைகளைக் குறைக்கவும் உங்களை அனுமதிக்கும்.
பிட் பேக்கேஜிங்
முதல் நுட்பம் பிட் பேக்கிங் ஆகும். இது விரும்பிய மதிப்பை விவரிக்க தேவையான பிட்களின் எண்ணிக்கையை சரியாகப் பயன்படுத்துகிறது. எடுத்துக்காட்டாக, உங்களிடம் 16 வெவ்வேறு மதிப்புகளைக் கொண்ட ஒரு enum இருந்தால், முழு பைட்டுக்கு (8 பிட்கள்) பதிலாக, நீங்கள் 4 பிட்களைப் பயன்படுத்தலாம்.
இதை எவ்வாறு செயல்படுத்துவது என்பதை கட்டுரையின் இரண்டாம் பகுதியில் கிளென் ஃபீட்லர் விளக்குகிறார் .
பிட் பேக்கிங் குறிப்பாக மாதிரியுடன் நன்றாக வேலை செய்கிறது, இது அடுத்த பகுதியின் தலைப்பாக இருக்கும்.
மாதிரி எடுத்தல்
மதிப்பை குறியாக்க சாத்தியமான மதிப்புகளின் துணைக்குழுவை மட்டுமே பயன்படுத்தும் இழப்பு சுருக்க நுட்பமாகும். ஃப்ளோட்டிங் பாயின்ட் எண்களை ரவுண்டிங் செய்வதன் மூலம் தனிமைப்படுத்தலைச் செயல்படுத்த எளிதான வழி.
க்ளென் ஃபீட்லர் (மீண்டும்!) தனது கட்டுரையில் மாதிரியை எவ்வாறு நடைமுறைப்படுத்துவது என்பதைக் காட்டுகிறார் .
சுருக்க வழிமுறைகள்
அடுத்த நுட்பம் இழப்பற்ற சுருக்க அல்காரிதம்களாக இருக்கும்.
இங்கே, என் கருத்துப்படி, நீங்கள் தெரிந்து கொள்ள வேண்டிய மூன்று சுவாரஸ்யமான வழிமுறைகள்:
- முன்-கணிக்கப்பட்ட குறியீட்டுடன், இது மிக வேகமாகவும் நல்ல முடிவுகளைத் தரக்கூடியதாகவும் உள்ளது. இது Quake3 நெட்வொர்க்கிங் எஞ்சினில் பாக்கெட்டுகளை சுருக்க பயன்படுத்தப்பட்டது.
- தரவுகளின் அளவை ஒருபோதும் அதிகரிக்காத ஒரு பொது-நோக்க சுருக்க வழிமுறை ஆகும். எப்படி பார்க்க முடியும் , இது பல்வேறு பயன்பாடுகளில் பயன்படுத்தப்படுகிறது. மாநிலங்களைப் புதுப்பிக்க இது தேவையற்றதாக இருக்கலாம். ஆனால் நீங்கள் சேவையகத்திலிருந்து வாடிக்கையாளர்களுக்கு சொத்துக்கள், நீண்ட உரைகள் அல்லது நிலப்பரப்புகளை அனுப்ப வேண்டும் என்றால் அது பயனுள்ளதாக இருக்கும்.
- - இது அநேகமாக எளிமையான சுருக்க அல்காரிதம் ஆகும், ஆனால் சில வகையான தரவுகளுக்கு இது மிகவும் பயனுள்ளதாக இருக்கும், மேலும் zlib க்கு முன் செயலாக்கத்திற்கு முந்தைய படியாக இதைப் பயன்படுத்தலாம். ஓடுகள் அல்லது வோக்சல்களால் ஆன நிலப்பரப்பை அழுத்துவதற்கு இது மிகவும் பொருத்தமானது, இதில் பல அடுத்தடுத்த கூறுகள் மீண்டும் மீண்டும் வருகின்றன.
டெல்டா சுருக்கம்
கடைசி சுருக்க நுட்பம் டெல்டா சுருக்கமாகும். தற்போதைய விளையாட்டு நிலைக்கும் கிளையன்ட் பெற்ற கடைசி நிலைக்கும் இடையிலான வேறுபாடுகள் மட்டுமே அனுப்பப்படுகின்றன என்ற உண்மையை இது கொண்டுள்ளது.
இது முதலில் Quake3 நெட்வொர்க் எஞ்சினில் பயன்படுத்தப்பட்டது. அதை எவ்வாறு பயன்படுத்துவது என்பதை விளக்கும் இரண்டு கட்டுரைகள் இங்கே:
- பிரையன் ஹூக்
- ஃபேபியன் சாங்க்லர்ஸ் [ ஹப்ரே பற்றிய கட்டுரைகள், “நெட்வொர்க் மாடல்” பகுதியைப் பார்க்கவும்]
க்ளென் ஃபீட்லர் தனது கட்டுரையின் இரண்டாம் பாகத்திலும் இதைப் பயன்படுத்தினார் .
குறியாக்க
கூடுதலாக, வாடிக்கையாளர்களுக்கும் சேவையகத்திற்கும் இடையிலான தகவல் பரிமாற்றத்தை நீங்கள் குறியாக்கம் செய்ய வேண்டியிருக்கலாம். இதற்கு பல காரணங்கள் உள்ளன:
- தனியுரிமை/ரகசியம்: செய்திகளைப் பெறுநரால் மட்டுமே படிக்க முடியும், மேலும் நெட்வொர்க்கை மோப்பம் பிடிக்கும் வேறு யாரும் அவற்றைப் படிக்க முடியாது.
- அங்கீகாரம்: ஒரு வீரரின் பாத்திரத்தை வகிக்க விரும்பும் ஒரு நபர் தனது திறவுகோலை அறிந்திருக்க வேண்டும்.
- ஏமாற்றுதல் தடுப்பு: தீங்கிழைக்கும் வீரர்கள் தங்கள் சொந்த ஏமாற்று தொகுப்புகளை உருவாக்குவது மிகவும் கடினமாக இருக்கும், அவர்கள் குறியாக்கத் திட்டத்தை மீண்டும் உருவாக்க வேண்டும் மற்றும் விசையைக் கண்டறிய வேண்டும் (ஒவ்வொரு இணைப்பிலும் இது மாறும்).
இதற்காக ஒரு நூலகத்தைப் பயன்படுத்த நான் கடுமையாக பரிந்துரைக்கிறேன். பயன்படுத்த பரிந்துரைக்கிறேன் , ஏனெனில் இது மிகவும் எளிமையானது மற்றும் சிறந்த பயிற்சிகளைக் கொண்டுள்ளது. குறிப்பாக சுவாரசியமானது குறித்த பயிற்சி , இது ஒவ்வொரு புதிய இணைப்பிலும் புதிய விசைகளை உருவாக்க உங்களை அனுமதிக்கிறது.
பயன்பாட்டு நெறிமுறை: முடிவு
இது எங்கள் பயன்பாட்டு நெறிமுறையை முடிக்கிறது. சுருக்கமானது முற்றிலும் விருப்பமானது என்று நான் நம்புகிறேன், அதைப் பயன்படுத்துவதற்கான முடிவு விளையாட்டு மற்றும் தேவையான அலைவரிசையை மட்டுமே சார்ந்துள்ளது. குறியாக்கம், என் கருத்துப்படி, கட்டாயமானது, ஆனால் முதல் முன்மாதிரியில் நீங்கள் அதை இல்லாமல் செய்யலாம்.
பயன்பாட்டு தர்க்கம்
இப்போது எங்களால் கிளையண்டில் நிலையைப் புதுப்பிக்க முடிகிறது, ஆனால் தாமதச் சிக்கல்கள் ஏற்படலாம். பிளேயர், உள்ளீட்டை முடித்த பிறகு, அது உலகில் என்ன தாக்கத்தை ஏற்படுத்தியது என்பதைப் பார்க்க, சேவையகத்திலிருந்து கேம் நிலை புதுப்பிக்கப்படும் வரை காத்திருக்க வேண்டும்.
மேலும், இரண்டு மாநில புதுப்பிப்புகளுக்கு இடையில், உலகம் முற்றிலும் நிலையானது. மாநில புதுப்பிப்பு விகிதம் குறைவாக இருந்தால், இயக்கங்கள் மிகவும் ஜெர்கியாக இருக்கும்.
இந்த சிக்கலின் தாக்கத்தை குறைக்க பல நுட்பங்கள் உள்ளன, அவற்றை அடுத்த பகுதியில் விவரிக்கிறேன்.
தாமதத்தை மென்மையாக்கும் நுட்பங்கள்
இந்த பிரிவில் விவரிக்கப்பட்டுள்ள அனைத்து நுட்பங்களும் தொடரில் விரிவாக விவாதிக்கப்படுகின்றன கேப்ரியல் காம்பெட்டா. இந்த சிறந்த தொடர் கட்டுரைகளைப் படிக்க நான் மிகவும் பரிந்துரைக்கிறேன். இந்த நுட்பங்கள் நடைமுறையில் எவ்வாறு செயல்படுகின்றன என்பதைப் பார்க்க உதவும் ஊடாடும் டெமோவும் இதில் அடங்கும்.
சேவையகத்தின் பதிலுக்காக காத்திருக்காமல் உள்ளீட்டு முடிவை நேரடியாகப் பயன்படுத்துவது முதல் நுட்பமாகும். அது அழைக்கபடுகிறது வாடிக்கையாளர் பக்க முன்னறிவிப்பு. இருப்பினும், கிளையன்ட் சேவையகத்திலிருந்து புதுப்பிப்பைப் பெறும்போது, அதன் கணிப்பு சரியானது என்பதைச் சரிபார்க்க வேண்டும். இது அவ்வாறு இல்லையென்றால், சர்வரிடமிருந்து அவர் பெற்றதற்கு ஏற்ப அவர் தனது நிலையை மாற்ற வேண்டும், ஏனெனில் சேவையகம் சர்வாதிகாரமானது. இந்த நுட்பம் முதலில் பூகம்பத்தில் பயன்படுத்தப்பட்டது. கட்டுரையில் இதைப் பற்றி மேலும் படிக்கலாம் ஃபேபியன் சாங்க்லர்ஸ் [ ஹப்ரே மீது].
இரண்டு மாநில புதுப்பிப்புகளுக்கு இடையில் மற்ற நிறுவனங்களின் இயக்கத்தை மென்மையாக்க இரண்டாவது செட் நுட்பங்கள் பயன்படுத்தப்படுகின்றன. இந்த சிக்கலை தீர்க்க இரண்டு வழிகள் உள்ளன: இடைக்கணிப்பு மற்றும் எக்ஸ்ட்ராபோலேஷன். இடைக்கணிப்பு வழக்கில், கடைசி இரண்டு நிலைகள் எடுக்கப்பட்டு, ஒன்றிலிருந்து மற்றொன்றுக்கு மாறுதல் காட்டப்படும். அதன் குறைபாடு என்னவென்றால், வாடிக்கையாளர் கடந்த காலத்தில் என்ன நடந்தது என்பதை எப்போதும் பார்ப்பதால், இது ஒரு சிறிய அளவு தாமதத்தை ஏற்படுத்துகிறது. எக்ஸ்ட்ராபோலேஷன் என்பது கிளையன்ட் கடைசியாகப் பெற்ற நிலையின் அடிப்படையில் இப்போது நிறுவனங்கள் எங்கு இருக்க வேண்டும் என்பதைக் கணிப்பதாகும். அதன் குறைபாடு என்னவென்றால், நிறுவனம் இயக்கத்தின் திசையை முழுவதுமாக மாற்றினால், முன்னறிவிப்புக்கும் உண்மையான நிலைக்கும் இடையில் ஒரு பெரிய பிழை இருக்கும்.
சமீபத்திய, மிகவும் மேம்பட்ட நுட்பம் FPS இல் மட்டுமே பயனுள்ளதாக இருக்கும் தாமத இழப்பீடு. பின்னடைவு இழப்பீட்டைப் பயன்படுத்தும் போது, சேவையகம் இலக்கை நோக்கிச் சுடும் போது கிளையண்டின் தாமதங்களை கணக்கில் எடுத்துக்கொள்கிறது. எடுத்துக்காட்டாக, ஒரு வீரர் தனது திரையில் ஹெட்ஷாட்டை நிகழ்த்தினால், ஆனால் உண்மையில் அவர்களின் இலக்கு தாமதம் காரணமாக வேறு இடத்தில் இருந்தால், தாமதம் காரணமாக வீரரைக் கொல்லும் உரிமையை மறுப்பது நியாயமற்றது. எனவே, பிளேயர் தனது திரையில் பார்த்ததை உருவகப்படுத்தவும், அவர்களின் ஷாட் மற்றும் இலக்குக்கு இடையே மோதலைச் சரிபார்க்கவும், பிளேயர் சுடும் தருணத்திற்கு சேவையகம் திரும்பும்.
க்ளென் ஃபீட்லர் (எப்போதும் போல!) 2004 இல் ஒரு கட்டுரை எழுதினார் , இதில் சர்வர் மற்றும் கிளையன்ட் இடையே இயற்பியல் உருவகப்படுத்துதல்களை ஒத்திசைப்பதற்கான அடித்தளத்தை அவர் அமைத்தார். 2014 இல் அவர் ஒரு புதிய தொடர் கட்டுரைகளை எழுதினார் , இது இயற்பியல் உருவகப்படுத்துதல்களை ஒத்திசைப்பதற்கான பிற நுட்பங்களை விவரித்தது.
வால்வு விக்கியிலும் இரண்டு கட்டுரைகள் உள்ளன. и தாமதத்திற்கான இழப்பீட்டைக் கருத்தில் கொண்டது.
ஏமாற்றுவதைத் தடுக்கும்
மோசடியைத் தடுக்க இரண்டு முக்கிய நுட்பங்கள் உள்ளன.
முதலாவதாக: ஏமாற்றுபவர்களுக்கு தீங்கிழைக்கும் பாக்கெட்டுகளை அனுப்புவது மிகவும் கடினம். மேலே குறிப்பிட்டுள்ளபடி, இதை செயல்படுத்த ஒரு நல்ல வழி குறியாக்கம்.
இரண்டாவது: ஒரு சர்வாதிகார சர்வர் கட்டளைகள்/உள்ளீடு/செயல்களை மட்டுமே பெற வேண்டும். உள்ளீட்டை அனுப்புவதைத் தவிர, கிளையன்ட் சர்வரில் நிலையை மாற்ற முடியாது. பின்னர், ஒவ்வொரு முறையும் சேவையகம் உள்ளீட்டைப் பெறும்போது, அதைப் பயன்படுத்துவதற்கு முன்பு அது சரியானதா என்பதைச் சரிபார்க்க வேண்டும்.
பயன்பாட்டு தர்க்கம்: முடிவு
அதிக தாமதங்கள் மற்றும் குறைந்த புதுப்பிப்பு விகிதங்களை உருவகப்படுத்துவதற்கான ஒரு வழியை நீங்கள் செயல்படுத்த பரிந்துரைக்கிறேன், இதன் மூலம் உங்கள் கேமின் மோசமான நிலையில், கிளையன்ட் மற்றும் சர்வர் ஒரே கணினியில் இயங்கும் போது கூட உங்கள் கேமின் நடத்தையை சோதிக்க முடியும். இது தாமதத்தை மென்மையாக்கும் நுட்பங்களை செயல்படுத்துவதை பெரிதும் எளிதாக்கும்.
பிற பயனுள்ள ஆதாரங்கள்
நெட்வொர்க் மாடல்களில் உள்ள பிற ஆதாரங்களை நீங்கள் ஆராய விரும்பினால், அவற்றை இங்கே காணலாம்:
- - அவரது முழு வலைப்பதிவும் படிக்கத் தகுந்தது, நிறைய சிறந்த கட்டுரைகள் உள்ளன. நெட்வொர்க் தொழில்நுட்பங்கள் பற்றிய அனைத்து கட்டுரைகளும் சேகரிக்கப்படுகின்றன.
- M. Fatih MAR ஆனது ஆன்லைன் வீடியோ கேம் இன்ஜின்களில் உள்ள கட்டுரைகள் மற்றும் வீடியோக்களின் விரிவான பட்டியலாகும்.
- В பல பயனுள்ள இணைப்புகளும் உள்ளன.
ஆதாரம்: www.habr.com