
நுண்ணோக்கியின் கீழ் BLE (ATTы GATTы...)
பகுதி 1, கண்ணோட்டம்
முதல் புளூடூத் 4.0 விவரக்குறிப்பு வெளியிடப்பட்டு நீண்ட காலம் ஆகிவிட்டது. BLE என்ற தலைப்பு மிகவும் சுவாரஸ்யமாக இருந்தாலும், அதன் சிக்கலான தன்மை காரணமாக இது இன்னும் பல டெவலப்பர்களை தள்ளி வைக்கிறது. எனது முந்தைய கட்டுரைகளில், நான் முதன்மையாக மிகக் குறைந்த மட்டத்தில் - இணைப்பு அடுக்கு மற்றும் இயற்பியல் அடுக்கு மீது கவனம் செலுத்தினேன். இது பண்புக்கூறு நெறிமுறை (ATP) மற்றும் பொதுவான பண்புக்கூறு சுயவிவரம் (GATT) போன்ற சிக்கலான மற்றும் குழப்பமான கருத்துக்களைத் தவிர்க்க எனக்கு அனுமதித்தது. இருப்பினும், இந்தக் கருத்துகளைப் புரிந்து கொள்ளாமல், இணக்கமான சாதனங்களை உருவாக்குவது சாத்தியமில்லை. இன்று, இந்த அறிவை உங்களுடன் பகிர்ந்து கொள்ள விரும்புகிறேன். இந்தக் கட்டுரையில், நான் நம்பியிருப்பேன் ஆரம்பநிலையாளர்களுக்கு, நோர்டிக் வலைத்தளத்திலிருந்து. சரி, தொடங்குவோம்.
எல்லாம் ஏன் மிகவும் சிக்கலானது?
என் கருத்துப்படி, ஸ்மார்ட்போன்கள் வழியாக சாதனங்களைக் கட்டுப்படுத்துவது மிகவும் நம்பிக்கைக்குரிய மற்றும் நீண்டகால கருத்தாகும் என்பது உடனடியாகத் தெளிவாகத் தெரிந்தது. எனவே, அதை உடனடியாக முழுமையாக வடிவமைக்க முடிவு செய்தோம். கேஜெட் உற்பத்தியாளர்கள் பின்னர் பொருந்தாத தங்கள் சொந்த நெறிமுறைகளை உருவாக்குவதைத் தடுப்பதற்காக இது செய்யப்பட்டது. இது சிக்கலான தன்மையை விளக்குகிறது. ஆரம்பத்திலிருந்தே, BLE நெறிமுறையில் சாத்தியமான அனைத்தையும் கசக்க முயற்சித்தோம். அது பின்னர் பயனுள்ளதாக இருக்குமா இல்லையா என்பது பொருத்தமற்றது. எதிர்காலத்தில் சாதனங்களின் பட்டியலை விரிவுபடுத்துவதற்கான சாத்தியத்தையும் நாங்கள் வழங்கினோம்.
BLE நெறிமுறை வரைபடத்தைக் காட்டும் படத்தைப் பார்ப்போம். இது பல அடுக்குகளைக் கொண்டுள்ளது. மிகக் குறைந்த, இயற்பியல் அடுக்கு (PHY), சாதனத்தின் ரேடியோ சேனலுக்குப் பொறுப்பாகும். இணைப்பு அடுக்கு (LL) கடத்தப்பட்ட செய்தியில் முழு பைட் வரிசையையும் கொண்டுள்ளது. முந்தைய கட்டுரைகளில் இந்த அடுக்கைப் படித்தோம். கட்டுப்படுத்தி மற்றும் ஹோஸ்ட் வெவ்வேறு சில்லுகளில் செயல்படுத்தப்பட்டால், ஹோஸ்ட் கட்டுப்படுத்தி இடைமுகம் (HCI) என்பது BLE அடுக்குகள் அல்லது சில்லுகளுக்கு இடையிலான தொடர்புக்கான நெறிமுறையாகும். லாஜிக்கல் லிங்க் கண்ட்ரோல் மற்றும் அடாப்டேஷன் புரோட்டோகால் (L2CAP) பாக்கெட் உருவாக்கம், ஃப்ரேமிங், பிழை கட்டுப்பாடு மற்றும் பாக்கெட் மறுசீரமைப்புக்கு பொறுப்பாகும். பாதுகாப்பு மேலாளர் நெறிமுறை (SMP) பாக்கெட் குறியாக்கத்திற்கு பொறுப்பாகும். "யார் யார்" என்பதை தீர்மானிக்க சாதனங்களுக்கு இடையிலான ஆரம்ப தரவு பரிமாற்றத்திற்கு பொதுவான அணுகல் சுயவிவரம் (GAP) பொறுப்பாகும். ஸ்கேனிங் மற்றும் விளம்பரமும் இந்த சுயவிவரத்தின் கீழ் வருகிறது. இந்தக் கட்டுரையில், நெறிமுறையின் மீதமுள்ள இரண்டு பகுதிகளான GATT மற்றும் ATT ஆகியவற்றில் கவனம் செலுத்துவேன். GATT என்பது ATT இல் ஒரு மேல்கட்டமைப்பு, எனவே அவை நெருக்கமாகப் பின்னிப் பிணைந்துள்ளன.

விவாதத்தை எளிமைப்படுத்த, நான் ஒரு ஒப்புமையைப் பயன்படுத்த விரும்புகிறேன். நான் அதை எங்கோ கேட்டிருக்கிறேன், அதை எதிரொலிக்க விரும்புகிறேன். பல அலமாரிகளைக் கொண்ட புத்தக அலமாரியாக ஒரு BLE சாதனத்தை கற்பனை செய்து பாருங்கள். ஒவ்வொரு அலமாரியும் ஒரு தனி தலைப்பைக் குறிக்கிறது. எடுத்துக்காட்டாக, அறிவியல் புனைகதை, கணிதம் மற்றும் கலைக்களஞ்சியங்களுக்கான அலமாரிகள் எங்களிடம் உள்ளன. ஒவ்வொரு அலமாரியிலும் அந்த தலைப்பில் புத்தகங்கள் உள்ளன. சில புத்தகங்களில் குறிப்புகளுடன் கூடிய காகித புக்மார்க்குகள் கூட உள்ளன. எங்களிடம் அனைத்து புத்தகங்களின் சிறிய காகித பட்டியலும் உள்ளது. பள்ளி நூலகங்களை நீங்கள் நினைவில் வைத்திருந்தால், அவை காகித அட்டைகளுடன் கூடிய குறுகிய டிராயர்கள் போன்றவை. இந்த ஒப்புமையில், புத்தக அலமாரி என்பது நமது சாதனத்தின் சுயவிவரம். அலமாரிகள் சேவைகள், புத்தகங்கள் பண்புகள், மற்றும் பட்டியல் என்பது ஒரு பண்புக்கூறு அட்டவணை. புத்தகங்களில் உள்ள புக்மார்க்குகள் விளக்கங்கள், அவற்றை நான் பின்னர் விரிவாக விவாதிப்பேன்.
சாதனங்களை உருவாக்கிய எவருக்கும் பல திட்டங்களில் ஒரே மாதிரியான குறியீடு துண்டுகள் இருப்பதைத் தெரியும். ஏனென்றால் பல சாதனங்கள் ஒரே மாதிரியான செயல்பாட்டைக் கொண்டுள்ளன. எடுத்துக்காட்டாக, சாதனங்கள் பேட்டரியால் இயங்கும் என்றால், சார்ஜ் செய்வதிலும் அவற்றின் அளவைக் கண்காணிப்பதிலும் உள்ள சிக்கல் ஒரே மாதிரியாக இருக்கும். சென்சார்களுக்கும் இது பொருந்தும். அடிப்படையில், நிரலாக்கத்திற்கான ஒரு பொருள் சார்ந்த அணுகுமுறை. "பண்புகளையும் நடத்தைகளையும் இணைத்து மீண்டும் பயன்படுத்தக்கூடிய ஒரு தன்னிறைவான ஒன்றியமாக பொருட்களை உருவாக்கும் திறனை வழங்குகிறது."என் கருத்துப்படி, BLE இதேபோன்ற அணுகுமுறையை முயற்சித்தது. புளூடூத் சிறப்பு ஆர்வக் குழு (SIG) சுயவிவரங்களை உருவாக்கியது. ஒரே மாதிரியான சுயவிவரங்களைக் கொண்ட வெவ்வேறு உற்பத்தியாளர்களின் சாதனங்கள் ஒன்றுக்கொன்று தடையின்றி செயல்பட வேண்டும். சுயவிவரங்கள், சேவைகளைக் கொண்டிருக்கின்றன, மேலும் சேவைகள் விளக்கங்களால் கூடுதலாக வழங்கப்பட்ட பண்புகளைக் கொண்டிருக்கின்றன. பொதுவாக, இது இப்படி இருக்கலாம்:

உதாரணமாக, இதய துடிப்பு மானிட்டருக்கான (உடற்தகுதி வளையல்) சுயவிவர வரைபடத்தைப் பார்ப்போம். இது இரண்டு சேவைகள் மற்றும் பல அம்சங்களைக் கொண்டுள்ளது. இந்த வரைபடத்திலிருந்து சுயவிவர படிநிலை உடனடியாகத் தெளிவாகிறது. சோதனைச் சாவடி அம்சம் ஒட்டுமொத்த கலோரி செலவின எண்ணிக்கையை பூஜ்ஜியத்திற்கு மீட்டமைக்கிறது.
1. இதய துடிப்பு சேவை மூன்று பண்புகளை உள்ளடக்கியது (0x180D):
அ) கட்டாய இதய துடிப்பு பண்பு (0x2A37)
b) விருப்ப உடல் சென்சார் நிலை அளவுரு (0x2A38)
c) இதய துடிப்பு கட்டுப்பாட்டு புள்ளியின் நிபந்தனை பண்பு (0x2A39)
2. பேட்டரி பராமரிப்பு சேவை (0x180F):
a) கட்டாய பேட்டரி நிலை பண்புக்கூறு (0x2A19)
UUID,
சுயவிவர கூறுகளை (சேவைகள், பண்புகள் மற்றும் விளக்கங்கள்) தனித்துவமாக அணுக, அவை அனைத்தும் எண்ணிடப்பட வேண்டும். இதற்காக, உலகளாவிய தனித்துவமான ஐடி (UUID) என்ற கருத்து அறிமுகப்படுத்தப்பட்டுள்ளது. ஒவ்வொரு வரியிலும் அடைப்புக்குறிக்குள் UUID குறிப்பிடப்பட்டுள்ளது. மேலும் இங்கே ஒரு தனித்தன்மை உள்ளது. UUID களுக்கு 16- மற்றும் 128-பிட் குறியீட்டைப் பயன்படுத்த அவர்கள் முடிவு செய்தனர். ஏன், நீங்கள் கேட்கிறீர்களா? BLE நெறிமுறை ஆற்றல் பாதுகாப்பைப் பற்றியது. எனவே, 16-பிட் குறியீடு மிகவும் நியாயமானது. எதிர்காலத்தில் 65 க்கும் மேற்பட்ட தனித்துவமான சேவைகள் மற்றும் பண்புகள் உருவாக்கப்படுவது சாத்தியமில்லை. இந்த கட்டத்தில், எண்ணக்கூடிய அனைத்தும் ஏற்கனவே எண்ணப்பட்டுள்ளன ("அது உங்களையும் எண்ணியது" என்ற பழமொழி எங்கிருந்து வருகிறது என்பதை நினைவில் கொள்ளுங்கள் :-)) எண்ணிடப்பட்ட கூறுகள் , , и நீங்கள் இணைப்புகளைப் பார்க்கலாம்.
இருப்பினும், இணையத்தில் 4-பைட் ஐபி முகவரியின் கதையை அனைவரும் நினைவில் வைத்திருப்பார்கள் என்று நினைக்கிறேன். முதலில், அது போதுமானது என்று அவர்கள் நினைத்தார்கள், ஆனால் இப்போது நாங்கள் இன்னும் 6-பைட் முகவரிக்கு மாற போராடி வருகிறோம். இந்த தவறை மீண்டும் செய்யாமல் இருக்கவும், DIY ஆர்வலர்களின் குறும்புத்தனமான கைகளுக்கு சுதந்திரம் அளிக்கவும், SIG உடனடியாக 128-பிட் UUIDகளை அறிமுகப்படுத்த முடிவு செய்தது. இது உரிமம் பெறாத 433 MHz அலைவரிசையை நினைவூட்டுகிறது, இது அனைத்து வகையான ரேடியோ சேனல் ஹேக்குகளுக்கும் வழங்கப்பட்டது. எங்கள் விஷயத்தில், எங்களுக்கு 128-பிட் சேவை மற்றும் சிறப்பியல்பு அடையாளங்காட்டி வழங்கப்பட்டது. இதன் பொருள் எங்கள் சேவைகள் மற்றும் சாதனங்களுக்கு கிட்டத்தட்ட எந்த 128-பிட் மதிப்பையும் பயன்படுத்தலாம். அனைவரும் ஒரே UUID உடன் வருவதற்கான வாய்ப்பு மிகக் குறைவு.
உண்மையில், குறுகிய 16-பிட் UUIDகள் 128-பிட் மதிப்புக்கு அவற்றின் சொந்த நீட்டிப்பைக் கொண்டுள்ளன. விவரக்குறிப்பில், இந்த நீட்டிப்பு Bluetooth அடிப்படை UUID என்று அழைக்கப்படுகிறது மற்றும் 00000000-0000-1000-8000-00805F9B34FB மதிப்பைக் கொண்டுள்ளது. எடுத்துக்காட்டாக, ஒரு பண்புக்கூறின் 16-பிட் UUID 0x1234 மதிப்பைக் கொண்டிருந்தால், அதற்கு சமமான 128-பிட் UUID 00001234-0000-1000-8000-00805F9B34FB மதிப்பைக் கொண்டிருக்கும். தொடர்புடைய சூத்திரம் கூட வழங்கப்படுகிறது:
128_பிட்_மதிப்பு = 16_பிட்_மதிப்பு * 2^96 + புளூடூத்_அடிப்படை_யுஐடி
இந்த மேஜிக் எண் எங்கிருந்து வந்தது என்று எனக்குத் தெரியவில்லை. வாசகர்கள் யாருக்காவது தெரிந்தால், தயவுசெய்து கருத்துகளில் எழுதுங்கள் (சினோப்டீக் என்ற புனைப்பெயரை கொண்ட ஒரு பயனர் ஏற்கனவே அவ்வாறு செய்துள்ளார். கருத்துகளைப் பார்க்கவும்). 128-பிட் UUIDகளை உருவாக்குவதற்கு, கொள்கையளவில், நீங்கள் ஒரு சிறப்புப் நிரலைப் பயன்படுத்தலாம். , இது உங்களுக்குச் செய்யும்.
ATTகள் GATTகள்…
இப்போது வேடிக்கையான பகுதி வருகிறது. ATT என்பது கிளையன்ட்-சர்வர் உறவை அடிப்படையாகக் கொண்டது என்பதை நான் உங்களுக்கு நினைவூட்டுகிறேன். இப்போது நாம் சர்வர் சாதனத்தைப் பார்க்கிறோம். இது சென்சார் மதிப்புகள், லைட் சுவிட்ச் நிலை, இருப்பிடத் தரவு மற்றும் பல போன்ற தகவல்களைக் கொண்டுள்ளது. இப்போது "எங்கள் அணிவகுப்பில் பங்கேற்பாளர்கள்" அனைவரும் எண்ணிடப்பட்டுள்ளதால், அவற்றை எப்படியாவது சாதனத்தின் நினைவகத்தில் சேமிக்க வேண்டும். இதைச் செய்ய, அவற்றை பண்புக்கூறு அட்டவணை எனப்படும் அட்டவணையில் வைக்கிறோம். இதை கவனமாக நினைவில் கொள்ளுங்கள். இது BLE இன் மையப்பகுதி. இதைத்தான் நாங்கள் மேலும் ஆராய்வோம். இனிமேல், ஒவ்வொரு வரிசையையும் ஒரு பண்புக்கூறு என்று அழைப்போம். இந்த அட்டவணை அடுக்கின் ஆழத்தில் அமைந்துள்ளது, ஒரு விதியாக, எங்களுக்கு நேரடி அணுகல் இல்லை. நாங்கள் அதை துவக்கி அணுகுகிறோம், ஆனால் உள்ளே என்ன நடக்கிறது என்பது ஒரு மர்மம்.
விவரக்குறிப்பிலிருந்து படத்தைப் பார்ப்போம், ஆனால் அதற்கு முன், சொற்களில், குறிப்பாக விளக்கிகளில், ஒரு பொதுவான குழப்பத்தை நான் சுட்டிக்காட்ட விரும்புகிறேன். ஒரு விளக்கியின் பங்கு, ஒரு பண்பின் விளக்கத்தை கூடுதலாக வழங்குவதாகும். அதன் திறன்களை விரிவாக்க வேண்டியிருக்கும் போது விளக்கிகள் பயன்படுத்தப்படுகின்றன. அவை பண்புக்கூறுகள் ஆகும், மேலும், சேவைகள் மற்றும் பண்புகள் போலவே, பண்புக்கூறு அட்டவணையில் அமைந்துள்ளன. கட்டுரையின் இரண்டாம் பகுதியில் அவற்றை விரிவாக விவாதிப்போம். இருப்பினும், சில நேரங்களில் பண்புக்கூறு அட்டவணையில் ஒரு வரிசை எண்ணைக் குறிக்க விளக்கிகளைப் பயன்படுத்துகிறோம். இதை மனதில் கொள்ள வேண்டும். குழப்பத்தைத் தவிர்க்க, இந்த நோக்கங்களுக்காக "பண்புக்கூறு சுட்டிக்காட்டி" என்ற வார்த்தையைப் பயன்படுத்துவோம்.

எனவே ஒரு பண்புக்கூறு என்பது பின்வரும் பண்புகளுடன் தொடர்புடைய ஒரு தனித்துவமான மதிப்பாகும்:
1. பண்புக்கூறு கைப்பிடி என்பது ஒரு பண்புக்கூறுடன் தொடர்புடைய அட்டவணை குறியீடாகும்.
2. பண்புக்கூறு வகை என்பது அதன் வகையை விவரிக்கும் ஒரு UUID ஆகும்.
3. பண்புக்கூறு மதிப்பு என்பது பண்புக்கூறு சுட்டிக்காட்டியால் குறியிடப்பட்ட தரவு.
4. பண்புக்கூறு அனுமதிகள் என்பது பண்புக்கூறு நெறிமுறையைப் பயன்படுத்தி படிக்கவோ எழுதவோ முடியாத ஒரு பண்புக்கூறின் பகுதியாகும்.
இதையெல்லாம் நாம் எப்படிப் புரிந்து கொள்ள வேண்டும்? ஒரு பண்புக்கூறின் குறியீடு என்பது, தோராயமாகச் சொன்னால், நமது அட்டவணையில் உள்ள அதன் எண்ணாகும்.
இது வாடிக்கையாளரை படிக்க அல்லது எழுத கோரிக்கைகளில் ஒரு பண்புக்கூறைக் குறிப்பிட அனுமதிக்கிறது. 0x0001 முதல் 0xFFFF வரையிலான நமது வரிகளை (பண்புக்கூறுகளை) எண்ணலாம். நமது புத்தக அலமாரி உருவகத்தில், இது ஒரு காகித பட்டியலில் உள்ள அட்டை எண். இதேபோல், ஒரு நூலக பட்டியலில் உள்ளதைப் போலவே, அட்டைகள் ஏறுவரிசையில் அமைக்கப்பட்டிருக்கும். ஒவ்வொரு அடுத்தடுத்த வரியின் எண்ணிக்கையும் முந்தையதை விட அதிகமாக இருக்க வேண்டும். ஒரு நூலகத்தில் இருப்பது போலவே, அட்டைகள் சில நேரங்களில் தொலைந்து போகும், எனவே நமது வரி எண்களிலும் இடைவெளிகள் இருக்கலாம். இது ஏற்றுக்கொள்ளத்தக்கது. முக்கிய விஷயம் என்னவென்றால், அவை ஏறுவரிசையில் உள்ளன.
பண்புக்கூறு வகை, பண்புக்கூறு எதைக் குறிக்கிறது என்பதை வரையறுக்கிறது. C மொழியைப் போலவே,
பூலியன், எண் மாறிகள் மற்றும் சரங்கள் இருக்கும் இடங்களில், அது இங்கேயும் ஒன்றுதான். பண்புக்கூறு வகையைப் பொறுத்தவரை, நமக்குத் தெரியும்
இங்கே நாம் எதைக் கையாள்கிறோம், இந்தப் பண்புக்கூறுடன் எவ்வாறு தொடர வேண்டும்? கீழே, சில குறிப்பிட்ட பண்புக்கூறு வகைகளைப் பார்ப்போம். எடுத்துக்காட்டாக, "சேவை அறிவிப்பு" (0x2800), "பண்பு அறிவிப்பு" (0x2803), மற்றும் "விளக்க அறிவிப்பு" (0x2902).
ஒரு பண்புக்கூறின் மதிப்பு அதன் உண்மையான மதிப்பு, மன்னிக்கவும், tautology. பண்புக்கூறின் வகை ஒரு சரமாக இருந்தால், அதன் மதிப்பு, எடுத்துக்காட்டாக, "வணக்கம் உலகம்!!!" என்ற வாசகமாக இருக்கலாம். பண்புக்கூறின் வகை "சேவை அறிவிப்பாக" இருந்தால், அதன் மதிப்பு சேவையே ஆகும். சில நேரங்களில், இது மற்ற பண்புக்கூறுகள் மற்றும் அவற்றின் பண்புகளை எங்கே கண்டுபிடிப்பது என்பது பற்றிய தகவலாக இருக்கும்.
பண்புக்கூறு அனுமதிகள், சேவையகம் படிக்க அல்லது எழுத அணுகல் அனுமதிக்கப்படுகிறதா என்பதைத் தீர்மானிக்க அனுமதிக்கின்றன.
இந்த அனுமதிகள் பண்புக்கூறு மதிப்புக்கு மட்டுமே பொருந்தும், சுட்டிக்காட்டி, வகை அல்லது அனுமதி புலத்திற்கு அல்ல என்பதை நினைவில் கொள்ளவும். எனவே, ஒரு பண்புக்கூறு எழுதக்கூடியதாக இருந்தால், எடுத்துக்காட்டாக, "ஹலோ வேர்ல்ட்!!!" சரத்தை "காலை வணக்கம்" என்று மாற்றலாம். இருப்பினும், ஒரு புதிய வரியை எழுதுவதைத் தடைசெய்யவோ அல்லது பண்புக்கூறு வகையை மாற்றவோ மற்றும் சரத்தை "சேவை அறிவிப்பு" என்று நியமிக்கவோ முடியாது. ஒரு கிளையன்ட் ஒரு சேவையகத்தை அணுகும்போது, கிளையன்ட் அதன் பண்புக்கூறுகளைக் கோருகிறது. மதிப்புகளைப் படிப்பதும் எழுதுவதும் தேவையில்லை என்றாலும், சேவையகம் என்ன வழங்க முடியும் என்பதை கிளையன்ட் தீர்மானிக்க இது அனுமதிக்கிறது.
அது எப்படி இருக்கும்
GATT இன் கருத்து என்னவென்றால், ஒரு பண்புக்கூறு அட்டவணையில் உள்ள பண்புக்கூறுகளை மிகவும் குறிப்பிட்ட மற்றும் தர்க்கரீதியான வரிசையில் ஒன்றாகக் குழுவாக்குவதாகும். கீழே உள்ள இதய துடிப்பு சுயவிவரத்தை உற்று நோக்கலாம். இந்த அட்டவணையின் இடதுபுற நெடுவரிசை விருப்பத்திற்குரியது. இது இந்த வரிசை (பண்புக்கூறு) என்ன என்பதை விவரிக்கிறது. மற்ற அனைத்து நெடுவரிசைகளும் ஏற்கனவே பரிச்சயமானவை.

ஒவ்வொரு குழுவின் மேலேயும், எங்களிடம் எப்போதும் ஒரு சேவை அறிவிப்பு பண்புக்கூறு இருக்கும். அதன் வகை எப்போதும் 0x2800 ஆகும், மேலும் அதன் குறியீடு அட்டவணையில் ஏற்கனவே எத்தனை பண்புக்கூறுகள் உள்ளன என்பதைப் பொறுத்தது. அதன் அனுமதிகள் எப்போதும் படிக்க மட்டுமே, எந்த அங்கீகாரமோ அல்லது அங்கீகாரமோ இல்லாமல். இந்த கருத்துக்களைப் பற்றி பின்னர் விவாதிப்போம். மதிப்பு சேவையை அடையாளம் காணும் மற்றொரு UUID ஆகும். அட்டவணையில், மதிப்பு 0x180D ஆகும், இது புளூடூத் SIG ஆல் இதய துடிப்பு சேவையாக வரையறுக்கப்படுகிறது.
சேவை அறிவிப்பைத் தொடர்ந்து பண்புக்கூறு அறிவிப்பு உள்ளது. இது சேவை அறிவிப்பைப் போன்ற வடிவத்தில் உள்ளது. அதன் UUID எப்போதும் 0x2803 ஆகும், மேலும் அதன் அனுமதிகளும் எந்த அங்கீகாரமோ அல்லது அங்கீகாரமோ இல்லாமல் எப்போதும் படிக்க மட்டுமே. சில தரவைக் கொண்ட பண்புக்கூறு மதிப்பு புலத்தைப் பார்ப்போம். இது எப்போதும் ஒரு சுட்டிக்காட்டி, ஒரு UUID மற்றும் பண்புகளின் தொகுப்பைக் கொண்டுள்ளது. இந்த மூன்று கூறுகளும் அடுத்தடுத்த பண்புக்கூறு மதிப்பு அறிவிப்பை விவரிக்கின்றன. பண்புக்கூறு அட்டவணையில் பண்புக்கூறு மதிப்பு அறிவிப்பின் இருப்பிடத்தை சுட்டிக்காட்டி இயல்பாகவே குறிக்கிறது. UUID நாம் எதிர்பார்க்கக்கூடிய தகவல் அல்லது மதிப்பை விவரிக்கிறது - எடுத்துக்காட்டாக, வெப்பநிலை மதிப்பு, ஒரு ஒளி சுவிட்சின் நிலை அல்லது வேறு சில தன்னிச்சையான மதிப்பு. இறுதியாக, பண்புகள் பண்புக்கூறு மதிப்புடன் எவ்வாறு தொடர்பு கொள்வது என்பதை விவரிக்கின்றன.
இங்கே நமக்கு இன்னொரு ஆபத்து காத்திருக்கிறது. அது பண்புக்கூறு அனுமதிகள் மற்றும் சிறப்பியல்பு பண்புகளுடன் தொடர்புடையது. விவரக்குறிப்பிலிருந்து பிட்ஃபீல்ட் பண்புகளின் படத்தைப் பார்ப்போம்.

நீங்கள் பார்க்க முடியும் என, படிக்க மற்றும் எழுத அணுகலை வழங்கும் புலங்களும் இங்கே உள்ளன. பண்புக்கூறு மற்றும் பண்புக்கு ஏன் படிக்க/எழுத அனுமதிகள் உள்ளன என்று நீங்கள் யோசிக்கலாம்.
ஒரு பண்பு மதிப்புக்கான படிக்க/எழுத அனுமதிகள்? அவை எப்போதும் ஒரே மாதிரியாக இருக்க வேண்டாமா? விஷயம் என்னவென்றால், ஒரு பண்பு மதிப்புக்கான பண்புகள் அடிப்படையில் GATT மற்றும் பயன்பாட்டு அடுக்குகளில் பயன்படுத்தப்படும் கிளையன்ட் பரிந்துரைகள் மட்டுமே. அவை பண்பு அறிவிப்பு பண்புக்கூறிலிருந்து கிளையன்ட் என்ன எதிர்பார்க்கலாம் என்பதற்கான குறிப்புகள் மட்டுமே. இதை இன்னும் விரிவாகப் பார்ப்போம். ஒரு பண்புக்கூறுக்கு என்ன வகையான அனுமதிகள் உள்ளன?
1. அணுகல் அனுமதிகள்:
— வாசிப்பு
— பதிவு செய்தல்
— வாசிப்பு மற்றும் எழுதுதல்
2. அங்கீகார அனுமதி:
— அங்கீகாரம் தேவை
- அங்கீகாரம் தேவையில்லை
3. அங்கீகார அனுமதி:
- அங்கீகாரம் தேவை
- எந்த அங்கீகாரமும் தேவையில்லை
பண்புக்கூறு அனுமதிகளுக்கும் சிறப்பியல்பு பண்புகளுக்கும் இடையிலான முக்கிய வேறுபாடு என்னவென்றால், முந்தையவை சேவையகம் சார்ந்தவை, பிந்தையவை கிளையன்ட் சார்ந்தவை. ஒரு சேவையகம் ஒரு பண்பின் மதிப்பைப் படிக்க அனுமதிக்கலாம், ஆனால் இன்னும் அங்கீகாரம் அல்லது அங்கீகாரம் தேவைப்படுகிறது. எனவே, ஒரு கிளையன்ட் ஒரு பண்பின் பண்புகளைக் கோரும்போது, வாசிப்பு அனுமதிக்கப்படுவதைக் காண்போம். இருப்பினும், அவற்றைப் படிக்க முயற்சிப்பது பிழையை ஏற்படுத்தும். எனவே, பண்புகளை விட அனுமதிகள் முன்னுரிமை பெறுகின்றன என்று நாம் பாதுகாப்பாகச் சொல்லலாம். கிளையன்ட் தரப்பில், ஒரு பண்புக்கூறு என்ன அனுமதிகளைக் கொண்டுள்ளது என்பதை அறிய எங்களுக்கு எந்த வழியும் இல்லை.
விவரிப்பான்
நமது அட்டவணைக்குத் திரும்புவோம். பண்பு மதிப்பை அறிவித்த பிறகு, பின்வரும் பண்புக்கூறு அறிவிப்புகள் சாத்தியமாகும்:
1. புதிய சிறப்பியல்பு அறிவிப்பு (ஒரு சேவையில் பல பண்புகள் இருக்கலாம்)
2. புதிய சேவை அறிவிப்பு (அட்டவணையில் அவற்றில் பல இருக்கலாம்)
3. விவரிப்பாளரின் பிரகடனம்
எங்கள் அட்டவணையில் உள்ள இதய துடிப்பு அளவீட்டு பண்புகளைப் பொறுத்தவரை, பண்பு மதிப்பின் அறிவிப்பு ஒரு விளக்க அறிவிப்புடன் இணைக்கப்பட்டுள்ளது. ஒரு விளக்கமானது பண்பு பற்றிய கூடுதல் தகவல்களைக் கொண்ட ஒரு பண்புக்கூறு ஆகும். பல வகையான விளக்கங்கள் உள்ளன, அவற்றை இந்தக் கட்டுரையின் இரண்டாம் பகுதியில் விரிவாக விவாதிப்போம். இப்போதைக்கு, கிளையன்ட் சிறப்பியல்பு உள்ளமைவு விளக்கத்தை (CCCD) மட்டுமே தொடுவோம். இது 0x2902 இன் UUID ஐக் கொண்டுள்ளது. இந்த விளக்கத்தைப் பயன்படுத்தி, கிளையன்ட் சர்வரில் ஒரு அறிகுறி அல்லது அறிவிப்பை இயக்க முடியும். அவற்றுக்கிடையேயான வேறுபாடு நுட்பமானது, ஆனால் இன்னும் உள்ளது. அறிவிப்புக்கு கிளையண்டிடமிருந்து ரசீதுக்கான ஒப்புதல் தேவையில்லை. அறிகுறி, இது பயன்பாட்டு மட்டத்தில் அல்ல, GATT மட்டத்தில் நிகழ்கிறது. இது ஏன் அப்படி என்று நீங்கள் கேட்கிறீர்களா? துரதிர்ஷ்டவசமாக, எனக்குத் தெரியவில்லை. நோர்டிக் நிபுணர்கள் அறிவிப்பைப் பயன்படுத்த பரிந்துரைக்கிறார்கள் என்று நான் கூறுவேன். மேலும், பாக்கெட் ஒருமைப்பாடு சரிபார்ப்பு (CRC ஐப் பயன்படுத்தி) இரண்டு நிகழ்வுகளிலும் நிகழ்கிறது.
முடிவுக்கு
கட்டுரையின் இறுதியில், நான் பின்வருவனவற்றைச் சொல்ல விரும்புகிறேன். கடைசி அட்டவணை சற்று குழப்பமாக இருக்கிறது. இருப்பினும், அது கொடுக்கப்பட்டுள்ளதால் நான் அதை நிறுத்திவிட்டேன் , நான் அதை நம்பி இருக்கிறேன். எனது கட்டுரையின் இரண்டாம் பகுதியில், புளூடூத் 4.0 விவரக்குறிப்பை ஆழமாக ஆராய விரும்புகிறேன். அங்கு இன்னும் துல்லியமான வரைபடங்கள் மற்றும் விளக்கப்படங்கள் நமக்காகக் காத்திருக்கின்றன. மூன்றாவது பகுதியில், Wireshark ஐப் பயன்படுத்தி கேஜெட்களில் ஒன்றிலிருந்து பெறப்பட்ட ஒரு பதிவை பகுப்பாய்வு செய்து, நாம் படித்து வரும் அனைத்து கோட்பாடுகளையும் செயல்பாட்டில் காண விரும்புகிறேன்.
குழும நிறுவனங்களின் ஊழியர்
விளாடிமிர் பெச்செர்ஸ்கி
ஆதாரம்: www.habr.com
