BLE მიკროსკოპის ქვეშ (ATTы GATTы…)

BLE მიკროსკოპის ქვეშ (ATTы GATTы…)

ნაწილი 1, მიმოხილვა

უკვე საკმაოდ დიდი დრო გავიდა Bluetooth 4.0-ის პირველი სპეციფიკაციის გამოქვეყნებიდან. და, მიუხედავად იმისა, რომ BLE თემა ძალიან საინტერესოა, ის მაინც აჩერებს ბევრ დეველოპერს მისი სირთულის გამო. ჩემს წინა სტატიებში მე ძირითადად ვუყურებდი ყველაზე დაბალ დონეს, Link Layer და Physical Layer. ამან საშუალება მოგვცა, აგვეცილებინა ისეთი რთული და დამაბნეველი ცნებები, როგორიცაა ატრიბუტის პროტოკოლი (ATT) და ზოგადი ატრიბუტის პროფილი (GATT). თუმცა, წასასვლელი არსად არის, მათი გაგების გარეშე შეუძლებელია თავსებადი მოწყობილობების შემუშავება. დღეს მინდა გაგიზიაროთ ეს ცოდნა. ჩემს სტატიაში დავეყრდნობით სახელმძღვანელო დამწყებთათვის Nordic ვებსაიტიდან. ასე რომ, დავიწყოთ.

რატომ არის ყველაფერი ასე რთული?

ჩემი აზრით, მაშინვე გაირკვა, რომ სმარტფონების საშუალებით მოწყობილობების მართვა ძალიან პერსპექტიული და გრძელვადიანი თემაა. ამიტომ, მათ გადაწყვიტეს მისი სტრუქტურირება დაუყოვნებლივ და მაქსიმალურად. ისე, რომ სხვადასხვა გაჯეტების მწარმოებლებმა არ გამოიგონონ საკუთარი პროტოკოლები, რომლებიც შემდეგ შეუთავსებელი იქნება. აქედან გამომდინარეობს სირთულე. უკვე პირველ ეტაპზე, ისინი ცდილობდნენ BLE პროტოკოლში ჩაეჭიმათ ყველაფერი რაც შესაძლებელი იყო. და არ აქვს მნიშვნელობა, იქნება ეს მოგვიანებით სასარგებლო თუ არა. გარდა ამისა, ისინი ითვალისწინებდნენ სამომავლო მოწყობილობების სიის გაფართოების შესაძლებლობას.

მოდით შევხედოთ სურათს, სადაც დახატულია BLE პროტოკოლის დიაგრამა. იგი შედგება რამდენიმე ფენისგან. ყველაზე დაბალი ფიზიკური ფენა (PHY) პასუხისმგებელია მოწყობილობის რადიო არხზე. Link Layer(LL) შეიცავს გადაცემულ შეტყობინებაში ბაიტების მთელ თანმიმდევრობას. წინა სტატიებში სწორედ ეს შევისწავლეთ. Host Controller Interface (HCI) არის გაცვლის პროტოკოლი BLE ფენებს ან ჩიპებს შორის, თუ კონტროლერი და ჰოსტი დანერგილია სხვადასხვა ჩიპებზე. ლოგიკური კავშირის კონტროლისა და ადაპტაციის პროტოკოლი (L2CAP) პასუხისმგებელია პაკეტის ფორმირებაზე, ჩარჩოში, შეცდომების კონტროლსა და პაკეტის შეკრებაზე. უსაფრთხოების მენეჯერის პროტოკოლი (SMP) პასუხისმგებელია პაკეტების დაშიფვრაზე. ზოგადი წვდომის პროფილი (GAP) პასუხისმგებელია მოწყობილობებს შორის მონაცემების თავდაპირველ გაცვლაზე, რათა დადგინდეს „ვინ არის ვინ“. იგი ასევე მოიცავს სკანირებას და რეკლამას. ამ სტატიაში ყურადღებას გავამახვილებ პროტოკოლის ორ დანარჩენ ნაწილზე - GATT და ATT. GATT არის ATT-ის სუპერსტრუქტურა, ამიტომ ისინი მჭიდროდ არიან გადაჯაჭვული.

სიუჟეტის გასამარტივებლად, მინდა მივმართო ანალოგიას. სადღაც გავიგე და მინდა მხარი დავუჭირო. წარმოიდგინეთ BLE მოწყობილობა, როგორც წიგნის კარადა რამდენიმე თაროებით. თითოეული თარო ცალკე თემაა. მაგალითად, გვაქვს თაროები სამეცნიერო ფანტასტიკით, მათემატიკით და ენციკლოპედიებით. თითოეულ თაროზე არის წიგნები მითითებული თემით. ზოგიერთ წიგნს კი აქვს ქაღალდის სანიშნეები შენიშვნებით. გარდა ამისა, ჩვენ გვაქვს ყველა წიგნის პატარა ქაღალდის კატალოგი. თუ გახსოვთ, სკოლის ბიბლიოთეკები არის ვიწრო ყუთი ქაღალდის ბარათებით. ამ ანალოგიით, კაბინეტი ჩვენი მოწყობილობის პროფილია. თაროები არის სერვისები, წიგნები არის მახასიათებლები, ხოლო კატალოგი არის ატრიბუტების ცხრილი. წიგნებში სანიშნეები არის აღწერები, რომლებზეც ასევე მოგვიანებით ვისაუბრებ უფრო დეტალურად.

ყველამ, ვინც შეიმუშავა მოწყობილობები, იცის, რომ ბევრ პროექტს აქვს მსგავსი კოდი. ფაქტია, რომ ბევრ მოწყობილობას აქვს მსგავსი ფუნქციონირება. მაგალითად, თუ მოწყობილობები იკვებება ბატარეებით, მაშინ მათი დონის დატენვის და მონიტორინგის პრობლემა იგივე იქნება. იგივე ეხება სენსორებს. სინამდვილეში, პროგრამირების ობიექტზე ორიენტირებული მიდგომა "უზრუნველჰყოფს ობიექტების შექმნის შესაძლებლობას, რომლებიც აერთიანებს თვისებებს და ქცევებს თვითმყოფად გაერთიანებაში, რომელიც შემდგომ შეიძლება ხელახლა იქნას გამოყენებული". ჩემი აზრით, BLE ცდილობდა მსგავსი მიდგომა. პროფილები შემუშავდა Bluetooth სპეციალური ინტერესების ჯგუფის (SIG) მიერ. სხვადასხვა მწარმოებლის მოწყობილობები, რომლებსაც აქვთ იგივე პროფილები, უნდა მუშაობდნენ ერთმანეთთან სირთულის გარეშე. პროფილები, თავის მხრივ, შედგება სერვისებისა და მახასიათებლების სერვისებისგან, დამატებული აღწერებით. ზოგადად შეიძლება ასე გამოიყურებოდეს:

მაგალითად, განიხილეთ გულისცემის მონიტორის პროფილის დიაგრამა (ფიტნეს სამაჯური). იგი შედგება ორი სერვისისა და რამდენიმე მახასიათებლისგან. მისგან პროფილის იერარქია მაშინვე ცხადი ხდება. გამშვები პუნქტის მახასიათებელი აღადგენს კალორიების დახარჯვის მთლიან რაოდენობას ნულამდე.

1. გულისცემის სერვისი მოიცავს სამ მახასიათებელს (0x180D):
    ა) გულისცემის სავალდებულო მახასიათებელი (0x2A37)
    ბ) სხეულის სენსორის პოზიციის არჩევითი მახასიათებელი (0x2A38)
    გ) გულისცემის საკონტროლო წერტილის პირობითი მახასიათებლები (0x2A39)
2. ბატარეის ტექნიკური მომსახურება (0x180F):
    ა) ბატარეის სავალდებულო დატენვის დონის მახასიათებელი (0x2A19)

UUID

იმისათვის, რომ ჩვენ უნიკალური წვდომა გვქონდეს პროფილის ელემენტებზე (მომსახურებებზე, მახასიათებლებზე და აღწერებზე), ჩვენ ყველა როგორმე უნდა დავნომროთ. ამ მიზნით დაინერგა ისეთი კონცეფცია, როგორიცაა უნივერსალურად უნიკალური ID (UUID) ან უნივერსალურად უნიკალური იდენტიფიკატორი. UUID მითითებულია თითოეული ხაზის ფრჩხილებში. და აქ არის ერთი თავისებურება. UUID-სთვის გადავწყვიტეთ გამოგვეყენებინა 16 და 128 ბიტიანი კოდი. Რატომ კითხულობ? BLE პროტოკოლში ყველაფერი ენერგიის დაზოგვას ეხება. ამიტომ, 16 ბიტიანი განზომილება საკმაოდ გონივრულია. ნაკლებად სავარაუდოა, რომ უახლოეს მომავალში 65 ათასზე მეტი შეიქმნას. უნიკალური სერვისები და მახასიათებლები. ამ მომენტში ყველაფერი, რაც შეიძლებოდა უკვე დათვლილი ყოფილიყო (გახსოვდეთ, საიდან გაჩნდა ეს - "მანაც დაგითვალა" :-)) დანომრილი ელემენტები პროფილები, მომსახურება, მახასიათებლები и აღწერები შეგიძლიათ ნახოთ ლინკები.

თუმცა, ვფიქრობ, ყველას ახსოვს ამბავი ინტერნეტში 4 ბაიტი IP მისამართით. თავიდან საკმარისად გვეგონა, მაგრამ ახლა მაინც ვერ გადავდივართ 6 ბაიტიან მისამართზე. იმისთვის, რომ ეს შეცდომა არ განმეორდეს და წვრილმანი ხელებით ხელები არ მიეცეს, SIG-მა მაშინვე გადაწყვიტა 128-ბიტიანი UUID-ების დანერგვა. ეს პირადად მახსენებს არალიცენზირებულ 433 MHz დიაპაზონს, რომელიც გადაეცა ყველა სახის Kulibins-ს რადიო არხიდან. ჩვენს შემთხვევაში, 128-ბიტიანი სერვისებისა და მახასიათებლების იდენტიფიკატორი იქნა შემუშავებული. ეს ნიშნავს, რომ ჩვენ, ჩვენი სერვისებისა და მოწყობილობებისთვის, შეგვიძლია გამოვიყენოთ თითქმის ნებისმიერი 128-ბიტიანი მნიშვნელობა. ერთი და იგივე, ერთი და იგივე UUID-ის გამოჩენის ალბათობა ნულისკენ მიისწრაფვის.

სინამდვილეში, მოკლე 16-ბიტიან UUID-ებს აქვთ გაფართოება 128-ბიტიან მნიშვნელობამდე. სპეციფიკაციაში, ამ გაფართოებას ეწოდება Bluetooth Base UUID და აქვს მნიშვნელობა 00000000-0000-1000-8000-00805F9B34FB. თუ, მაგალითად, 16-ბიტიან UUID ატრიბუტს აქვს მნიშვნელობა 0x1234, მაშინ ექვივალენტურ 128-ბიტიან UUID-ს ექნება მნიშვნელობა 00001234-0000-1000-8000-00805F9B34FB. და შესაბამისი ფორმულაც კი მოცემულია:

                                128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID

არ ვიცი საიდან გაჩნდა ეს ჯადოსნური ნომერი. თუ რომელიმე მკითხველმა იცის, დაწეროს კომენტარებში (მომხმარებელმა მეტსახელად Sinopteek უკვე გააკეთა. იხილეთ კომენტარები). რაც შეეხება 128-ბიტიან UUID-ების შექმნას, პრინციპში შეგიძლიათ გამოიყენოთ სპეციალური გენერატორივინც ამას გააკეთებს თქვენთვის.

ATTy GATTy...

სინამდვილეში, მაშინ იწყება გართობა. შეგახსენებთ, რომ ATT დაფუძნებულია კლიენტ-სერვერის ურთიერთობაზე. ახლა ჩვენ ვუყურებთ სერვერის მოწყობილობას. ის შეიცავს ინფორმაციას, როგორიცაა სენსორის მნიშვნელობები, განათების გადამრთველის სტატუსი, მდებარეობის მონაცემები და ა.შ. ახლა, როდესაც ყველა "ჩვენი აღლუმის მონაწილე" დანომრილია, ჩვენ უნდა როგორმე მოვათავსოთ ისინი მოწყობილობის მეხსიერებაში. ამისათვის ჩვენ ვათავსებთ მათ ცხრილში სახელწოდებით ატრიბუტების ცხრილი. ეს კარგად დაიმახსოვრე. ეს არის BLE-ის გული. ეს არის ის, რასაც შემდგომ განვიხილავთ. ახლა თითოეულ ხაზს ატრიბუტს დავარქმევთ. ეს ცხრილი მდებარეობს სტეკის სიღრმეში და, როგორც წესი, მასზე პირდაპირი წვდომა არ გვაქვს. ჩვენ ვაკეთებთ მას ინიციალიზაციას და წვდომას ვახდენთ, მაგრამ ის, რაც შიგნით ხდება, ჩვენგან იმალება შვიდი ბეჭდის მიღმა.

მოდით შევხედოთ სურათს სპეციფიკაციებიდან, მაგრამ მანამდე მინდა დაუყოვნებლივ გავამახვილო ყურადღება ტერმინების, კერძოდ, აღწერების ხშირ დაბნეულობაზე. აღმწერის როლი არის შეავსოს მახასიათებლის აღწერა. როდესაც საჭიროა მისი შესაძლებლობების გაფართოება, მაშინ გამოიყენება დესკრიპტორები. ისინი ასევე ატრიბუტებია და ისევე როგორც სერვისები და მახასიათებლები, ისინი განლაგებულია ატრიბუტების ცხრილში. მათ დეტალურად განვიხილავთ სტატიის მეორე ნაწილში. თუმცა, ზოგჯერ აღწერები მიუთითებენ სტრიქონის ნომერზე ატრიბუტების ცხრილში. ეს უნდა იყოს მხედველობაში. დაბნეულობის თავიდან ასაცილებლად, ამ მიზნებისთვის გამოვიყენებთ ტერმინს „ატრიბუტის მაჩვენებელი“.


ამრიგად, ატრიბუტი არის დისკრეტული მნიშვნელობა, რომელსაც აქვს შემდეგი თვისებები:
1. ატრიბუტის სახელური არის ატრიბუტის შესაბამისი ცხრილის ინდექსი
2. ატრიბუტის ტიპი არის UUID, რომელიც აღწერს მის ტიპს
3. ატრიბუტის მნიშვნელობა არის ატრიბუტის მაჩვენებლის მიერ ინდექსირებული მონაცემები
4. ატრიბუტის ნებართვები არის ატრიბუტის ის ნაწილი, ნებართვები, რომელთა წაკითხვა ან ჩაწერა შეუძლებელია ატრიბუტის პროტოკოლის გამოყენებით.

როგორ გავიგოთ ეს ყველაფერი? ატრიბუტის მაჩვენებელი, შედარებით რომ ვთქვათ, არის მისი ნომერი ჩვენს ცხრილში.
ის საშუალებას აძლევს კლიენტს მიმართოს ატრიბუტს წაკითხვის ან ჩაწერის მოთხოვნებში. ჩვენ შეგვიძლია ჩვენი ხაზების (ატრიბუტების) დათვლა 0x0001-დან 0xFFFF-მდე. წიგნის კარადასთან ჩვენს ასოციაციაში, ეს არის ბარათის ნომერი ქაღალდის კატალოგში. ანალოგიურად, როგორც ბიბლიოთეკის კატალოგში, ბარათები განლაგებულია რაოდენობის ზრდის მიხედვით. ყოველი მომდევნო სტრიქონის რაოდენობა წინაზე მეტი უნდა იყოს. ისევე, როგორც ბიბლიოთეკაში, ზოგჯერ ზოგიერთი ბარათი იკარგება, ამიტომ ჩვენთან შეიძლება იყოს ხარვეზები ხაზების ნუმერაციაში. ეს დასაშვებია. მთავარია, რომ ისინი თანდათანობით მიდიან.

ატრიბუტის ტიპი განსაზღვრავს რას წარმოადგენს ატრიბუტი. C ენის ანალოგიით,
სადაც არის ლოგიკური, რიცხვითი ცვლადები და სტრიქონები, ასეა აქ. ჩვენ ვაღიარებთ ატრიბუტის ტიპის მიხედვით
რასთან გვაქვს საქმე და როგორ გავაგრძელოთ ამ ატრიბუტთან მუშაობა. ქვემოთ განვიხილავთ ატრიბუტების რამდენიმე სპეციფიკურ ტიპს. მაგალითად, „მომსახურების დეკლარაცია“ (0x2800), „მახასიათებელი დეკლარაცია“ (0x2803), „აღმწერის დეკლარაცია“ (0x2902).

ატრიბუტის მნიშვნელობა არის მისი რეალური მნიშვნელობა, აპატიეთ ტავტოლოგიას. თუ ატრიბუტის ტიპი არის სტრიქონი, მაშინ ატრიბუტის მნიშვნელობა შეიძლება იყოს, მაგალითად, სლოგანი "Hello World !!!". თუ ატრიბუტის ტიპი არის „მომსახურების დეკლარაცია“, მაშინ მისი მნიშვნელობა არის თავად სერვისი. და ზოგჯერ ეს არის ინფორმაცია იმის შესახებ, თუ სად უნდა იპოვოთ სხვა ატრიბუტები და მათი თვისებები.

ატრიბუტების ნებართვები საშუალებას აძლევს სერვერს გაიგოს, ნებადართულია თუ არა წაკითხვის ან ჩაწერის წვდომა.
გაითვალისწინეთ, რომ ეს ნებართვები ვრცელდება მხოლოდ ატრიბუტის მნიშვნელობაზე და არა თავად მაჩვენებელზე, ტიპზე ან ნებართვის ველზე. იმათ. თუ ატრიბუტის ჩაწერა დაშვებულია, მაშინ ჩვენ შეგვიძლია შევცვალოთ, მაგალითად, ხაზი "Hello World !!!" სტრიქონამდე "დილა მშვიდობისა". მაგრამ ჩვენ არ შეგვიძლია ავკრძალოთ ახალი სტრიქონის დაწერა ან შევცვალოთ ატრიბუტის ტიპი და დავნიშნოთ ხაზი, როგორც "მომსახურების დეკლარაცია". როდესაც კლიენტი დაუკავშირდება სერვერს, კლიენტი ითხოვს მის ატრიბუტებს. ეს საშუალებას აძლევს კლიენტს იცოდეს რა შეუძლია სერვერს. თუმცა არ არის აუცილებელი მნიშვნელობების წაკითხვა და ჩაწერა.

როგორ გამოიყურება

GATT-ის კონცეფცია არის ატრიბუტების დაჯგუფება ატრიბუტების ცხრილში ერთად ძალიან კონკრეტული და ლოგიკური თანმიმდევრობით. მოდით უფრო ახლოს მივხედოთ ქვემოთ მოცემულ გულისცემის პროფილს. ამ ცხრილის მარცხენა სვეტი არჩევითია. ის უბრალოდ აღწერს ჩვენთვის რა არის ეს ხაზი (ატრიბუტი). ყველა სხვა სვეტი ჩვენთვის უკვე ნაცნობია.

თითოეული ჯგუფის ზედა ნაწილში ყოველთვის გვაქვს სერვისის დეკლარაციის ატრიბუტი. მისი ტიპი ყოველთვის არის 0x2800 და მაჩვენებელი დამოკიდებულია იმაზე, თუ რამდენი ატრიბუტია უკვე წარმოდგენილი ცხრილში. მისი ნებართვები ყოველთვის არის მხოლოდ წაკითხვადი, ყოველგვარი ავთენტიფიკაციისა და ავტორიზაციის გარეშე. ამ ცნებებზე ცოტა მოგვიანებით ვისაუბრებთ. მნიშვნელობა არის კიდევ ერთი UUID, რომელიც განსაზღვრავს რა არის სერვისი. ცხრილში, მნიშვნელობა არის 0x180D, რომელიც განისაზღვრება Bluetooth SIG-ით, როგორც გულისცემის სერვისი.

სამსახურის გამოცხადების შემდეგ მოდის მახასიათებლის გამოცხადება. ის მსგავსია სერვისის დეკლარაციის სახით. მისი UUID ყოველთვის არის 0x2803 და მისი ნებართვები ყოველთვის არის მხოლოდ წაკითხვადი ყოველგვარი ავტორიზაციის ან ავტორიზაციის გარეშე. მოდით შევხედოთ Attribute Value ველს, რომელიც შეიცავს გარკვეულ მონაცემებს. ის ყოველთვის შეიცავს მაჩვენებელს, UUID-ს და თვისებების კომპლექტს. ეს სამი ელემენტი აღწერს დამახასიათებელი მნიშვნელობის შემდგომ გამოცხადებას. მაჩვენებელი ბუნებრივად აღნიშნავს დამახასიათებელი მნიშვნელობის გამოცხადების ადგილს ატრიბუტების ცხრილში. UUID აღწერს რა ტიპის ინფორმაციას ან მნიშვნელობას შეიძლება ველოდოთ. მაგალითად, ტემპერატურის მნიშვნელობა, შუქის ჩამრთველის მდგომარეობა ან სხვა თვითნებური მნიშვნელობა. და ბოლოს თვისებები, რომლებიც აღწერს, თუ როგორ შეიძლება ურთიერთქმედება დამახასიათებელ მნიშვნელობასთან.

აქ კიდევ ერთი ხიბლი გველოდება. ის ასოცირდება ატრიბუტების ნებართვებთან და დამახასიათებელ თვისებებთან. მოდით შევხედოთ ბიტის ველის თვისებების სურათს სპეციფიკაციიდან.

როგორც ხედავთ, აქ ასევე არის ველები, რომლებიც უზრუნველყოფენ წაკითხვისა და ჩაწერის შესაძლებლობებს. შეიძლება გაინტერესებთ, რატომ გვაქვს ატრიბუტისა და ქონების წაკითხვის/ჩაწერის ნებართვა
წაიკითხეთ/დაწერეთ დამახასიათებელი მნიშვნელობისთვის? ისინი ყოველთვის ერთნაირი არ უნდა იყვნენ? ფაქტია, რომ დამახასიათებელი მნიშვნელობის თვისებები რეალურად არის მხოლოდ რეკომენდაციები კლიენტისთვის, რომელიც გამოიყენება GATT-ში და აპლიკაციის ფენებში. ეს არის უბრალოდ მინიშნებები იმის შესახებ, თუ რას შეიძლება მოელოდეს კლიენტი დამახასიათებელი დეკლარაციის ატრიბუტიდან. მოდით შევხედოთ ამას უფრო დეტალურად. რა ტიპის ნებართვები აქვს ატრიბუტს?

1. წვდომის ნებართვები:
     - კითხვა
     - ჩანაწერი
     - წაიკითხე და დაწერე
2. ავთენტიფიკაციის ნებართვა:
     - საჭიროა ავთენტიფიკაცია
     - არ არის საჭირო ავთენტიფიკაცია
3. ავტორიზაციის ნებართვა:
     - საჭიროა ავტორიზაცია
     - არ არის საჭირო ავტორიზაცია

მთავარი განსხვავება ატრიბუტის გარჩევადობასა და დამახასიათებელ თვისებებს შორის არის ის, რომ პირველი ვრცელდება სერვერებზე, ხოლო მეორე - კლიენტებზე. სერვერს შეიძლება მიეცეს უფლება წაიკითხოს დამახასიათებელი მნიშვნელობა, მაგრამ შეიძლება მოითხოვოს ავთენტიფიკაცია ან ავტორიზაცია. ამიტომ, როდესაც კლიენტი ითხოვს მახასიათებლის თვისებებს, ჩვენ მივიღებთ, რომ წაკითხვა დაშვებულია. მაგრამ როდესაც ვცდილობთ წაკითხვას, ვიღებთ შეცდომას. აქედან გამომდინარე, ჩვენ შეგვიძლია უსაფრთხოდ ვისაუბროთ ნებართვების პრიორიტეტზე თვისებებზე. კლიენტის მხრიდან, ჩვენ ვერ მივიღებთ ცოდნას იმის შესახებ, თუ რა ნებართვები აქვს ატრიბუტს.

აღმწერი

დავუბრუნდეთ ჩვენს სუფრას. მახასიათებლის მნიშვნელობის გამოცხადების შემდეგ, შესაძლებელია შემდეგი ატრიბუტების დეკლარაციები:
1. მახასიათებლების ახალი დეკლარაცია (სერვისს შეიძლება ჰქონდეს მრავალი მახასიათებელი)
2. ახალი სერვისის დეკლარაცია (შეიძლება ბევრი მათგანი იყოს ცხრილში)
3. სახელურის გამოცხადება

გულისცემის საზომი მახასიათებლის შემთხვევაში, ჩვენს ცხრილში, დამახასიათებელი მნიშვნელობის დეკლარაციას ახლავს აღწერის დეკლარაცია. აღმწერი არის ატრიბუტი, რომელსაც აქვს დამატებითი ინფორმაცია მახასიათებლის შესახებ. აღწერის რამდენიმე სახეობა არსებობს. მათ შესახებ დეტალურად ვისაუბრებთ ამ სტატიის მეორე ნაწილში. ამ დროისთვის ჩვენ შევეხებით მხოლოდ კლიენტის მახასიათებლების კონფიგურაციის აღმწერს (CCCD). მას აქვს UUID ტოლი 0x2902. ამ დესკრიპტორის გამოყენებით კლიენტს აქვს შესაძლებლობა ჩართოს ჩვენება ან შეტყობინება სერვერზე. განსხვავება მათ შორის მცირეა, მაგრამ მაინც არსებობს. შეტყობინება არ საჭიროებს კლიენტისგან მიღების დადასტურებას. მითითება ამას მოითხოვს, თუმცა ეს ხდება GATT-ის დონეზე და არ აღწევს განაცხადის დონეს. რატომ ასე, გეკითხებით? ვაი, ეს არ ვიცი. ნება მომეცით უბრალოდ ვთქვა, რომ სკანდინავიური ექსპერტები გვირჩევენ შეტყობინებების გამოყენებას. უფრო მეტიც, პაკეტის მთლიანობის შემოწმება (CRC გამოყენებით) ხდება ორივე შემთხვევაში.

დასკვნა

სტატიის ბოლოს მინდა ვთქვა ეს. ბოლო ცხრილი ცოტა დამაბნეველია. თუმცა, მე ავირჩიე, რადგან ის არის მოცემული მუხლი, რომელსაც ვეყრდნობი. ჩემი სტატიის მეორე ნაწილში მე ვაპირებ უფრო ღრმად ჩავუღრმავდე BlueTooth 4.0 სპეციფიკაციას. იქ უფრო სწორი დიაგრამები და ნახატები გველოდება. მესამე ნაწილში მინდა გავაანალიზო Wireshark პროგრამის გამოყენებით მიღებული ჟურნალი ერთ-ერთი გაჯეტიდან და ვნახოთ „ცოცხალი“ მთელი თეორია, რომელსაც ჩვენ ვსწავლობთ.

კომპანიების ჯგუფის თანამშრომელი "ცეზარის სატელიტი"
პეჩერსკიხი ვლადიმერ

წყარო: www.habr.com