ສາມອົງປະກອບ, ໜຶ່ງເປົ້າໝາຍ
ເບື້ອງຫຼັງ Timmy ຖືກສ້າງຂຶ້ນແບບເນັ້ນໃຊ້ງານຈິງ: Flutter ສຳລັບແອັບ, WebRTC ສຳລັບສຽງ ແລະ ວິດີໂອແບບເວລາຈິງ, ແລະ Firebase ສຳລັບການປະສານງານ. ຂ້ອຍບໍ່ຢາກສ້າງແພລດຟອມໃຫຍ່ທີ່ສົ່ງທຸກຢ່າງຜ່ານຄລາວ. ແຕ່ລະສ່ວນຄວນຮູ້ຂໍ້ມູນເທົ່າທີ່ຈຳເປັນ ແລະຍັງເຮັດວຽກຮ່ວມກັນໄດ້ຢ່າງໜ້າເຊື່ອຖື.
WebRTC: ເຊື່ອມຕໍ່ໂດຍກົງ, ເຂົ້າລະຫັດເປັນຄ່າພື້ນຖານ
WebRTC (Web Real-Time Communication) ສົ່ງສຽງ ແລະ ວິດີໂອລະຫວ່າງອຸປະກອນຂອງລູກ ແລະ ຂອງພໍ່ແມ່. ໃນກໍລະນີທີ່ດີທີ່ສຸດ ຂໍ້ມູນຈະໄຫຼ ໂດຍກົງລະຫວ່າງສອງອຸປະກອນ, ແບບ peer-to-peer, ໂດຍບໍ່ມີເຊີບເວີສື່ຄັ່ນກາງ.
ທຸກການເຊື່ອມຕໍ່ WebRTC ໃຊ້ DTLS-SRTP ເປັນຄ່າພື້ນຖານ. ຖ້າມີໃຜດັກຈັບແພັກເກັດໃນເຄືອຂ່າຍ ພວກເຂົາກໍຈະບໍ່ສາມາດຟັງສຽງ ຫຼືເບິ່ງວິດີໂອໄດ້. ການເຂົ້າລະຫັດນີ້ເປັນສ່ວນໜຶ່ງຂອງໂປຣໂຕຄອນ ແລະບໍ່ສາມາດປິດໄດ້ໃນ WebRTC.
ນີ້ແມ່ນຈຸດສຳຄັນສຳລັບຂ້ອຍ: ສື່ຈາກຫ້ອງລູກບໍ່ຄວນຢູ່ໃນເຊີບເວີຂອງຂ້ອຍ. ມັນຢູ່ລະຫວ່າງອຸປະກອນຂອງທ່ານເທົ່ານັ້ນ.
ການສົ່ງສັນຍານຜ່ານ Firebase Firestore
ກ່ອນທີ່ WebRTC ຈະເລີ່ມໄດ້ ອຸປະກອນຕ້ອງຫາກັນໃຫ້ເຫັນ ແລະຕົກລົງວິທີເຊື່ອມຕໍ່. ສ່ວນນີ້ເອີ້ນວ່າ ການສົ່ງສັນຍານ. Timmy ໃຊ້ Firebase Firestore, ຖານຂໍ້ມູນຄລາວຂອງ Google, ສຳລັບສ່ວນນີ້.
ມີການແລກປ່ຽນພຽງຂໍ້ມູນເຕັກນິກສຳລັບການເຊື່ອມຕໍ່:
- ຄຳສະເໜີ ແລະຄຳຕອບ SDP: ອະທິບາຍຄວາມສາມາດຂອງອຸປະກອນ (ຕົວເຂົ້າແລະຖອດລະຫັດສື່ທີ່ຮອງຮັບ, ຄວາມລະອຽດ ແລະອື່ນໆ).
- ຕົວເລືອກ ICE: ເສັ້ນທາງເຄືອຂ່າຍທີ່ເປັນໄປໄດ້ ທີ່ອຸປະກອນສາມາດໃຊ້ເພື່ອເຂົ້າຫາກັນ.
ສຽງ ແລະ ວິດີໂອບໍ່ໄດ້ໄປຢູ່ໃນ Firebase. Firestore ຂົນສົ່ງພຽງຂໍ້ມູນເຕັກນິກສຳລັບການເຊື່ອມຕໍ່. Timmy ຍັງເຂົ້າລະຫັດຊັ້ນການສົ່ງສັນຍານນີ້ ດັ່ງນັ້ນ Firestore ຈຶ່ງບໍ່ເປັນຈຸດລວມຂໍ້ຄວາມແບບບໍ່ເຂົ້າລະຫັດສຳລັບ SDP ແລະ ICE.
ເຊີບເວີ TURN: ເມື່ອເສັ້ນທາງໂດຍກົງໃຊ້ບໍ່ໄດ້
ບາງເຄືອຂ່າຍບລັອກການເຊື່ອມຕໍ່ໂດຍກົງ ເຊັ່ນ firewall ທີ່ເຂັ້ມງວດ ຫຼື ຜູ້ໃຫ້ບໍລິການມືຖືບາງລາຍ. ໃນເວລານັ້ນ WebRTC ຕ້ອງການ TURN relay (Traversal Using Relays around NAT).
Timmy ຈະລອງໃຊ້ເຊີບເວີ TURN ຂອງຕົນເອງກ່ອນ ແລະໃຊ້ Cloudflare ເປັນລະບົບສຳຮອງ ເມື່ອເຊີບເວີຖ່າຍທອດດັ່ງກ່າວໃຊ້ບໍ່ໄດ້ ຫຼືຮັບພາລະໜັກເກີນໄປ. ເຊີບເວີຖ່າຍທອດພຽງແຕ່ສົ່ງຕໍ່ແພັກເກັດທີ່ເຂົ້າລະຫັດແລ້ວ. ມັນບໍ່ໄດ້ຮັບກະແຈສຳລັບຖອດລະຫັດສຽງ ຫຼືວິດີໂອ; ການເຂົ້າລະຫັດຂອງ WebRTC ຍັງຄົງຢູ່.
ຂໍ້ມູນຮັບຮອງ TURN ມາຈາກ Firebase Cloud Function ແລະໃຊ້ໄດ້ພຽງ 24 ຊົ່ວໂມງ. ສຳລັບຂ້ອຍ ການມີຂໍ້ມູນຮັບຮອງຖາວອນໃນແອັບເບິ່ງແຍງລູກແມ່ນສ່ຽງເກີນໄປ.
Nearby Connections: ອຸປະກອນຫາກັນເຈີອັດຕະໂນມັດ
ເພື່ອບໍ່ໃຫ້ການຕັ້ງຄ່າລະຫວ່າງອຸປະກອນຂອງລູກ ແລະ ຂອງພໍ່ແມ່ຍຸ່ງຍາກ, Timmy ໃຊ້ Nearby Connections. Google ໃຫ້ຊັ້ນການຄົ້ນພົບນີ້ຜ່ານ Bluetooth ແລະ WiFi.
ການຈັບຄູ່ອັດຕະໂນມັດໃນ Timmy ໃຊ້ໄດ້ໂດຍບໍ່ຕ້ອງພິມລະຫັດດ້ວຍມື: ອຸປະກອນຈະຄົ້ນພົບກັນ ແລະຊອກຫາຈຸດດຽວກັນສຳລັບແລກປ່ຽນກະແຈ. ຖ້າເຮັດບໍ່ສຳເລັດ ມີລະຫັດ 4 ຕົວອັກສອນໃຫ້ທ່ານພິມ. ລະຫັດຈັບຄູ່ບໍ່ເຄີຍອອກຈາກອຸປະກອນ; Firestore ເຫັນພຽງຄ່າແຮັຊທາງການເຂົ້າລະຫັດ (SHA-256) ທີ່ໃຊ້ເປັນຕົວລະບຸເອກະສານ.
ການຢືນຢັນຕົວຕົນແບບບໍ່ລະບຸຊື່
Timmy ໃຊ້ Firebase Anonymous Authentication. ເມື່ອເປີດໃຊ້ຄັ້ງທຳອິດ ແຕ່ລະອຸປະກອນຈະໄດ້ຮັບ ID ຊົ່ວຄາວແບບບໍ່ລະບຸຊື່. ບໍ່ມີບັນຊີ, ບໍ່ມີອີເມວ ແລະ ບໍ່ມີລະຫັດຜ່ານ. ID ນີ້ມີໄວ້ເພື່ອບັງຄັບໃຊ້ກົດ Firestore ເທົ່ານັ້ນ: ມີພຽງອຸປະກອນທີ່ຢືນຢັນຕົວຕົນແລ້ວ ຈຶ່ງອ່ານ ຫຼື ຂຽນຂໍ້ມູນ session ໄດ້.
ໂຄງສ້າງລະບົບ: ໃຜສົ່ງ, ໃຜຮັບ
Timmy ມີສອງໂໝດ:
- ໂໝດລູກນ້ອຍ (ຜູ້ສົ່ງ): ອຸປະກອນຈັບສຽງຜ່ານໄມໂຄຣໂຟນ ແລະສົ່ງໄປຫາອຸປະກອນຂອງພໍ່ແມ່ຜ່ານ WebRTC. ສາມາດເປີດກ້ອງໄດ້ຕາມເລືອກ; ວິດີໂອຈະຖືກສົ່ງໂດຍກົງເຊັ່ນກັນ.
- ໂໝດພໍ່ແມ່ (ຜູ້ຮັບ): ອຸປະກອນຮັບສຽງ ແລະ ວິດີໂອ, ສະແດງພາບຈາກກ້ອງ ແລະມີ push-to-talk ສຳລັບສົ່ງຂໍ້ຄວາມສຽງສັ້ນໆໄປຫາອຸປະກອນຂອງລູກ.
ການຄວບຄຸມເຊັ່ນ push-to-talk ແລະ ການເປີດ/ປິດກ້ອງ ໃຊ້ DataChannel, ເປັນຊ່ອງ WebRTC ອີກຊ່ອງໜຶ່ງທີ່ສົ່ງຂໍ້ຄວາມນ້ອຍໆທີ່ເຂົ້າລະຫັດໂດຍກົງລະຫວ່າງອຸປະກອນ.
ເປັນຫຍັງຈຶ່ງໃຊ້ Flutter?
Flutter ແມ່ນຊຸດເຄື່ອງມືຂອງ Google ສຳລັບສ້າງແອັບໃນຫຼາຍແພລດຟອມ. ສຳລັບ Timmy, ນັ້ນໝາຍຄວາມວ່າຂ້ອຍສາມາດຂຽນໂລຈິກສ່ວນໃຫຍ່ພຽງຄັ້ງດຽວ ແລ້ວນຳໄປໃຊ້ໄດ້ທັງໃນ Android ແລະ iOS. Timmy ມີໃຫ້ໃຊ້ໃນ Android ແລ້ວ ແລະເວີຊັນ iOS ກໍໃກ້ຈະເປີດໃຫ້ໃຊ້. ເມື່ອມີລະຫັດໂປຣແກຣມທີ່ຊ້ຳກັນໜ້ອຍລົງ ຈຸດທີ່ຂໍ້ຜິດພາດອາດເກີດຂຶ້ນກໍໜ້ອຍລົງເຊັ່ນກັນ.
ສະຫຼຸບ
ຫຼັກການດ້ານເຕັກນິກແມ່ນງ່າຍໆ: Timmy ຄວນແຕະຕ້ອງສະເພາະຂໍ້ມູນທີ່ຈຳເປັນແທ້ໆ. WebRTC ປົກປ້ອງສື່, Firebase ປະສານການຕັ້ງຄ່າເຊື່ອມຕໍ່, TURN ເຫັນພຽງແພັກເກັດທີ່ເຂົ້າລະຫັດ, ແລະ Nearby Connections ເຮັດໃຫ້ການຈັບຄູ່ງ່າຍຂຶ້ນ.
ເຕັກໂນໂລຊີທີ່ດີຈະກົມກືນເຂົ້າກັບຊີວິດປະຈຳວັນ. ມັນເຮັດວຽກໄດ້ ໂດຍບໍ່ປ່ຽນຫ້ອງລູກໃຫ້ກາຍເປັນໂຄງການຄລາວ.