മൂന്ന് അടിസ്ഥാന ഘടകങ്ങൾ, ഒരേയൊരു ലക്ഷ്യം
Timmy അകത്ത് പ്രവർത്തിക്കുന്നത് വളരെ പ്രായോഗികമായ രീതിയിലാണ്: Flutter ആപ്പിനായി, WebRTC തത്സമയ ഓഡിയോയ്ക്കും വീഡിയോയ്ക്കുമായി, കൂടാതെ Firebase ഏകോപനത്തിനായി. എല്ലാം ക്ലൗഡിലൂടെ കടത്തിവിടുന്ന വലിയൊരു പ്ലാറ്റ്ഫോം ഉണ്ടാക്കാൻ ഞാൻ ആഗ്രഹിച്ചില്ല. ഓരോ ഭാഗവും കഴിയുന്നത്ര കുറച്ച് കാര്യങ്ങൾ മാത്രം അറിഞ്ഞാലും മറ്റുള്ളവയുമായി വിശ്വസനീയമായി പ്രവർത്തിക്കണം.
WebRTC: നേരിട്ടുള്ള കണക്ഷൻ, ഡിഫോൾട്ടായി എൻക്രിപ്റ്റ് ചെയ്തത്
WebRTC (Web Real-Time Communication) ബേബി ഉപകരണത്തിനും മാതാപിതാക്കളുടെ ഉപകരണത്തിനും ഇടയിൽ ഓഡിയോയും വീഡിയോയും കൈമാറുന്നു. ഏറ്റവും നല്ല സാഹചര്യത്തിൽ, ഡാറ്റ രണ്ട് ഉപകരണങ്ങൾക്കിടയിൽ നേരിട്ട് പിയർ-ടു-പിയർ ആയി ഒഴുകും; ഇടയിൽ മീഡിയ സെർവർ ഒന്നുമില്ല.
ഓരോ WebRTC കണക്ഷനും ഡിഫോൾട്ടായി DTLS-SRTP ഉപയോഗിക്കുന്നു. ആരെങ്കിലും നെറ്റ്വർക്ക് പാക്കറ്റുകൾ പിടിച്ചാലും വായിക്കാവുന്ന ഓഡിയോയോ വീഡിയോയോ ലഭിക്കില്ല. ഈ എൻക്രിപ്ഷൻ പ്രോട്ടോക്കോളിന്റെ ഭാഗമാണ്; WebRTC-യിൽ ഇത് വെറുതെ ഓഫ് ചെയ്യാനാവില്ല.
എനിക്ക് പ്രധാനമായിരുന്നത് ഇതാണ്: നഴ്സറിയിലെ മീഡിയ എന്റെ സെർവറിൽ ഉണ്ടാകരുത്. അത് നിങ്ങളുടെ ഉപകരണങ്ങൾക്കിടയിൽ തന്നെ തുടരും.
Firebase Firestore വഴിയുള്ള സിഗ്നലിംഗ്
WebRTC ആരംഭിക്കുന്നതിന് മുമ്പ്, ഉപകരണങ്ങൾ പരസ്പരം കണ്ടെത്തുകയും എങ്ങനെ കണക്റ്റ് ചെയ്യാമെന്ന് ധാരണയിലെത്തുകയും വേണം. ഈ ഘട്ടത്തെ സിഗ്നലിംഗ് എന്ന് വിളിക്കുന്നു. ഇതിനായി Timmy Google-ന്റെ ക്ലൗഡ് ഡാറ്റാബേസായ Firebase Firestore ഉപയോഗിക്കുന്നു.
സാങ്കേതിക കണക്ഷൻ ഡാറ്റ മാത്രമാണ് കൈമാറുന്നത്:
- SDP ഓഫറുകളും ഉത്തരങ്ങളും: ഉപകരണങ്ങളുടെ കഴിവുകൾ വിവരിക്കുന്നു (പിന്തുണയ്ക്കുന്ന കോഡെക്കുകൾ, റെസല്യൂഷനുകൾ മുതലായവ).
- ICE കാൻഡിഡേറ്റുകൾ: ഉപകരണങ്ങൾക്ക് പരസ്പരം എത്തിച്ചേരാൻ കഴിയുന്ന സാധ്യതയുള്ള നെറ്റ്വർക്ക് വഴികൾ.
ഓഡിയോയും വീഡിയോയും Firebase-ലേക്ക് എത്തുന്നില്ല. Firestore സാങ്കേതിക കണക്ഷൻ ഡാറ്റ മാത്രമാണ് കൈമാറുന്നത്. Timmy ഈ സിഗ്നലിംഗ് ലെയറും എൻക്രിപ്റ്റ് ചെയ്യുന്നു; അതിനാൽ SDP, ICE വിവരങ്ങൾക്കുള്ള പ്ലെയിൻടെക്സ്റ്റ് കൂടിക്കാഴ്ചയിടമായി Firestore മാറില്ല.
TURN സെർവറുകൾ: നേരിട്ടുള്ള വഴി പ്രവർത്തിക്കാത്തപ്പോൾ
കർശനമായ ഫയർവാളുകളോ ചില മൊബൈൽ സേവനദാതാക്കളുടെ നിയന്ത്രണങ്ങളോ കാരണം ചില നെറ്റ്വർക്കുകളിൽ നേരിട്ടുള്ള കണക്ഷനുകൾ തടയപ്പെടും. അപ്പോൾ WebRTC-യ്ക്ക് ഒരു TURN റിലേ (Traversal Using Relays around NAT) ആവശ്യമാണ്.
Timmy ആദ്യം ലോക്കൽ TURN സെർവർ പരീക്ഷിക്കും. ലോക്കൽ റിലേ ലഭ്യമല്ലെങ്കിലോ അമിതഭാരത്തിലാണെങ്കിലോ പകരമായി Cloudflare ഉപയോഗിക്കും. റിലേ എൻക്രിപ്റ്റ് ചെയ്ത പാക്കറ്റുകൾ കൈമാറുക മാത്രമാണ് ചെയ്യുന്നത്. ശബ്ദത്തിന്റെയോ വീഡിയോയുടെയോ കീകൾ അതിന് ലഭിക്കില്ല; WebRTC എൻക്രിപ്ഷൻ അതേപടി നിലനിൽക്കും.
TURN ക്രെഡൻഷ്യലുകൾ Firebase Cloud Function-ൽ നിന്നാണ് ലഭിക്കുന്നത്; അവ 24 മണിക്കൂർ മാത്രമേ സാധുവായിരിക്കൂ. ബേബി മോണിറ്റർ ആപ്പിൽ സ്ഥിരം ക്രെഡൻഷ്യലുകൾ വെക്കുന്നത് എനിക്ക് വളരെ അപകടസാധ്യതയുള്ള കാര്യമാണ്.
Nearby Connections: ഉപകരണങ്ങൾ പരസ്പരം സ്വയം കണ്ടെത്തുന്നു
ബേബി ഉപകരണവും മാതാപിതാക്കളുടെ ഉപകരണവും തമ്മിലുള്ള ബുദ്ധിമുട്ടുള്ള സെറ്റപ്പ് ഘട്ടങ്ങൾ ഒഴിവാക്കാൻ, Timmy ഉപയോഗിക്കുന്നത് Nearby Connections ആണ്. Bluetooth, WiFi എന്നിവയിലൂടെ Google ഈ കണ്ടെത്തൽ സംവിധാനം നൽകുന്നു.
Timmy-യിലെ സ്വയമേവയുള്ള പേയറിംഗ് കോഡ് നേരിട്ട് നൽകാതെ തന്നെ ഇത് പ്രവർത്തിക്കുന്നു: ഉപകരണങ്ങൾ പരസ്പരം കണ്ടെത്തുകയും കീ കൈമാറ്റത്തിനായി ഒരേ ബന്ധപ്പെടൽ കേന്ദ്രത്തിലെത്തുകയും ചെയ്യും. അത് പരാജയപ്പെട്ടാൽ, നിങ്ങൾക്ക് നൽകാവുന്ന 4 പ്രതീകങ്ങളുള്ള ഒരു കോഡുണ്ട്. പേയറിംഗ് കോഡ് ഒരിക്കലും ഉപകരണത്തിന് പുറത്തേക്ക് പോകുന്നില്ല; Firestore-ന് ഡോക്യുമെന്റ് ഐഡന്റിഫയറായി ക്രിപ്റ്റോഗ്രാഫിക് ഹാഷ് (SHA-256) മാത്രമേ കാണാനാകൂ.
അജ്ഞാത ഓതന്റിക്കേഷൻ
Timmy Firebase Anonymous Authentication ഉപയോഗിക്കുന്നു. ആദ്യമായി തുറക്കുമ്പോൾ ഓരോ ഉപകരണത്തിനും താൽക്കാലികവും അജ്ഞാതവുമായ ഒരു ഐഡി ലഭിക്കും. അക്കൗണ്ടോ ഇമെയിൽ വിലാസമോ പാസ്വേഡോ ഇല്ല. Firestore നിയമങ്ങൾ നടപ്പാക്കാൻ മാത്രമാണ് ഈ ഐഡി: ഓതന്റിക്കേറ്റ് ചെയ്ത ഉപകരണങ്ങൾക്കു മാത്രം സെഷൻ ഡാറ്റ വായിക്കാനോ എഴുതാനോ കഴിയും.
ആർക്കാണ് അയക്കുന്നത്, ആർക്കാണ് ലഭിക്കുന്നത്: ആർക്കിടെക്ചർ
Timmy-ക്ക് രണ്ട് മോഡുകളുണ്ട്:
- ബേബി മോഡ് (അയയ്ക്കുന്നത്): ഉപകരണം മൈക്രോഫോൺ വഴി ഓഡിയോ പകർത്തി WebRTC വഴി മാതാപിതാക്കളുടെ ഉപകരണത്തിലേക്ക് അയയ്ക്കുന്നു. വേണമെങ്കിൽ ക്യാമറ സജീവമാക്കാം; അപ്പോൾ വീഡിയോയും നേരിട്ട് അയക്കും.
- പാരന്റ് മോഡ് (സ്വീകരിക്കുന്നത്): ഉപകരണം ഓഡിയോയും വീഡിയോയും സ്വീകരിക്കും, ക്യാമറ സ്ട്രീം കാണിക്കും, ബേബി ഉപകരണത്തിലേക്ക് ചെറിയ വോയ്സ് സന്ദേശങ്ങൾ അയയ്ക്കാൻ പുഷ്-ടു-ടോക്ക് സൗകര്യവും നൽകും.
പുഷ്-ടു-ടോക്ക്, ക്യാമറ ഓൺ/ഓഫ് പോലുള്ള നിയന്ത്രണങ്ങൾ ഉപയോഗിക്കുന്നത് ഒരു DataChannel ആണ്; ഉപകരണങ്ങൾക്കിടയിൽ ചെറിയ എൻക്രിപ്റ്റ് ചെയ്ത സന്ദേശങ്ങൾ നേരിട്ട് അയയ്ക്കുന്ന മറ്റൊരു WebRTC ചാനൽ.
എന്തിന് Flutter?
ഒന്നിലധികം പ്ലാറ്റ്ഫോമുകൾക്കായുള്ള ആപ്പുകൾ നിർമ്മിക്കാൻ Google നൽകുന്ന ഫ്രെയിംവർക്കാണ് Flutter. Timmy-യുടെ കാര്യത്തിൽ, ലോജിക്കിന്റെ വലിയൊരു ഭാഗം ഒരിക്കൽ എഴുതിയാൽ Android-ലും iOS-ലും ഉപയോഗിക്കാം. Timmy Android-ൽ ലഭ്യമാണ്; iOS പതിപ്പ് പുറത്തിറങ്ങാൻ അടുത്തിരിക്കുകയാണ്. ഒരേ കോഡ് ആവർത്തിച്ച് എഴുതേണ്ടതില്ലാത്തതിനാൽ ബഗുകൾ കടന്നുകയറാവുന്ന ഇടങ്ങളും കുറയും.
ചുരുക്കം
സാങ്കേതിക നിയമം ലളിതമാണ്: Timmy-ക്ക് യഥാർത്ഥത്തിൽ ആവശ്യമായ ഡാറ്റ മാത്രമേ കൈകാര്യം ചെയ്യാവൂ. WebRTC മീഡിയയെ സംരക്ഷിക്കുന്നു, Firebase കണക്ഷൻ സജ്ജീകരണം ഏകോപിപ്പിക്കുന്നു, TURN-ന് എൻക്രിപ്റ്റ് ചെയ്ത പാക്കറ്റുകൾ മാത്രം കാണാം, Nearby Connections പേയറിംഗിലെ ബുദ്ധിമുട്ട് കുറയ്ക്കുന്നു.
നല്ല സാങ്കേതികവിദ്യ ദൈനംദിന ജീവിതത്തിന്റെ ഭാഗമായിക്കൊണ്ട് അല്പം അദൃശ്യമാകുന്നു. നഴ്സറിയെ ഒരു ക്ലൗഡ് പ്രോജക്റ്റാക്കാതെ അത് പ്രവർത്തിക്കുന്നു.