ប្លុក

របៀបដែល Baby Monitor Timmy ដំណើរការតាមបច្ចេកទេស

ពន្យល់អំពី WebRTC, Firebase និងការការពារពីចុងដល់ចុង ដោយគ្មានពាក្យបច្ចេកទេសស្មុគស្មាញ។

សមាសភាគបី គោលដៅមួយ

នៅខាងក្នុង Timmy ត្រូវបានបង្កើតឡើងយ៉ាងសាមញ្ញ និងជាក់ស្តែង៖ Flutter សម្រាប់កម្មវិធី, WebRTC សម្រាប់សំឡេង និងវីដេអូពេលជាក់ស្តែង, និង Firebase សម្រាប់ការសម្របសម្រួល។ ខ្ញុំមិនចង់បង្កើតវេទិកាធំមួយដែលបញ្ជូនអ្វីៗទាំងអស់តាម cloud ទេ។ ផ្នែកនីមួយៗគួរដឹងតិចបំផុតតាមដែលអាចធ្វើបាន ប៉ុន្តែនៅតែដំណើរការជឿជាក់ជាមួយផ្នែកផ្សេងៗ។

WebRTC៖ ការតភ្ជាប់ដោយផ្ទាល់ និងអ៊ិនគ្រីបជាស្រេច

WebRTC (Web Real-Time Communication) បញ្ជូនសំឡេង និងវីដេអូរវាងឧបករណ៍នៅក្បែរកូន និងឧបករណ៍របស់ឪពុកម្តាយ។ ក្នុងករណីល្អបំផុត ទិន្នន័យហូរ ដោយផ្ទាល់រវាងឧបករណ៍ទាំងពីរ, តាមរបៀប peer-to-peer ដោយគ្មានម៉ាស៊ីនមេផ្ទុកមេឌៀនៅកណ្ដាល។

រាល់ការតភ្ជាប់ WebRTC ប្រើ DTLS-SRTP ជាលំនាំដើម។ បើមាននរណាម្នាក់ចាប់យកកញ្ចប់ទិន្នន័យបណ្ដាញ ពួកគេមិនអាចអានសំឡេង ឬវីដេអូបានទេ។ ការអ៊ិនគ្រីបនេះជាផ្នែកមួយនៃពិធីការ ហើយមិនអាចបិទចោលក្នុង WebRTC បានងាយៗទេ។

នេះជាចំណុចសំខាន់សម្រាប់ខ្ញុំ៖ សំឡេង និងវីដេអូពីបន្ទប់កូនមិនគួរនៅលើម៉ាស៊ីនមេរបស់ខ្ញុំទេ។ វាស្ថិតនៅតែរវាងឧបករណ៍របស់អ្នក។

ការផ្តល់សញ្ញាតាម Firebase Firestore

មុនពេល WebRTC អាចចាប់ផ្តើម ឧបករណ៍ត្រូវស្វែងរកគ្នា និងចរចាអំពីរបៀបដែលពួកវាអាចតភ្ជាប់បាន។ ផ្នែកនេះហៅថា signaling. Timmy ប្រើ Firebase Firestore ដែលជាមូលដ្ឋានទិន្នន័យ cloud របស់ Google សម្រាប់ការងារនេះ។

មានតែទិន្នន័យបច្ចេកទេសសម្រាប់ការតភ្ជាប់ប៉ុណ្ណោះដែលត្រូវបានផ្លាស់ប្តូរ៖

សំឡេង និងវីដេអូមិនត្រូវបានផ្ទុកក្នុង Firebase ទេ។ Firestore គ្រាន់តែបញ្ជូនទិន្នន័យបច្ចេកទេសសម្រាប់ការតភ្ជាប់ប៉ុណ្ណោះ។ Timmy ក៏អ៊ិនគ្រីបស្រទាប់ signaling នេះដែរ ដូច្នេះ Firestore មិនក្លាយជាកន្លែងដែល SDP និង ICE បង្ហាញជាអក្សរធម្មតាទេ។

ម៉ាស៊ីនមេ TURN៖ នៅពេលផ្លូវតភ្ជាប់ដោយផ្ទាល់មិនដំណើរការ

បណ្ដាញខ្លះរារាំងការតភ្ជាប់ដោយផ្ទាល់ ដូចជា firewall តឹងរ៉ឹង ឬក្រុមហ៊ុនបណ្ដាញទូរស័ព្ទមួយចំនួន។ ពេលនោះ WebRTC ត្រូវការ TURN relay (Traversal Using Relays around NAT)។

Timmy សាកល្បងប្រើម៉ាស៊ីនមេ TURN ក្នុងតំបន់ជាមុន ហើយប្រើ Cloudflare ជាជម្រើសបម្រុង នៅពេល relay ក្នុងតំបន់មិនអាចប្រើបាន ឬផ្ទុកលើសកម្រិត។ relay បញ្ជូនបន្តកញ្ចប់ទិន្នន័យដែលបានអ៊ិនគ្រីប។ វាមិនទទួលបានសោសម្រាប់សំឡេង ឬវីដេអូទេ ហើយការអ៊ិនគ្រីប WebRTC នៅតែដដែល។

ព័ត៌មានសម្ងាត់ TURN មកពី Firebase Cloud Function ហើយមានសុពលភាពត្រឹម 24 ម៉ោងប៉ុណ្ណោះ។ សម្រាប់ខ្ញុំ ការមានព័ត៌មានសម្ងាត់អចិន្ត្រៃយ៍ក្នុងកម្មវិធីម៉ូនីទ័រកូនគឺប្រថុយពេក។

Nearby Connections៖ ឧបករណ៍ស្វែងរកគ្នាដោយស្វ័យប្រវត្តិ

ដើម្បីជៀសវាងជំហានដំឡើងដែលពិបាករវាងឧបករណ៍នៅក្បែរកូន និងឧបករណ៍របស់ឪពុកម្តាយ Timmy ប្រើ Nearby Connections. Google ផ្តល់ស្រទាប់ស្វែងរកនេះតាម Bluetooth និង WiFi។

ការផ្គូផ្គងដោយស្វ័យប្រវត្តិក្នុង Timmy ដំណើរការដោយមិនចាំបាច់បញ្ចូលកូដដោយដៃ៖ ឧបករណ៍ស្វែងរកគ្នា ហើយរកឃើញចំណុចជួបគ្នាដូចគ្នាសម្រាប់ការផ្លាស់ប្តូរសោ។ បើវាមិនជោគជ័យ អ្នកអាចវាយបញ្ចូលកូដ 4 តួអក្សរ។ កូដផ្គូផ្គងមិនដែលចាកចេញពីឧបករណ៍ទេ; Firestore មើលឃើញតែ cryptographic hash (SHA-256) ជាអត្តសញ្ញាណឯកសារប៉ុណ្ណោះ។

ការផ្ទៀងផ្ទាត់អត្តសញ្ញាណអនាមិក

Timmy ប្រើ Firebase Anonymous Authentication។ នៅពេលបើកប្រើលើកដំបូង ឧបករណ៍នីមួយៗទទួលបាន ID បណ្តោះអាសន្ន និងអនាមិក។ មិនមានគណនី អ៊ីមែល ឬពាក្យសម្ងាត់ទេ។ ID នេះមានតួនាទីតែដើម្បីអនុវត្តច្បាប់ Firestore ប៉ុណ្ណោះ៖ មានតែឧបករណ៍ដែលបានផ្ទៀងផ្ទាត់អត្តសញ្ញាណប៉ុណ្ណោះដែលអាចអាន ឬសរសេរទិន្នន័យ session បាន។

ស្ថាបត្យកម្ម៖ អ្នកណាបញ្ជូន អ្នកណាទទួល

Timmy មានរបៀបប្រើពីរ៖

ការបញ្ជាដូចជា push-to-talk និងបើក/បិទកាមេរ៉ា ប្រើ DataChannel, ជាឆានែល WebRTC មួយទៀតដែលផ្ញើសារខ្លីៗដែលបានអ៊ិនគ្រីបដោយផ្ទាល់រវាងឧបករណ៍។

ហេតុអ្វី Flutter?

Flutter គឺជាក្របខ័ណ្ឌរបស់ Google សម្រាប់កម្មវិធីលើវេទិកាច្រើន។ សម្រាប់ Timmy វាមានន័យថា ខ្ញុំអាចសរសេរតក្កវិជ្ជាជាច្រើនតែម្តង ហើយប្រើវាបានទាំង Android និង iOS។ Timmy មាននៅលើ Android ហើយកំណែ iOS ជិតចេញផ្សាយហើយ។ កូដស្ទួនតិចជាងមុន មានន័យថាកន្លែងដែលកំហុសអាចលាក់ខ្លួនក៏តិចជាងមុនដែរ។

សរុប

គោលការណ៍បច្ចេកទេសគឺសាមញ្ញ៖ Timmy គួរប៉ះពាល់តែទិន្នន័យដែលវាពិតជាត្រូវការប៉ុណ្ណោះ។ WebRTC ការពារមេឌៀ, Firebase សម្របសម្រួលការរៀបចំការតភ្ជាប់, TURN ឃើញតែកញ្ចប់ទិន្នន័យដែលបានអ៊ិនគ្រីប ហើយ Nearby Connections ធ្វើឱ្យការផ្គូផ្គងកាន់តែងាយស្រួល។

បច្ចេកវិទ្យាល្អគឺរលាយចូលក្នុងជីវិតប្រចាំថ្ងៃបន្តិច។ វាដំណើរការ ដោយមិនធ្វើឱ្យបន្ទប់កូនក្លាយជាគម្រោង cloud ទេ។


អត្ថបទបន្ថែម