OpenAI எவ்வாறு குறைந்த தாமதம் கொண்ட குரல் AI-ஐ மிகப்பெரிய அளவில் வழங்குகிறது

உரையாடல் பேச்சின் வேகத்தில் நகர்ந்தால்தான் குரல் AI இயல்பாக உணரப்படும். நெட்வொர்க் குறுக்கிடும்போது, அது இயல்பற்ற இடைநிறுத்தங்கள், துண்டிக்கப்பட்ட குறுக்கீடுகள் அல்லது தாமதமான இடைமறித்தல்களாக மக்களுக்கு உடனடியாகக் கேட்கும். இது ChatGPT குரலுக்கும், Realtime API மூலம் உருவாக்கும் டெவலப்பர்களுக்கும், இடையாடும் பணிப்பாய்வுகளில் செயல்படும் முகவர்களுக்கும், பயனர் இன்னும் பேசிக்கொண்டிருக்கும்போதே ஆடியோவை செயலாக்க வேண்டிய மாதிரிகளுக்கும் முக்கியமானது.

OpenAI-இன் அளவில், அது மூன்று உறுதியான தேவைகளாக மாறுகிறது:

• 900 மில்லியனுக்கும் அதிகமான வாராந்திர செயலில் உள்ள பயனர்களை சென்றடையும் உலகளாவிய அணுகல்.
• அமர்வு தொடங்கியவுடன் பயனர் பேசத் தொடங்குவதற்கான விரைவான இணைப்பு அமைப்பு.
• குறைந்த மற்றும் நிலையான மீடியா சுற்றுப்பயண நேரம், குறைந்த ஜிட்டர் மற்றும் பாக்கெட் இழப்புடன், உரையாடல் மாறிமாறி நடைபெறுவது துல்லியமாகவும் சீராகவும் உணரப்படும்.

நேரடி AI தொடர்புகளுக்குப் பொறுப்பான OpenAI குழு சமீபத்தில் எங்கள் WebRTC ஸ்டாக்கை மறுகட்டமைத்தது. இதன் மூலம் பெரிய அளவில் செயல்படும் போது மோதிய மூன்று முக்கிய கட்டுப்பாடுகளைத் தீர்க்கப்பட்டது: ஒரு அமர்வுக்கு ஒரு போர்ட் என்ற மீடியா டெர்மினேஷன் OpenAI உள்கட்டமைப்புக்கு பொருந்தாது, ஸ்டேட்ஃபுல் ICE (Interactive Connectivity Establishment) மற்றும் DTLS (Datagram Transport Layer Security) அமர்வுகளுக்கு நிலையான உரிமையாளர் தேவை, மேலும் உலகளாவிய ரௌட்டிங் முதல்-ஹாப் லேட்டன்சியை குறைவாக வைத்திருக்க வேண்டும். இந்த பதிவில், OpenAI உள்கட்டமைப்புக்குள் பாக்கெட்டுகள் வழிமாற்றப்படும் முறையை மாற்றியபோதும், கிளையண்டுகளுக்கான நிலையான WebRTC நடத்தையைப் பாதுகாக்க நாங்கள் உருவாக்கிய பிரிக்கப்பட்ட ரிலே பிளஸ் டிரான்ஸீவர் கட்டமைப்பைப் பற்றி விவரமாகப் பார்ப்போம்.

WebRTC என்பது உலாவிகள், மொபைல் செயலிகள் மற்றும் சர்வர்களுக்கு இடையே குறைந்த தாமதத்துடன் ஆடியோ, வீடியோ மற்றும் தரவை அனுப்புவதற்கான திறந்த தரநிலையாகும். இது பெரும்பாலும் peer-to-peer அழைப்புகளுடன் தொடர்புபடுத்தப்படுகிறது, ஆனால் client-to-server நேரடி அமைப்புகளுக்கும் இது ஒரு நடைமுறை அடித்தளமாகும், ஏனெனில் இது தொடர்பாடும் ஊடகத்தின் கடினமான பகுதிகளைத் தரநிலைப்படுத்துகிறது: இணைப்பு ஏற்படுத்தல் மற்றும் NAT (Network Address Translation) வழியாகச் செல்லுதலுக்கான ICE, குறியாக்கப்பட்ட போக்குவரத்திற்கான DTLS மற்றும் SRTP (Secure Real-time Transport Protocol), ஆடியோவைச் சுருக்கி டிகோடு செய்வதற்கான codec ஒப்புரவு, தரக் கட்டுப்பாட்டிற்கான RTCP (Real-time Transport Control Protocol), மேலும் எதிரொலி ரத்துசெய்தல் மற்றும் jitter இடையகப்படுத்தல் போன்ற client-பக்க அம்சங்கள்.

அந்தத் தரநிலைப்படுத்தல் AI தயாரிப்புகளுக்கு முக்கியத்துவம் வாய்ந்தது. WebRTC இல்லாமல், ஒவ்வொரு கிளையன்டுக்கும் NAT-களைத் தாண்டி இணைப்பை நிறுவுவது, மீடியாவை குறியாக்குவது, கோடெக்குகளை பேச்சுவார்த்தை மூலம் தீர்மானிப்பது மற்றும் மாறும் நெட்வொர்க் நிலைமைகளுக்கு ஏற்ப மாற்றியமைப்பது ஆகியவற்றுக்கு வெவ்வேறு தீர்வு தேவைப்படும். WebRTC மூலம், உலாவிகள் மற்றும் மொபைல் தளங்களில் ஏற்கனவே செயல்படுத்தப்பட்டுள்ள நெறிமுறை அடுக்கை அடிப்படையாகக் கொண்டு, நிகழ்நேர ஊடகத்தை மாடல்களுடன் இணைக்கும் உள்கட்டமைப்பில் எங்கள் பணியை நாங்கள் கவனமாகச் செலுத்த முடியும்.

முதிர்ச்சியடைந்த திறந்த மூல அமலாக்கங்களும், உலாவிகள், மொபைல் ஆப்கள் மற்றும் சர்வர்கள் ஒன்றுடன் ஒன்று இயங்கக்கூடியவையாக இருக்கச் செய்யும் தரநிலைப்படுத்தல் பணிகளும் உட்பட, WebRTC சூழலமைப்பையே அடிப்படையாகக் கொண்டும் நாங்கள் கட்டமைக்கிறோம். WebRTC-இன் அசல் ஆர்கிடெக்ட்களில் ஒருவரான Justin Uberti மற்றும் Pion-ஐ உருவாக்கி பராமரித்து வரும் Sean DuBois ஆகியோரின் அடித்தளப் பணியே, எங்களைப் போன்ற குழுக்கள் குறைந்த-நிலை பரிமாற்றம், குறியாக்கம் மற்றும் நெரிசல்-கட்டுப்பாட்டு நடத்தையை மறுஉருவாக்குவதற்குப் பதிலாக, நடைமுறையில் சோதித்து நிரூபிக்கப்பட்ட மீடியா உள்கட்டமைப்பின் மேல் உருவாக்குவதை சாத்தியமாக்கியது. Justin மற்றும் Sean இருவரும் இப்போது இங்கே OpenAI-இல் எங்கள் சக பணியாளர்களாக இருந்து, WebRTC-யையும் நிகழ்நேர AI-யையும் இன்னும் நெருக்கமாக ஒன்றிணைக்கும் முறையை வழிநடத்த உதவுவது எங்களுக்கு அதிர்ஷ்டம்.

AI-க்கு, மிக முக்கியமான பண்பு என்னவெனில், ஆடியோ தொடர்ச்சியான ஸ்ட்ரீமாக வந்து சேர்வதாகும். ஒரு பேசும் ஏஜென்ட், முழு பதிவேற்றத்திற்காக காத்திருக்காமல், பயனர் இன்னும் பேசிக்கொண்டிருக்கும்போதே உரையாக்கம், ரீஸனிங், கருவிகளை அழைப்பது அல்லது பேச்சை உருவாக்குவது ஆகியவற்றைத் தொடங்கலாம். அதுதான், உரையாடலாக உணரப்படும் ஒரு அமைப்புக்கும் push-to-talk போல உணரப்படும் ஒன்றுக்கும் உள்ள வேறுபாடு.

நாங்கள் WebRTC-ஐத் தேர்ந்தெடுத்த பிறகு, அடுத்த கேள்வி அதை எங்கு டெர்மினேட் செய்வது (அதாவது, WebRTC இணைப்பை நாங்கள் எங்கு ஏற்றுக்கொண்டு அதன் பொறுப்பை ஏற்க வேண்டும்—உதாரணமாக, எட்ஜில்) மற்றும் அந்த அமர்வுகளை இன்ஃபரன்ஸ் பேக்கெண்டுடன் எவ்வாறு இணைப்பது என்பதாக இருந்தது. முடிவுறுத்தல் முக்கியமானது, ஏனெனில் நிகழ்நேர அமர்வு நிலை, ஊடகப் பரிமாற்றம், வழித்தடமிடல், தாமதம் மற்றும் தோல்வி தனிமைப்படுத்தல் ஆகியவற்றை நாங்கள் எவ்வாறு கையாள்கிறோம் என்பதை அது தீர்மானிக்கிறது.

SFU, அல்லது selective forwarding unit, என்பது ஒவ்வொரு பங்கேற்பாளரிடமிருந்தும் ஒரு WebRTC ஸ்ட்ரீமைப் பெற்று, அந்த ஸ்ட்ரீம்களை மற்றவர்களுக்கு தேர்ந்தெடுத்து அனுப்பும் ஒரு மீடியா சர்வர் ஆகும். இந்த மாடலில், ஒவ்வொரு பங்கேற்பாளருக்கும் தனித்தனி WebRTC இணைப்பை SFU முடிவுறுத்துகிறது, மேலும் AI அமர்வில் மற்றொரு பங்கேற்பாளராக இணைகிறது. குழு அழைப்புகள், வகுப்பறைகள் அல்லது ஒத்துழைப்பான கூட்டங்கள் போன்ற, இயல்பாகவே பல தரப்பினரை உள்ளடக்கிய தயாரிப்புகளுக்கு அது ஒரு நல்ல பொருத்தமாக இருக்கலாம். இது audio codecs, RTCP செய்திகள், data channels, பதிவு மற்றும் ஒவ்வொரு ஸ்ட்ரீமுக்கான கொள்கையை ஒரே இடத்தில் வைத்திருக்கிறது.¹

client-to-AI தயாரிப்புகளில்கூட, SFU பெரும்பாலும் இயல்புநிலை தொடக்கப் புள்ளியாக இருக்கும், ஏனெனில் signaling, மீடியா ரூட்டிங், பதிவு செய்தல், observability, மேலும் மனிதரிடம் ஒப்படைப்பு அல்லது கூடுதல் பங்கேற்பாளர்களைச் சேர்த்தல் போன்ற எதிர்கால விரிவாக்கங்களுக்கு, ஏற்கனவே நிரூபிக்கப்பட்ட ஒரே அமைப்பை குழுக்கள் மீண்டும் பயன்படுத்த இது உதவுகிறது.

எங்கள் பணிச்சுமை மாறுபட்டது. பெரும்பாலான அமர்வுகள் 1:1 வடிவிலானவை—ஒரு பயனர் ஒரு மாடலுடன் பேசுவது, அல்லது ஒரு பயன்பாடு ஒரு நிகழ்நேர ஏஜென்டுடன் பேசுவது—ஒவ்வொரு திருப்பத்திலும் தாமத உணர்திறன் கொண்டவை. அந்த வகையான டிராஃபிக் வடிவத்திற்காக, நாங்கள் ஒரு transceiver மாடலைத் தேர்ந்தெடுத்தோம்: WebRTC edge service கிளையன்ட் இணைப்பை முடிவுறச் செய்து, பின்னர் மீடியா மற்றும் நிகழ்வுகளை மாடல் inference, transcription, speech generation, tool use, மற்றும் orchestration ஆகியவற்றுக்கான எளிய உள் நெறிமுறைகளாக மாற்றுகிறது.

இந்த வடிவமைப்பில், ICE connectivity checks, DTLS handshake, SRTP encryption keys மற்றும் session lifecycle உட்பட WebRTC session state-ஐ நிர்வகிக்கும் ஒரே சேவை டிரான்ஸீவர் ஆகும். இங்கே “Termination” என்பது, அந்த handshakes-ஐ நிறைவு செய்து மீடியாவை encrypt அல்லது decrypt செய்யும் எண்ட்பாயிண்ட் டிரான்ஸீவர் என்பதைக் குறிக்கிறது. அந்த state-ஐ ஒரே இடத்தில் வைத்ததால், session ownership பற்றி புரிந்துகொண்டு விளக்குவது எளிதானது; மேலும் backend services தாமே WebRTC peers ஆக செயல்படுவதற்குப் பதிலாக, சாதாரண services போல scale ஆக அது அனுமதித்தது.

டிரான்ஸ்சீவர் மாடலைத் தேர்ந்தெடுத்த பிறகு, எங்களின் முதல் செயலாக்கம் Pion-ஐ அடிப்படையாகக் கொண்டு உருவாக்கப்பட்ட, சிக்னலிங் மற்றும் மீடியா டெர்மினேஷனை கையாளும் ஒற்றை Go சேவையாக இருந்தது. இது ChatGPT வாய்ஸ், Realtime API-யின் WebRTC எண்ட்பாயிண்ட் மற்றும் பல ஆராய்ச்சி திட்டங்களை இயக்குகிறது.

செயல்பாட்டில், டிரான்ஸ்சீவர் சேவை இரண்டு பணிகளைச் செய்கிறது:

• சிக்னலிங்: SDP negotiation, கோடெக் தேர்வு, ICE credentials மற்றும் அமர்வு அமைப்பு
• மீடியா: கீழ்நிலை WebRTC இணைப்புகளை நிறுத்தி, மேல்நிலை இணைப்புகளை அனுமானம் மற்றும் ஆர்க்கெஸ்ட்ரேஷனுக்காக பேக்கெண்ட் சேவைகளுடன் பராமரித்தல்.

சேவை எங்கள் மீதமுள்ள உள்கட்டமைப்பைப் போலவே இயங்க வேண்டும் என்று நாங்கள் விரும்பினோம்: Kubernetes-இல், அங்கு பணிச்சுமைகள் அளவை அதிகரிக்கவும் குறைக்கவும், தேவை மாறும்போது ஹோஸ்ட்களுக்கு இடையே நகரவும் முடியும். ஆனால் வழக்கமான ஒரு அமர்வுக்கு ஒரு போர்ட் என்ற WebRTC மாடல் அந்தச் சூழலுக்கு சரியாகப் பொருந்தாது, ஏனெனில் பொட்கள் சேர்க்கப்படும்போது, அகற்றப்படும்போது அல்லது மீள்திட்டமிடப்படும்போது வெளிப்படுத்தவும், பாதுகாக்கவும், பராமரிக்கவும் கடினமான பெரிய பொது UDP போர்ட் வரம்புகளையே அது சார்ந்துள்ளது.²

முதல் பிரச்சினை ஒரு அமர்வுக்கு ஒரு போர்ட் என்ற மாடல் தான். அதிக concurrency நிலையில், மிகப் பெரிய UDP போர்ட் வரம்புகளை வெளிப்படுத்தி நிர்வகிக்க வேண்டியதாகும்.

• கிளவுட் லோடு பாலன்சர்களும் Kubernetes சேவைகளும், ஒவ்வொரு சேவைக்கும் பல்லாயிரக்கணக்கான பொது UDP போர்ட்கள் இருப்பதை அடிப்படையாகக் கொண்டு வடிவமைக்கப்படவில்லை. ஒவ்வொரு கூடுதல் வரம்பும் சுமை சமநிலைப்படுத்தியின் உள்ளமைவு, ஹெல்த் சரிபார்ப்பு, ஃபயர்வால் கொள்கை மற்றும் ரோல்அவுட் பாதுகாப்பு ஆகியவற்றில் செயல்பாட்டு சிக்கலை அதிகரிக்கிறது.³
• பெரிய UDP போர்ட் வரம்புகளை பாதுகாப்பது கடினம், ஏனெனில் அவை வெளிப்புறத்திலிருந்து அணுகக்கூடிய மேற்பரப்பளவை விரிவாக்கி, நெட்வொர்க் கொள்கையைத் தணிக்கை செய்வதை மேலும் சிக்கலாக்குகின்றன.
• அவை autoscaling-க்கும் சரியான பொருத்தமல்ல. Kubernetes இல் pods தொடர்ந்து சேர்க்கப்படுகின்றன, அகற்றப்படுகின்றன, மற்றும் மீண்டும் திட்டமிடப்படுகின்றன. ஒவ்வொரு pod-மும் பெரிய, நிலையான port வரம்பை ஒதுக்கி அறிவிக்க வேண்டும் என்று கோருவது, அந்த நெகிழ்தன்மையை எளிதில் முறிவடையக்கூடியதாக ஆக்குகிறது.⁴

இதனால்தான் பல WebRTC அமைப்புகள், ஒவ்வொரு சர்வருக்கும் ஒற்றை UDP போர்டை நோக்கி நகர்கின்றன; அந்த போர்டுக்குப் பின்னால் பயன்பாட்டு-நிலை டீமல்டிப்ளெக்சிங் செய்யப்படுகிறது.⁵

ஒவ்வொரு சர்வருக்கும் ஒரே போர்ட் என்ற வடிவமைப்புகள் போர்ட் எண்ணிக்கைச் சிக்கலைத் தீர்க்கின்றன; ஆனால் அவை இரண்டாவது பிரச்சினையை உருவாக்குகின்றன: ஒரு சர்வர் தொகுதி முழுவதும் ஒவ்வொரு அமர்வின் உரிமையைப் பாதுகாப்பது.

ICE மற்றும் DTLS ஆகியவை நிலை சார்ந்த நெறிமுறைகள். ஒரு அமர்வை உருவாக்கிய செயல்முறை, இணைப்புச் சரிபார்ப்புகளைச் செல்லுபடியாக்க, DTLS handshake-ஐ நிறைவு செய்ய, SRTP-ஐ குறியாக்கம் நீக்க, மேலும் ICE மறுதொடக்கங்கள் போன்ற பின்னர் நிகழும் அமர்வு மாற்றங்களை செயலாக்க, அந்த அமர்வின் பாக்கெட்டுகளை தொடர்ந்து பெற்றுக்கொண்டிருக்க வேண்டும். அதே அமர்வுக்கான பாக்கெட்டுகள் வேறு செயல்முறைக்கு சென்றுவிட்டால், அமைவு தோல்வியடையலாம் அல்லது மீடியா செயலிழக்கலாம்.

அது எங்களுக்கு ஒரு குறிப்பிட்ட இலக்கைக் கொடுத்தது: சிறிய, நிலையான UDP மேற்பரப்பை பொது இணையத்தில் வெளிப்படுத்துவது, அதே நேரத்தில் ஒவ்வொரு பாக்கெட்டையும் அதற்குரிய WebRTC அமர்வைக் கொண்டிருக்கும் டிரான்ஸ்சீவருக்கு தொடர்ந்து வழிமாற்றுவது.

அதை அடைய பல வழிகளை நாங்கள் மதிப்பீடு செய்தோம், TURN (Traversal Using Relays around NAT) உட்பட. இதில், ஒரு எட்ஜ் ரிலே கிளையன்ட் ஒதுக்கீடுகளை முடித்து, அவர்களின் சார்பாக டிராஃபிக்கைக் கையாளுகிறது.²

நாங்கள் வெளியிட்ட கட்டமைப்பு, பாக்கெட் வழிமாற்றலை நெறிமுறை முடிவுறுத்தலிலிருந்து பிரிக்கிறது. செஷன் செட்டப்புக்காக சிக்னலிங் இன்னும் டிரான்ஸீவரை அடைகிறது, அதே நேரத்தில் மீடியா முதலில் ரிலே வழியாக நுழைகிறது. ரிலே என்பது சிறிய பொது தடத்துடன் கூடிய இலகுரக UDP முன்னனுப்பும் அடுக்கு ஆகும், மேலும் டிரான்ஸீவர் என்பது அதன் பின்னால் உள்ள நிலையைப் பராமரிக்கும் WebRTC எண்ட்பாயிண்ட் ஆகும்.

ரிலே மீடியாவை டிக்ரிப்ட் செய்யாது, ICE நிலை மெஷின்களை இயக்காது அல்லது கோடெக் பேச்சுவார்த்தையில் பங்கேற்காது. அது இலக்கைத் தேர்ந்தெடுக்க போதுமான பாக்கெட் மெட்டாடேட்டாவைப் படித்து, பின்னர் அந்த அமர்வின் பொறுப்பில் இருக்கும் டிரான்ஸீவருக்கு பாக்கெட்டை அனுப்புகிறது. டிரான்ஸீவர் இன்னும் ஒரு சாதாரண WebRTC ஓட்டத்தையே காண்கிறது, மேலும் அனைத்து நெறிமுறை நிலைகளையும் தன் பொறுப்பில் வைத்திருக்கிறது. கிளையன்டின் பார்வையில், WebRTC அமர்வில் எதுவும் மாறாது.

இந்த அமைப்பில் முதல்-பாக்கெட் ரௌட்டிங் முக்கியமான படியாகும். ஒரு ரிலே, வெளிப்புற லுக்கப் சேவையில் காத்திருப்பதற்குப் பதிலாக, பாக்கெட் பாதையிலேயே எந்த அமர்வும் இன்னும் இல்லாத நிலையில், கிளையன்டிடமிருந்து வரும் முதல் பாக்கெட்டை வழிமாற்ற வேண்டும்.

ஒவ்வொரு WebRTC செஷனும் ஏற்கனவே ப்ரொடோகாலுக்கே உரிய ஒரு ரூட்டிங் ஹுக்கைக் கொண்டுள்ளது: ICE username fragment, அல்லது ufrag, இது செஷன் அமைப்பின் போது பரிமாறப்படும் ஒரு குறுகிய அடையாளங்காட்டி; மேலும் STUN கனெக்டிவிட்டி சோதனைகளில் எதிரொலிக்கப்படுகிறது. இலக்கு க்ளஸ்டர் மற்றும் அதற்குரிய டிரான்ஸ்சீவரை ரிலே கண்டறியத் தேவையான அளவு ரௌட்டிங் மெட்டாடேட்டா மட்டும் அதில் அடங்குமாறு, சேவையகப் பக்க ufrag-ஐ நாங்கள் உருவாக்குகிறோம்.

சிக்னலிங் நடைபெறும் போது, டிரான்ஸீவர் அமர்வு நிலையை ஒதுக்கி, SDP பதிலில் பகிரப்பட்ட ரிலே VIP மற்றும் UDP போர்ட்டை திருப்பி வழங்குகிறது. VIP என்பது ரிலே தொகுப்பின் முன்னிலையில் இருக்கும் ஒரு மெய்நிகர் IP முகவரியாகும்; போர்ட்டுடன் சேர்க்கப்பட்டால், அதன் பின்னால் பல ரிலே நிகழ்வுகள் இருந்தாலும், இது கிளையன்டுக்கு `203.0.113.10:3478` போன்ற ஒரே நிலையான இலக்கை வழங்குகிறது. கிளையன்டின் முதல் மீடியா-பாதை பாக்கெட் பொதுவாக STUN (Session Traversal Utilities for NAT) பைண்டிங் கோரிக்கையாக இருக்கும்; அறிவிக்கப்பட்ட முகவரியை பாக்கெட்டுகள் சென்றடைய முடியுமா என்பதைச் சரிபார்க்க ICE இதைப் பயன்படுத்துகிறது.

Relay, சர்வர் ufrag-ஐப் படிக்கவும், வழித்தடக் குறிப்பை குறிவிலக்கவும், அந்தத் தொகுப்பை அதற்குரிய transceiver-க்கு அனுப்பவும் தேவையான அளவிற்கு மட்டுமே அந்த முதல் STUN தொகுப்பைப் பகுப்பாய்வு செய்கிறது. ஒவ்வொரு டிரான்ஸீவரும் பகிரப்பட்ட UDP சாக்கெட்டில் கேட்கிறது, அதாவது உள் IP:port உடன் பிணைக்கப்பட்ட ஒரு operating system எண்ட்பாயிண்ட், அமர்வு ஒன்றுக்கு ஒரு சாக்கெட் அல்ல. கிளையண்டின் மூல IP:port இலிருந்து அந்த டிரான்ஸீவர் இலக்குக்கான ஒரு அமர்வை ரிலே உருவாக்கிய பிறகு, அதன்பின் வரும் DTLS, RTP, மற்றும் RTCP பாக்கெட்டுகள் ufrag-ஐ மீண்டும் டிகோடு செய்யாமல் அந்த அமர்வுக்குள் செல்கின்றன.

ரிலேவின் அமர்வு நோக்கமுடனே குறைந்தபட்சமாக வைக்கப்பட்டுள்ளது. இது பாக்கெட் முன்னனுப்புதலைத் தெரிவிக்க நினைவகத்திலேயே இருக்கும் ஒரு அமர்வையும், கண்காணிப்புக்குத் தேவையான கவுண்டர்களையும், அமர்வு காலாவதி மற்றும் சுத்தப்படுத்தலுக்கான டைமர்களையும் மட்டுமே கொண்டுள்ளது. இந்த வடிவமைப்புத் தேர்வு, பாக்கெட் ரூட்டிங்கை நேரடியாக பாக்கெட் பாதையிலேயே வைத்திருக்கிறது. ஒரு ரிலே மறுதொடக்கம் ஆகி செஷனை இழந்தால், அடுத்த STUN பாக்கெட் ufrag ரூட்டிங் குறிப்பிலிருந்து செஷனை மீண்டும் உருவாக்குகிறது. இதை இன்னும் நம்பகமானதாக மாற்ற, வழித்தடம் நிறுவப்பட்டதும் <கிளையண்ட் IP + போர்ட், டிரான்ஸீவர் IP + போர்ட்> என்பதின் மேப்பிங்கை வைத்திருக்க Redis கேஷ் பயன்படுத்தப்படுகிறது. இதனால் அடுத்த STUN பாக்கெட் வருவதற்கு முன்பே அதை மிகவும் முன்னதாக மீட்டெடுக்க முடியும்.

பொதுவாக வெளிப்படும் UDP பரப்பை சில நிலையான முகவரிகள் மற்றும் போர்ட்களாகக் குறைத்த பிறகு, அதே ரிலே முறையை உலகளவில் செயல்படுத்த முடிந்தது. Global Relay என்பது ஒரே மாதிரியான பாக்கெட்-முன்னனுப்பு நடத்தையை செயல்படுத்தும், புவியியல் ரீதியாகப் பரவியுள்ள ரிலே உள்வரவு புள்ளிகளின் எங்கள் தொகுப்பாகும்.

பரந்த புவியியல் நுழைவு (ingress) OpenAI-க்கு செல்லும் முதல் கிளையண்ட் ஹாப்பைச் சுருக்குகிறது, ஏனெனில் ஒரு பாக்கெட் பப்ளிக் இணையத்தை கடந்து தொலைதூரப் பிரதேசத்திற்குச் செல்லாமல், புவியியல் மற்றும் நெட்வொர்க் டோபாலஜி ரீதியாக பயனருக்கு அருகிலுள்ள ஒரு ரிலேவில் எங்கள் நெட்வொர்க்குக்குள் நுழைய முடியும். நடைமுறையில், இதன் பொருள் டிராஃபிக் எங்கள் பேக்போனை அடையும் முன் குறைந்த தாமதம், குறைவான ஜிட்டர் மற்றும் தவிர்க்கக்கூடிய திடீர் இழப்புகள் குறைவாக இருக்கும் என்பதாகும்.⁶

சிக்னலிங்கிற்காக Cloudflare இன் geo மற்றும் proximity steering-ஐ பயன்படுத்துகிறோம், இதனால் ஆரம்ப HTTP அல்லது WebSocket கோரிக்கை அருகிலுள்ள டிரான்ஸ்சீவர் கிளஸ்டரை அடைகிறது. கோரிக்கை சூழல் செஷனின் இருப்பிடத்தையும், வாடிக்கையாளருக்கு எந்த Global Relay ingress point அறிவிக்கப்படுகிறது என்பதையும் தீர்மானிக்கிறது. SDP பதில் Global Relay முகவரியை வழங்குகிறது; அதே நேரத்தில், நியமிக்கப்பட்ட கிளஸ்டருக்கு ஊடகத் தரவை வழிமாற்ற Global Relay-க்கும், இலக்கு டிரான்ஸ்சீவருக்கு வழிமாற்ற ரிலேக்கும் தேவையான தகவலை ufrag கொண்டுள்ளது.

புவியியல் அடிப்படையில் வழிநடத்தப்படும் சிக்னலிங் மற்றும் Global Relay ஆகியவை இணைந்து, அமர்வை ஒரே அனுப்பி-பெறியுடன் நிலைநிறுத்தியபடி, அமைப்பு செயல்முறை மற்றும் மீடியா இரண்டையும் அருகிலுள்ள நுழைவு பாதையில் வைக்கின்றன. இது சிக்னலிங்கிற்கும் முதல் ICE இணைப்புத்திறன் சரிபார்ப்பிற்குமான ரவுண்ட்-ட்ரிப் நேரத்தை குறைக்கிறது, இதனால் பேச்சு தொடங்கும் முன் பயனர் காத்திருக்க வேண்டிய நேரம் நேரடியாகக் குறைகிறது.

நாங்கள் ரிலே சேவையை Go-வில் எழுதி, இம்ப்ளிமென்டேஷனை நோக்கத்துடனே குறுகிய வரம்பில் வைத்தோம். Linux-இல், கர்னலின் நெட்வொர்க்கிங் ஸ்டாக் மெஷினின் நெட்வொர்க் இடைமுகத்திலிருந்து UDP பாக்கெட்டுகளைப் பெற்று, அவற்றை ஒரு சாக்கெட்டுக்கு வழங்குகிறது; அது IP:Port-ஐ பைண்ட் செய்த பிறகு ஒரு செயல்முறை வாசிக்கும் இயக்க முறைமை எண்ட்பாயிண்ட் ஆகும். Relay பயனர் இடத்தில் (userspace) இயங்குவதால், ஒரு வழக்கமான Go செயல்முறை அந்த socket-இலிருந்து பாக்கெட் தலைப்புகளைப் படித்து, சிறிய அளவிலான ஓட்ட நிலையைப் புதுப்பித்து, WebRTC-ஐ முடிவுக்குக் கொண்டு வராமல் பாக்கெட்டுகளை முன்னனுப்புகிறது. அதிக பாக்கெட் வீதங்களுக்காக பயனர்-இட செயல்முறை நெட்வொர்க் வரிசைகளை நேரடியாக poll செய்ய அனுமதிக்கும், ஆனால் செயல்பாட்டு சிக்கலையும் சேர்க்கும் எந்தவொரு கர்னல்-பைபாஸ் கட்டமைப்பும் எங்களுக்கு தேவையில்லை.

முக்கிய வடிவமைப்புத் தேர்வுகள்:

• நெறிமுறை முடிவுறுத்தல் இல்லை: ரிலே STUN ஹெடர்கள்/ufrag மட்டுமே பகுப்பாய்வு செய்கிறது; பின்னர் வரும் DTLS, RTP மற்றும் RTCP க்காக கேச் செய்யப்பட்ட நிலையைப் பயன்படுத்தி, பாக்கெட்டுகளை வெளிப்படாதவையாக வைத்திருக்கிறது.
• தற்காலிக நிலை: பாய்வு நிலை மற்றும் கவனிப்புத்தன்மைக்காக, இது கிளையன்ட் முகவரியிலிருந்து டிரான்சீவர் இலக்கிற்கான குறுகிய நேரமுடிவு கொண்ட, நினைவக மேப்பை பராமரிக்கிறது.
• கிடைமட்ட விரிவாக்கத்திறன்: ஒரு லோடு பாலன்சருக்குப் பின்னால் பல ரிலே இன்ஸ்டன்ஸ்கள் இணையாக இயங்குகின்றன. நிலை என்பது கடினமான WebRTC நிலை அல்ல; எனவே மறுதொடக்கங்கள் குறைந்தபட்ச போக்குவரத்து குறைவுகளையும் விரைவான ஓட்ட மீட்பையும் ஏற்படுத்துகின்றன.

செயல்திறன் நடவடிக்கைகள்.

• SO_REUSEPORT என்பது ஒரே கணினியில் பல relay worker-கள் ஒரே UDP போர்ட்டை bind செய்ய அனுமதிக்கும் Linux சாக்கெட் விருப்பமாகும். பின்னர் கர்னல் உள்வரும் பாக்கெட்டுகளை அந்த வொர்க்கர்களுக்கிடையே பகிர்ந்தளிக்கிறது; இதனால் ஒற்றை read-loop தடங்கல் தவிர்க்கப்படுகிறது.
• runtime.LockOSThread ஒவ்வொரு UDP வாசிக்கும் goroutine-ஐ ஒரு குறிப்பிட்ட OS thread-இல் பிணைக்கிறது. SO_REUSEPORT உடன் இணைக்கப்படும்போது, அது ஒரே பாய்விலிருந்து வரும் packets-ஐ (மூல மற்றும் இலக்கு IP:Port மற்றும் protocol) அதே CPU core-இல் வைத்திருக்க முனைகிறது, இதனால் cache locality மேம்பட்டு context switching குறைகிறது.
• முன்கூட்டியே ஒதுக்கப்பட்ட பஃபர்கள் மற்றும் குறைந்தபட்ச நகலெடுத்தல் மூலம், Go-வில் குப்பை சேகரிப்பைத் தவிர்க்க பார்சிங் மற்றும் ஒதுக்கீட்டு ஓவர்ஹெட்டை குறைவாக வைத்திருக்க முடியும்.

இந்த செயலாக்கம் ஒப்பீட்டளவில் சிறிய ரிலே வளத் தடயத்துடன் எங்கள் உலகளாவிய நிகழ்நேர மீடியா போக்குவரத்தை கையாண்டது, அதனால் கர்னல் பைபாஸ் பாதையை மேற்கொள்வதற்குப் பதிலாக எளிமையான வடிவமைப்பையே வைத்திருந்தோம்.

இந்த கட்டமைப்பு, ஆயிரக்கணக்கான UDP போர்ட்களை வெளிப்படுத்தாமல் Kubernetes இல் WebRTC மீடியாவை இயக்க அனுமதிக்கிறது. அது முக்கியமானது, ஏனெனில் சிறியதும் நிலையானதுமான UDP பரப்பைப் பாதுகாப்பதும் சுமை சமநிலைப்படுத்துவதும் எளிதானது, மேலும் பெரிய பொதுப் போர்ட் வரம்புகளை ஒதுக்கிவைக்காமல் உள்கட்டமைப்பு விரிவடைய இது உதவுகிறது. Kubernetes வழங்கும் சிறந்த உள்கட்டமைப்பு ஆதரவும், குறைந்த தாக்குதல் பரப்பளவு காரணமாக மேம்பட்ட பாதுகாப்பும் கிடைப்பதால், இந்த வடிவமைப்பு கிளையண்ட்களுக்கான நிலையான WebRTC செயல்பாட்டையும் பாதுகாக்கிறது, மேலும் எங்கள் பணிச்சுமைக்கு SFU இல்லாத வடிவமைப்பே சரியான இயல்புநிலை என்பதை உறுதிப்படுத்துகிறது. எங்கள் பெரும்பாலான அமர்வுகள் பாயிண்ட்-டு-பாயிண்ட் வகையிலானவை, பதுங்குநிலை-உணர்திறன் கொண்டவை, மேலும் இன்ஃபரன்ஸ் சேவைகள் WebRTC பியர்களைப் போலச் செயல்பட வேண்டியதில்லை என்றால் அவற்றை அளவிடுவது எளிதாகும்.

சிக்கல்தன்மையைச் சேர்க்க சிறந்த இடம் ஒரு இலகுவான routing layer-இல்தான்; ஒவ்வொரு backend service-இலும் அல்ல, தனிப்பயன் client behavior-இலும் அல்ல என்பதே பரந்த பாடமாகும். ரூட்டிங் மெட்டாடேட்டாவை நெறிமுறைக்கு இயல்பான புலத்தில் குறியாக்கியது, இது எங்களுக்கு முதல் பாக்கெட்டிலேயே நிச்சயமான ரூட்டிங், சிறிய பொது UDP தடம், மற்றும் உலகம் முழுவதும் உள்ள பயனர்களுக்கு அருகில் ingress ஐ அமைக்க போதுமான நெகிழ்வுத்தன்மையை வழங்கியது.

சில தேர்வுகள் மிகவும் முக்கியமானவை என்று கருதப்பட்டன:

• எட்ஜ் பகுதியில் நெறிமுறை அர்த்தவியலைப் பாதுகாக்கவும். கிளையன்ட்கள் இன்னும் தரநிலையான WebRTC-யைப் பேசுகின்றன, இதனால் உலாவி மற்றும் மொபைல் இடையிலான இணக்கத்தன்மை முழுமையாகக் காக்கப்படுகிறது.
• கடினமான அமர்வு நிலைகள் ஒரே இடத்தில் இருக்க வேண்டும். டிரான்ஸ்சீவர் ICE, DTLS, SRTP மற்றும் அமர்வு நிலைமுறையை நிர்வகிக்கிறது; ரிலே பாக்கெட்டுகளை மட்டுமே அனுப்புகிறது.
• அமைப்பில் ஏற்கனவே உள்ள தகவலின் அடிப்படையில் வழிநடத்தவும். ICE ufrag நமக்கு, ஹாட்-பாத் தேடல் சார்புநிலையைச் சேர்க்காமல், முதல்-பாக்கெட் வழிநடத்தல் ஹூக்கை வழங்கியது.
• கர்னல் பைபாஸை நாடுவதற்கு முன், பொதுவான நிலைக்காக மேம்படுத்தவும். SO_REUSEPORT-ஐ கவனமாகப் பயன்படுத்துதல், thread pinning, மற்றும் குறைந்த-ஒதுக்கீட்டு parsing ஆகியவற்றுடன் கூடிய ஒரு குறுகிய Go செயலாக்கம் எங்கள் பணிச்சுமைக்கு போதுமானதாக இருந்தது.

உள்கட்டமைப்பு தாமதத்தை உணர முடியாததாக ஆக்கினால் மட்டுமே நேரடி குரல் AI செயல்படும். எங்களைப் பொறுத்தவரை, WebRTC-யிடமிருந்து கிளையன்ட்கள் எதிர்பார்ப்பதை மாற்றாமல், எங்கள் WebRTC deployment-இன் வடிவத்தை மாற்றுவதாக அது பொருள்பட்டது.