OpenAI મોટા પાયે ઓછી વિલંબતા ધરાવતું વોઈસ AI કેવી રીતે પ્રદાન કરે છે

વોઈસ AI ત્યારે જ સ્વાભાવિક લાગે છે જ્યારે વાતચીત બોલવાની ઝડપે આગળ વધે છે. જ્યારે નેટવર્ક અવરોધરૂપ બને છે ત્યારે લોકોને તે તરત જ અટપટા વિરામો, અધવચ્ચે કપાઈ જતા વિક્ષેપો અથવા મોડું થતું બાર્જ-ઇન તરીકે સંભળાય છે. આ બાબત ChatGPT વૉઇસ માટે રિયલટાઈમ એપીઆઈ સાથે કામ કરતા ડેવલપર્સ માટે ઈન્ટરેક્ટિવ વર્કફ્લોઝમાં કાર્યરત એજન્ટ્સ માટે અને વપરાશકર્તા હજી બોલી રહ્યાં હોય ત્યારે ઑડિયો પ્રોસેસ કરવાની જરૂર ધરાવતા મોડલ માટે મહત્વ ધરાવે છે.

OpenAI ના સ્તર, તે ત્રણ ચોક્કસ આવશ્યકતામાં અનુવાદિત થાય છે:

• 90 કરોડથી વધુ સાપ્તાહિક સક્રિય વપરાશકર્તા સુધી વૈશ્વિક પહોંચ
• ઝડપી કનેક્શન સેટઅપ કરવું જેથી સત્ર શરૂ થતાં જ વપરાશકર્તા તરત બોલી શકે
• ઓછો અને સ્થિર મીડિયા રાઉન્ડ-ટ્રિપ સમય, ઓછા જિટર અને ઓછા પૅકેટ લોસ સાથે કે જેથી વારા-ફરતી બોલવાનું ચુસ્ત લાગે

રીઅલ-ટાઇમ AI ઈન્ટરૅક્શન્સ માટે જવાબદાર OpenAI ની ટીમે તાજેતરમાં અમારા વેબઆરટીસી સ્ટેકને ફરીથી આર્કિટેક્ટ કર્યું હતુ જેથી મોટા પાયે ટકરાવતી ત્રણ મર્યાદાઓનો ઉકેલ લાવી શકાય: સત્ર દીઠ એક પોર્ટવાળું મીડિયા ટર્મિનેશન OpenAI ઇન્ફ્રાસ્ટ્રક્ચર માટે યોગ્ય નથી, સ્ટેટફુલ આઈસી (ઈન્ટરેક્ટિવ કનેક્ટિવિટી એસ્ટાબ્લિશમેન્ટ) અને ડીટીએલએસ (ડેટાગ્રામ ટ્રાન્સપોર્ટ લેયર સિક્યુરિટી) સેશન્સને સ્થિર માલિકીની જરૂર છે અને ગ્લોબલ રાઉટિંગે પ્રથમ-હોપ લેટન્સી ઓછી રાખવી જરૂરી છે. આ પોસ્ટમાં અમે ક્લાયન્ટ્સ માટે સ્ટાન્ડર્ડ વેબઆરટીસી વર્તન જાળવી રાખવા માટે બનાવેલા વિભાજિત રિલે પ્લસ ટ્રાન્સસીવર આર્કિટેક્ચરને સમજાવીએ છીએ અને OpenAI ના ઈન્ફ્રાસ્ટ્રક્ચરની અંદર પેકેટ્સને કેવી રીતે રાઉટ કરવામાં આવે છે તે બદલીએ છીએ.

વેબઆરટીસી એ બ્રાઉઝર્સ, મોબાઇલ એપ્સ અને સર્વર્સ વચ્ચે ઓછા વિલંબવાળા ઑડિઓ, વિડિઓ અને ડેટા મોકલવા માટેનું ખુલ્લું ધોરણ છે. તેને ઘણી વખત પીઅર-ટુ-પીઅર કૉલિંગ સાથે જોડવામાં આવે છે, પરંતુ તે ક્લાયન્ટ-ટુ-સર્વર રીઅલ-ટાઇમ સિસ્ટમ્સ માટે પણ એક વ્યવહારુ પાયો છે, કારણ કે તે ઇન્ટરેક્ટિવ મીડિયાના મુશ્કેલ ભાગોને સ્ટાન્ડર્ડાઇઝ કરે છે: કનેક્ટિવિટી સ્થાપવા અને એનએટી (નેટવર્ક એડ્રેસ ટ્રાન્સલેશન) ટ્રાવર્સલ માટે આઈસીઈ, એન્ક્રિપ્ટેડ ટ્રાન્સપોર્ટ માટે ડીટીએલએસ અને એસઆરટીપી (સિક્યુર રિયલ-ટાઈમ ટ્રાન્સપોર્ટ પ્રોટોકોલ), ઑડિયોને કમ્પ્રેસ અને ડીકોડ કરવા માટે કોડેક નેગોશિયેશન, ગુણવત્તા નિયંત્રણ માટે આરટીસીપી (રિયલ-ટાઈમ ટ્રાન્સપોર્ટ કન્ટ્રોલ પ્રોટોકોલ), અને ક્લાયન્ટ-સાઇડ સુવિધાઓ જેમ કે ઇકો કેન્સલેશન અને જિટર બફરિંગ.

તે માનકીકરણ AI પ્રોડક્ટ્સ માટે મહત્વપૂના છે. વેબઆરટીસી વગર, દરેક ક્લાયન્ટને એનએટી પર કનેક્ટિવિટી સ્થાપિત કરવા મીડિયાને એન્ક્રિપ્ટ કરવા, કોડેક્સ (ટ્રાન્સમિશન અને ડિકમ્પ્રેશન માટે પસંદ કરાયેલા કોડર-ડિકોડર્સ) નેગોશિએટ કરવા અને બદલાતી નેટવર્ક પરિસ્થિતિને અનુકૂળ થવા માટે અલગ ઉકેલની જરૂર પડશે. વેબઆરટીસી સાથે, અમે બ્રાઉઝર્સ અને મોબાઇલ પ્લેટફોર્મ્સમાં પહેલેથી જ અમલમાં મૂકાયેલા પ્રોટોકોલ સ્ટેક પર નિર્માણ કરી શકીએ છીએ અને અમારા પોતાના કાર્યને રિયલ-ટાઇમ મીડિયાને મોડલ સાથે જોડતા ઇન્ફ્રાસ્ટ્રક્ચર પર કેન્દ્રિત કરી શકીએ છીએ.

અમે વેબઆરટીસી ઇકોસિસ્ટમ પર પણ નિર્માણ કરીએ છીએ કે જેમાં પરિપક્વ ઓપન-સોર્સ અમલીકરણો અને બ્રાઉઝર્સ, મોબાઇલ એપ્સ અને સર્વર્સને પરસ્પર સુસંગત રાખવાને લગતા ધોરણોનો સમાવેશ થાય છે. જસ્ટીન ઉબર્ટી (વેબઆરટીસીના મૂળ આર્કિટેક્ટ્સમાંના એક) અને સીન દુબાયોઈસ (પાયોનના સર્જક અને મેન્ટેનર) દ્વારા કરાયેલા પાયાના કાર્યથી, અમારી જેવી ટીમો માટે નીચલા સ્તરના ટ્રાન્સપોર્ટ, એન્ક્રિપ્શન અને કન્જેશન-કંટ્રોલ વર્તણૂકને ફરીથી વિકસાવવાને બદલે વ્યાપક રીતે પરીક્ષણ કરાયેલા મીડિયા ઇન્ફ્રાસ્ટ્રક્ચર પર આધાર રાખી કામ કરવું શક્ય બન્યું. અમારું સદનસીબ છે કે જસ્ટિન અને શોન બંને હવે અહીં OpenAI માં સહકર્મીઓ છ, અને વેબઆરટીસી અને રીઅલ-ટાઈમ AI ને વધુ નજીક લાવવાના માર્ગદર્શનમાં મદદ કરી રહ્યા છે.

AI માટે સૌથી મહત્વનો ગુણધર્મ એ છે કે ઓડિયો સતત સ્ટ્રીમ તરીકે આવે છે. વપરાશકર્તા હજુ પણ બોલી રહ્યો હોય ત્યારે સંપૂર્ણ અપલોડની રાહ જોવાને બદલે સ્પોકન એજન્ટ ટ્રાન્સક્રાઇબ કરવું, તર્ક કરવું, ટૂલ્સને કૉલ કરવું અથવા ભાષણ જનરેટ કરવું શરૂ કરી શકે છે. એવી જ એ સિસ્ટમ વચ્ચેનો ફરક છે જે વાતચીત જેવી લાગે છે અને એ સિસ્ટમ વચ્ચેનો જે પુશ-ટુ-ટૉક જેવી લાગે છે.

એકવાર અમે વેબઆરટીસી પસંદ કર્યું, ત્યારબાદનો પ્રશ્ન એ હતો કે તેને ક્યાં ટર્મિનેટ કરવું (જ્યાં અમે વેબઆરટીસી કનેક્શન સ્વીકારીને તેની જવાબદારી લઈશું—ઉદાહરણ તરીકે, એજ પર) અને તે સત્રોને ઈન્ફરન્સ બેકએન્ડ સાથે કેવી રીતે જોડવું. ટર્મિનેશન મહત્વ ધરાવે છે કારણ કે તે નક્કી કરે છે કે આપણે રીઅલ-ટાઈમ સત્ર સ્થિતિ, મીડિયા ટ્રાન્સપોર્ટ, રૂટિંગ, વિલંબ અને નિષ્ફળતા અલગતાને કેવી રીતે સંભાળીએ છીએ.

SFU, અથવા સિલેક્ટિવ ફોર્વડિંગ યુનિટ, એક મીડિયા સર્વર છે જે દરેક સહભાગી પાસેથી એક વેબઆરટીસી સ્ટ્રીમ પ્રાપ્ત કરે છે અને પસંદગીપૂર્વક સ્ટ્રીમ્સ અન્ય સહભાગીઓને ફોરવર્ડ કરે છે. આ મોડલમાં એસએફયુ દરેક સહભાગી માટે અલગ વેબઆરટીસી કનેક્શન ટર્મિનેટ કરે છે અને AI સેશનમાં અન્ય એક સહભાગી તરીકે જોડાય છે. તે એવા પ્રોડક્ટ્સ માટે યોગ્ય વિકલ્પ હોઈ શકે છે કે જે સ્વાભાવિક રીતે બહુ-પક્ષીય હોય જેમ કે ગ્રુપ કૉલ્સ, વર્ગખંડો અથવા સહયોગી મીટિંગ્સ. તે ઑડિયો કોડેક્સ આરટીસીપી સંદેશા, ડેટા ચેનલો, રેકોર્ડિંગ અને પ્રતિ-સ્ટ્રીમ નીતિને એક જગ્યાએ રાખે છે.¹

ક્લાયન્ટ-થી-AI પ્રોડક્ટ્સમાં પણ એસએફયુ ઘણીવાર ડિફોલ્ટ શરૂઆતનું બિંદુ હોય છે, કારણ કે તે ટીમોને સિગ્નલિંગ, મીડિયા રૂટિંગ, રેકોર્ડિંગ, ઑબ્ઝર્વેબિલિટી અને માનવીને હેન્ડઓફ અથવા વધુ ભાગીદારો ઉમેરવા જેવા ભવિષ્યના વિસ્તરણો માટે એક જ સાબિત સિસ્ટમનો ફરીથી ઉપયોગ કરવાની સુવિધા આપે છે.

અમારો વર્કલોડ અલગ છે. મોટાભાગનાં સેશન્સ 1:1 હોય છે—એક યુઝર એક મોડલ સાથે વાત કરતો હોય અથવા એક એપ્લિકેશન એક રિયલ-ટાઇમ એજન્ટ સાથે વાત કરતી હોય—દરેક ટર્ન પર લેટન્સી માટેની સંવેદનશીલતા સાથે. ટ્રાફિકના તે સ્વરૂપ માટે, અમે ટ્રાન્સસીવર મોડલ પસંદ કર્યું: એક વેબઆરટીસી એજ સર્વિસ ક્લાયન્ટ કનેક્શનને ટર્મિનેટ કરે છે અને પછી મીડિયા અને ઇવેન્ટ્સને મોડલ ઇન્ફરન્સ, ટ્રાન્સક્રિપ્શન, વાણી જનરેશન, ટૂલ ઉપયોગ અને ઓર્કેસ્ટ્રેશન માટે વધુ સરળ ઇન્ટર્નલ પ્રોટોકોલ્સમાં રૂપાંતરિત કરે છે.

આ ડિઝાઇનમાં, ટ્રાન્સસીવર એ એકમાત્ર સર્વિસ છે જે વેબઆરટીસી સેશન સ્ટેટની માલિકી ધરાવે છે, જેમાં આઈસીઈ કનેક્ટિવિટી ચેક્સ, ડીટીએલએસ હેન્ડશેક, એસઆરટીપી એન્ક્રિપ્શન કીઝ અને સેશન લાઇફસાઇકલ શામેલ છે. અહીં “ટર્મિનેશન”નો અર્થ એ છે કે ટ્રાન્સસીવર એ એન્ડપોઇન્ટ છે જે તે હેન્ડશેક્સ પૂર્ણ કરે છે અને મીડિયાને એન્ક્રિપ્ટ અથવા ડિક્રિપ્ટ કરે છે. તે સ્થિતિને એક જ જગ્યાએ રાખવાથી સેશનની માલિકી વિશે વિચારવું વધુ સરળ બન્યું, અને તેના કારણે બેકએન્ડ સેવાઓ પોતે વેબઆરટીસી પીઅર્સ તરીકે કાર્ય કરવાને બદલે સામાન્ય સેવાની જેમ સ્કેલ થઈ શકી.

ટ્રાન્સસીવર મોડલ પસંદ કર્યા પછી અમારું પ્રથમ અમલીકરણ પિયોન પર બનાવવામાં આવેલી એક જ ગો સેવા હતી, જે સિગ્નલિંગ અને મીડિયા ટર્મિનેશન બંને સંભાળતી હતી. તે ChatGPT વૉઇસ, રીઅલ-ટાઇમ એપીઆઈના વેબઆરટીસી એન્ડપોઇન્ટ અને અનેક સંશોધન પ્રોજેક્ટ્સને પાવર કરે છે.

કાર્યકારી રીતે ટ્રાન્સસીવર સેવા બે કાર્યો કરે છે:

• સિગ્નલિંગ: એસડીપી વાટાઘાટ, કોડેક પસંદગી, આઈસીઈ ક્રેડેન્શિયલ્સ અને સત્ર સેટઅપ
• મીડિયા: ઈન્ફરન્સ અને ઓર્કેસ્ટ્રેશન માટે બેકએન્ડ સેવાઓ સાથે અપસ્ટ્રીમ કનેક્શન્સ જાળવી રાખતી વખતે ડાઉનસ્ટ્રીમ વેબઆરટીસી કનેક્શન્સને ટર્મિનેટ કરવું

અમે ઇચ્છતા હતા કે આ સેવા અમારી બાકીની ઈન્ફ્રાસ્ટ્રક્ચરની જેમ ચાલે: કુબેરનેટ્સ પર, જ્યાં વર્કલોડ્સ સ્કેલ અપ અને ડાઉન થઈ શકે અને માંગ બદલાતી જાય તેમ હોસ્ટ્સ વચ્ચે ખસેડાઈ શકે. પરંતુ દર સત્ર માટે એક પોર્ટ ધરાવતું પરંપરાગત વેબઆરટીસી મોડલ તે પર્યાવરણમાં યોગ્ય રીતે બંધબેસતું નથી કારણ કે તે મોટી જાહેર યુડીપી પોર્ટ રેન્જ પર આધારિત છે, જેને પોડ્સ ઉમેરવામાં દૂર કરવામાં અથવા ફરી શેડ્યૂલ કરવામાં આવે છે ત્યારે એક્સપોઝ કરવી, સુરક્ષિત કરવી તથા જાળવી રાખવી મુશ્કેલ હોય છે.²

પ્રથમ સમસ્યા એક-પોર્ટ-પ્રતિ-સત્ર મોડલ પોતે જ હતી. ઉચ્ચ સમકાલીનતા પર તેનો અર્થ ખૂબ મોટી યુડીપી પોર્ટ શ્રેણીને પ્રદર્શિત અને મેનેજ કરવો થાય છે.

• ક્લાઉડ લોડ બેલેન્સર્સ અને કુબેરનેટ્સ સેવા સેવા દીઠ 10,000થી વધુ જાહેર યુડીપી પોર્ટ્સ માટે ડિઝાઇન કરવામાં આવી નથી. દરેક વધારાની રેન્જ સાથે લોડ બેલેન્સર કૉન્ફિગ, હેલ્થ ચેકિંગ, ફાયરવૉલ નીતિ અને રોલઆઉટ સુરક્ષામાં ઓપરેશનલ જટિલતા ઉમેરે છે.³
• મોટી યુડીપી પોર્ટ શ્રેણીને સુરક્ષિત કરવી મુશ્કેલ છે, કારણ કે તે બહારથી પહોંચી શકાય તેવા સપાટી વિસ્તારને વિસ્તારે છે અને નેટવર્ક નીતિનું ઓડિટ કરવું મુશ્કેલ બનાવે છે.
• તે ઑટોસ્કેલિંગ માટે પણ યોગ્ય નથી. કુબેરનેટ્સમાં પોડ્સ સતત ઉમેરવામાં, દૂર કરવામાં અને ફરીથી શેડ્યૂલ કરવામાં આવે છે. દરેક પોડને મોટી સ્થિર પોર્ટ શ્રેણી અનામત રાખવા અને જાહેર કરવાની જરૂર રાખવાથી તે લવચીકતાને અસર કરી શકે છે.⁴

તેથી જ ઘણી વેબઆરટીસી સિસ્ટમ્સ દરેક સર્વર દીઠ એક જ યુડીપી પોર્ટ તરફ આગળ વધે છે, જેમાં તે પોર્ટ પાછળ એપ્લિકેશન-સ્તરનું ડીમલ્ટીપ્લેક્સિંગ હોય છે.⁵

સર્વર દીઠ એક પોર્ટવાળી ડિઝાઇન પોર્ટની સંખ્યાની સમસ્યાને ઉકેલે છે પરંતુ તે બીજી સમસ્યા ઊભી કરે છે: સર્વરોના સમૂહમાં દરેક સેશનની માલિકી જાળવી રાખવી.

આઈસીઈ અને ડીટીએલએસ સ્ટેટફુલ પ્રોટોકોલ છે. સેશન બનાવનાર પ્રક્રિયાએ તે સેશનના પૅકેટ્સ મેળવતા રહેવાની જરૂર છે, જેથી તે કનેક્ટિવિટી ચેક્સને માન્ય કરી શકે, ડીટીએલએસ હેન્ડશેક પૂર્ણ કરી શકે, એસઆરટીપી ડિક્રિપ્ટ કરી શકે અને પછીના સેશન ફેરફારો, જેમ કે આઈસીઈ રીસ્ટાર્ટ્સ, પ્રોસેસ કરી શકે. જો એક જ સત્રના પેકેટ્સ કોઈ અલગ પ્રોસેસ પર પહોંચે તો સેટઅપ નિષ્ફળ થઈ શકે છે અથવા મીડિયા અવરોધાઈ શકે છે.

એથી અમને એક ચોક્કસ લક્ષ્યાંક મળ્યું: જાહેર ઇન્ટરનેટ પર નાની, નિશ્ચિત યુડીપી સપાટી એક્સપોઝ કરવી, અને દરેક પેકેટને સંબંધિત વેબઆરટીસી સેશન ધરાવતા ટ્રાન્સસીવર સુધી રૂટ કરવું.

અમે ત્યાં પહોંચવાના અનેક માર્ગોનું મૂલ્યાંકન કર્યું, જેમાં ટર્ન (ટ્રાવેરસલ યુઝીંગ રિલેઝ અરાઉન્ડ એનએટી) સામેલ છે, જ્યાં એજ રિલે ક્લાયન્ટ ફાળવણીઓને ટર્મિનેટ કરે છે અને તેમના વતી ટ્રાફિક ફોરવર્ડ કરે છે.²

અમે શિપ કરેલું આર્કિટેક્ચર પેકેટ રાઉટિંગને પ્રોટોકોલ ટર્મિનેશનથી અલગ કરે છે. સેશન સેટઅપ માટે સિગ્નલિંગ હજુ પણ ટ્રાન્સસીવર સુધી પહોંચે છે કે જ્યારે મીડિયા પહેલા રિલે મારફતે પ્રવેશે છે. રિલે એ નાની જાહેર ફૂટપ્રિન્ટ ધરાવતું હળવું યુડીપી ફોરવર્ડિંગ લેયર છે, અને ટ્રાન્સસીવર તેની પાછળનો સ્ટેટફુલ વેબઆરટીસી એન્ડપોઇન્ટ છે.

રિલે મીડિયા ડિક્રિપ્ટ કરતું નથી, આઈસીઈ સ્ટેટ મશીનો ચલાવતું નથી કે કોડેક વાટાઘાટમાં ભાગ લેતું નથી. તે નિયત સ્થાન પસંદ કરવા માટે પૂરતું પેકેટ મેટાડેટા વાંચે છે, ત્યાર પછી પેકેટને તે ટ્રાન્સસીવર તરફ ફોરવર્ડ કરે છે જે સત્રનો માલિક છે. ટ્રાન્સસીવર હજુ પણ સામાન્ય વેબઆરટીસી ફ્લો જુએ છે અને હજી પણ તમામ પ્રોટોકોલ સ્થિતિની માલિકી ધરાવે છે. ક્લાયન્ટના દૃષ્ટિકોણથી વેબઆરટીસી સત્રમાં કોઈ ફેરફાર થતો નથી.

આ સેટઅપમાં ફર્સ્ટ-પેકેટ રાઉટિંગ મુખ્ય પગલું છે. રિલેએ ક્લાયન્ટનું પ્રથમ પેકેટ કોઈપણ સત્ર અસ્તિત્વમાં આવે તે પહેલાં, બાહ્ય લુકઅપ સેવા પર અટકવાને બદલે પેકેટ પાથ પર જ રૂટ કરવું પડે છે.

દરેક વેબઆરટીસી સેશનમાં પહેલેથી જ પ્રોટોકોલમાં જ રહેલો એક રૂટિંગ હૂક હોય છે: આઈસીઈ યુઝરનેમ ફ્રેગમેન્ટ અથવા ufrag. આ સેશન સેટઅપ દરમિયાન આદાન-પ્રદાન થતું અને એસટીયુએન કનેક્ટિવિટી ચેક્સ દરમિયાન ફરીથી આવતું એક ટૂંકું ઓળખક છે. અમે સર્વર-સાઇડ યુફ્રંગ જનરેટ કરીએ છીએ જેથી તેમાં રિલે માટે નિર્ધારિત ક્લસ્ટર અને માલિક ટ્રાન્સસીવરનું અનુમાન કરવા માટે માત્ર એટલો જ પૂરતો રૂટિંગ મેટાડેટા હોય.

સિગ્નલિંગ દરમિયાન, ટ્રાન્સસીવર સેશન સ્ટેટ ફાળવે છે અને એસડીપી જવાબમાં શેર કરેલ રિલે વીઆઈપી અને યુડીપી પોર્ટ પરત કરે છે. વીઆઈપી એ રિલે ફ્લીટની આગળ રહેલું વર્ચ્યુઅલ આઈપી સરનામું છે; પોર્ટ સાથે જોડાય ત્યારે, તે ક્લાયન્ટને `203.0.113.10:3478` જેવું એક જ સ્થિર ગંતવ્ય આપે છે, ભલે તેની પાછળ ઘણા રિલે ઈન્સ્ટન્સ હોય. ક્લાયન્ટનું પ્રથમ મીડિયા-પાથ પેકેટ સામાન્ય રીતે એસટીયુએન (સેશન ટ્રાવર્સલ યુટીલિટીઝ ફોર એનએટી) બાઇન્ડિંગ વિનંતી હોય છે, જેનો ઉપયોગ આઈસીઈ એ ચકાસવા માટે કરે છે કે પેકેટ્સ જાહેર કરેલા સરનામે પહોંચી શકે છે.

રિલે તે પ્રથમ એસટીયુએન પેકેટમાંથી સર્વર યુફ્રંગ વાંચવા, રૂટિંગ સંકેત ડિકોડ કરવા અને પેકેટને માલિકી ધરાવતા ટ્રાન્સસીવર સુધી ફોરવર્ડ કરવા માટે જરૂરી હોય એટલું જ પાર્સ કરે છે. દરેક ટ્રાન્સસીવર શેર કરેલા યુડીપી સોકેટ પર સાંભળે છે, અર્થાત્ આંતરિક આઈપી:પોર્ટ સાથે બંધાયેલ એક ઓપરેટિંગ સિસ્ટમ એન્ડપોઇન્ટ, દરેક સત્ર માટે એક સોકેટ નહીં. રિલે ક્લાયન્ટના સ્રોત આઈપી:પોર્ટ માંથી તે ટ્રાન્સસીવર ગંતવ્ય સુધી સેશન બનાવે પછી, અનુગામી ડીટીએલએસ, આરટીપી અને આરટીસીપી પેકેટ્સ યુફ્રંગ ને ફરીથી ડીકોડ કર્યા વિના સેશનની અંદર વહે છે.

રિલેનું સેશન ઇરાદાપૂર્વક ન્યૂનતમ રાખવામાં આવ્યું છે, જેમાં પેકેટ ફોરવર્ડિંગ માટે માહિતી પૂરી પાડવા ફક્ત ઇન-મેમરી સેશન હોય છે, આ સાથે મોનિટરિંગ માટે જરૂરી કાઉન્ટર્સ અને સેશનની સમાપ્તિ તથા ક્લીનઅપ માટે ટાઈમર્સ હોય છે. આ ડિઝાઇન પસંદગી પેકેટ રૂટિંગને સીધું પેકેટ પાથ પર જાળવી રાખે છે. જો રિલે ફરી શરૂ થાય અને સત્ર ગુમાવે તો આગળનું સ્ટર્ન પેકેટ યુફ્રંગ રાઉટિંગ સંકેત પરથી સત્રને ફરીથી બનાવે છે. તેને વધુ વિશ્વસનીય બનાવવા માટે, રૂટ સ્થાપિત થયા પછી <ક્લાયન્ટ આઈપી + પોર્ટ, ટ્રાન્સસીવર આઈપી + પોર્ટ> ના મેપિંગને રાખવા માટે રેડિસ કૅશનો ઉપયોગ કરવામાં આવે છે, જેથી આગામી સ્ટર્ન પૅકેટ આવે તે પહેલાં તેને ઘણું વહેલું પુનઃપ્રાપ્ત કરી શકાય.

એકવાર અમે જાહેર યુડીપી સપાટીને સ્થિર સરનામા અને પોર્ટ્સની નાની સંખ્યા સુધી સીમિત કરી ત્યારબાદ અમે એ જ રિલે પેટર્નને વૈશ્વિક સ્તરે ગોઠવણ કરી શક્યા છીએ. ગ્લોબલ રિલે એ અમારા ભૂગોળીય રીતે વિતરિત રિલે પ્રવેશ બિંદુનો સમૂહ છે કે જે તમામ સમાન પેકેટ-ફોરવર્ડિંગ વર્તન અમલમાં મૂકે છે.

વ્યાપક ભૌગોલિક ઇન્ગ્રેસ પ્રથમ ક્લાયન્ટ-થી-OpenAI હોપને ટૂંકાવે છે કારણ કે પૅકેટ પહેલા દૂરના પ્રદેશ સુધી જાહેર ઇન્ટરનેટ પાર કરવાની બદલે ભૂગોળ અને નેટવર્ક ટોપોલોજી બંનેની દૃષ્ટિએ વપરાશકર્તાની નજીક આવેલા રિલે પર અમારા નેટવર્કમાં પ્રવેશી શકે છે. વ્યવહારિક રીતે જોઈએ તો તેનો અર્થ એ થાય છે કે ટ્રાફિક અમારા બેકબોન સુધી પહોંચે તે અગાઉ ઓછી લેટન્સી, ઓછું જિટર અને ટાળી શકાય તેવા લોસ બર્સ્ટ્સની સંખ્યા ઓછી હોય છે.⁶

અમે સિગ્નલિંગ માટે ક્લાઉડફ્લેર જિયો અને પ્રોક્સિમિટી સ્ટિયરિંગનો ઉપયોગ કરીએ છીએ જેથી પ્રારંભિક એચટીટીપી અથવા વેબસોકેટ વિનંતી નજીકના ટ્રાન્સસીવર ક્લસ્ટર સુધી પહોંચે. વિનંતિનો સંદર્ભ સત્રનું સ્થાન અને ક્લાયન્ટને કયો ગ્લોબલ રિલે ઈન્ગ્રેસ પોઇન્ટ જાહેર કરવામાં આવે છે તે નિર્ધારિત કરે છે. એસડીપી જવાબ ગ્લોબલ રિલે સરનામું પ્રદાન કરે છે કે જ્યારે યુફ્રંગમાં ગ્લોબલ રિલે માટે મીડિયાને નિર્ધારિત ક્લસ્ટર સુધી રૂટ કરવા અને રિલે માટે ગંતવ્ય ટ્રાન્સસીવર સુધી રૂટ કરવા માટે પૂરતી માહિતી હોય છે.

સાથે મળી જિયો-સ્ટીયર્ડ સિગ્નલિંગ અને ગ્લોબલ રિલે, સત્રને એક જ ટ્રાન્સસીવર સાથે એન્કર રાખીને સેટઅપ અને મીડિયા બંનેને નજીકના પ્રવેશ માર્ગ પર રાખે છે. તે સિગ્નલિંગ માટે અને પ્રથમ આઈસીઈ કનેક્ટિવિટી ચેક માટેનો રાઉન્ડ-ટ્રિપ સમય ઘટાડે છે કે જેના કારણે વાણી શરૂ થઈ શકે તે પહેલાં વપરાશકર્તાને કરવી પડતી રાહ સીધી રીતે ઓછી થાય છે.

અમે રિલે સેવા ગોમાં લખી અને અમલીકરણનો વ્યાપ જાણબૂઝીને મર્યાદિત રાખ્યો. લીનક્સ પર, કર્નલનો નેટવર્કિંગ સ્ટેક મશીનના નેટવર્ક ઇન્ટરફેસમાંથી યુડીપી પેકેટ્સ પ્રાપ્ત કરે છે અને તેમને સોકેટ સુધી પહોંચાડે છે—એ સોકેટ ઓપરેટિંગ સિસ્ટમનો એન્ડપોઇન્ટ છે, જેમાંથી કોઈ પ્રોસેસઆઈપી:પોર્ટ બાઇન્ડ કર્યા પછી વાંચે છે. રિલે યુઝરસ્પેસ માં ચાલે છે, તેથી એક સામાન્ય ગો પ્રોસેસ સોકેટમાંથી પેકેટ હેડર્સ વાંચે છે, ફ્લો સ્ટેટના થોડા પ્રમાણ અપડેટ કરે છે અને વેબઆરટીસીને સમાપ્ત કર્યા વગર પેકેટ્સ આગળ મોકલે છે. અમને કોઈપણ કર્નલ-બાયપાસ ફ્રેમવર્કની જરૂર પડી ન હતી કેજે યુઝરસ્પેસ પ્રોસેસને વધુ ઊંચા પેકેટ દરો માટે નેટવર્ક ક્યુઝને સીધા પોલ કરવાની મંજૂરી આપત, પરંતુ ઓપરેશનલ જટિલતા પણ ઉમેરત.

ડિઝાઈનની મુખ્ય પસંદગી:

• કોઈ પ્રોટોકોલ ટર્મિનેશન નથી: રિલે ફક્ત એસટીયુએન હેડર્સ/યુફ્રેગને પાર્સ કરે છે; તે પછીના ડીટીએલએસ, આરટીપી અને આરટીસીપી માટે કેશ્ડ સ્થિતિનો ઉપયોગ કરે છે, જેથી પેકેટ્સ અપારદર્શક રહે છે.
• અસ્થાયી સ્ટેટ: ફ્લો સ્ટેટ અને અવલોકનક્ષમતા માટે તે ક્લાયન્ટ સરનામાંથી ટ્રાન્સસીવર ગંતવ્ય સુધીનો નાનો, ટૂંકા-ટાઇમ આઉટવાળો, ઈન-મેમરી મેપ જાળવે છે.
• હોરિઝોન્ટલ સ્કેલેબિલિટી: બહુવિધ રિલે ઈન્સ્ટન્સ લોડ બેલેન્સરની પાછળ સમાંતર રીતે ચાલુ રહે છે. સ્ટેટ હાર્ડ વેબઆરટીસી સ્ટેટ નથી, તેથી રીસ્ટાર્ટ્સથી ન્યૂનતમ ટ્રાફિક ડ્રોપ્સ થાય છે અને ફ્લો ઝડપથી પુનઃપ્રાપ્ત થાય છે.

કાર્યક્ષમતા ઉપાયો:

• SO_REUSEPORT એ લીનક્સ સોકેટ વિકલ્પ છે જે એક જ મશીન પરના અનેક રિલે વર્કર્સને એ યુડીપી પોર્ટ સાથે બાઇન્ડ કરવાની મંજૂરી આપે છે. પછી કર્નલ આવતાં પેકેટ્સને તે વર્કર્સમાં વિતરિત કરે છે, જેના કારણે એક જ રીડ-લૂપનો અવરોધને ટળે છે.
• runtime.LockOSThread દરેક યુડીપી વાંચતી ગોરોટીન ને ચોક્કસ ઓએસ થ્રીડ સાથે બાંધી રાખે છે. SO_REUSEPORT સાથે સંયોજિત હોય ત્યારે તે એક જ ફ્લોના પૅકેટ્સને (સ્રોત અને ગંતવ્ય આઈપી:પોર્ટ સાથે પ્રોટોકોલ) એ જ યુપીયુ કોર પર રાખવાની વૃત્તિ ધરાવે છે, જેના કારણે કૅશ લોકાલિટી સુધરે છે અને કોન્ટેક્સ્ટ સ્વિચિંગ ઘટે છે.
• પૂર્વ-ફાળવેલા બફર્સ અને ન્યૂનતમ કૉપીંગ પાર્સિંગ અને ફાળવણીના ઓવરહેડને ઓછો રાખે છે કે જેથી ગો માં ગાર્બેજ કલેક્શન ટાળી શકાય છે.

આ અમલીકરણે અમારા વૈશ્વિક રીઅલ-ટાઇમ મીડિયા ટ્રાફિકને તુલનાત્મક રીતે નાના રિલે ફૂટપ્રિન્ટ સાથે સંભાળ્યો, તેથી અમે કર્નલ બાયપાસ રૂટ અપનાવવાને બદલે વધારે સરળ ડિઝાઈન જાળવી રાખી.

આ આર્કિટેક્ચર અમને હજારો યુડીપી પોર્ટ્સને ખુલ્લા કર્યા વગર કુબેરનેટ્સમાં વેબઆરટીસી મીડિયા ચલાવવાની મંજૂરી આપે છે. તે મહત્વનું છે કારણ કે નાનું અને સ્થિર યુડીપી સર્ફેસ સુરક્ષિત કરવું અને લોડ બેલેન્સ કરવું વધુ સરળ હોય છે અને તે ઇન્ફ્રાસ્ટ્રક્ચરને મોટા જાહેર પોર્ટ રેન્જીસ અનામત રાખ્યા વિના વિસ્તરવા દે છે. કુબેરનેટ્સ તરફથી મળતા વધુ સારા ઇન્ફ્રા સપોર્ટ અને નાના એટેક સરફેસ એરિયાને કારણે વધુ સુરક્ષા સાથે, આ ડિઝાઇન ક્લાયન્ટ્સ માટેનું સ્ટાન્ડર્ડ વેબઆરટીસી વર્તન પણ જાળવી રાખે છે અને પુષ્ટિ કરે છે કે અમારા વર્કલોડ માટે એસએફયુ વિનાની ડિઝાઈન યોગ્ય ડિફૉલ્ટ હતી. અમારા મોટાભાગના સત્રો પોઇન્ટ-ટુ-પોઇન્ટ, લેટન્સી-સંવેદનશીલ હોય છે, અને જ્યારે ઇન્ફરન્સ સેવાઓને વેબઆરટીસી પીઅર્સની જેમ વર્તવાની જરૂર ન હોય ત્યારે તેમને સ્કેલ કરવું વધુ સરળ હોય છે.

વ્યાપક પાઠ એ છે કે જટિલતા ઉમેરવા માટેનું શ્રેષ્ઠ સ્થાન દરેક બેકએન્ડ સર્વિસમાં કે કસ્ટમ ક્લાયન્ટ વર્તનમાં નહીં, પરંતુ પાતળા રૂટિંગ લેયરમાં છે. રૂટિંગ મેટાડેટાને પ્રોટોકોલ-નેટિવ ફીલ્ડમાં એન્કોડ કરવાથી અમને નિર્ધારિત ફર્સ્ટ-પૅકેટ રૂટિંગ, નાનું જાહેર યુડીપી ફૂટપ્રિન્ટ અને વિશ્વભરના યુઝર્સની નજીક ઇન્ગ્રેસ મૂકવા માટે પૂરતી લવચીકતા મળી છે.

કેટલીક પસંદગી ખાસ કરીને મહત્વની હતી:

• એજ પર પ્રોટોકોલના સેમેન્ટિક્સ જાળવી રાખો. ક્લાયન્ટ્સ હજુ પણ પ્રમાણભૂત વેબઆરટીસીનો ઉપયોગ કરે છે, જેના કારણે બ્રાઉઝર અને મોબાઇલ ઇન્ટરઓપરેબિલિટી અકબંધ રહે છે.
• હાર્ડ સેશન સ્ટેટ્સને એક જ જગ્યાએ રાખો. ટ્રાન્સસીવર આઈસીઈ, ડીટીએલએસ, એસઆરટીપી અને સત્ર લાઇફસાઇકલ સંભાળે છે; રિલે ફક્ત પેકેટ્સ આગળ મોકલે છે.
• સેટઅપમાં પહેલેથી જ હાજર માહિતીના આધારે રૂટ કરો. આઈસીઈ યુફ્રેગ એ હોટ-પાથ લુકઅપ નિર્ભરતા ઉમેર્યા વગર અમને પ્રથમ-પેકેટ રૂટિંગ હૂક આપ્યો.
• કર્નલ બાયપાસનો આશરો લઈને પહેલાં સામાન્ય કેસ માટે ઑપ્ટિમાઇઝ કરો. SO_REUSEPORT નો સાવચેતીપૂર્વક ઉપયોગ, થ્રેડ પિનિંગ અને ઓછી ફાળવણીવાળું પાર્સિંગ ધરાવતું મર્યાદિત ગો અમલીકરણ અમારા વર્કલોડ માટે પૂરતું હતું.

રીઅલ-ટાઇમ વૉઈસ AI ફક્ત ત્યારે જ કાર્યક્ષમ બને છે કે જ્યારે ઈન્ફ્રાસ્ટ્રક્ચર લેટન્સી અદ્રશ્ય લાગે છે. અમારા માટે તેનો અર્થ એ હતો કે ક્લાયન્ટ્સ વેબઆરટીસી પાસેથી જે અપેક્ષા રાખે છે તેમાં ફેરફાર કર્યા વગર અમારા વેબઆરટીસી ડિપ્લોયમેન્ટના સ્વરૂપમાં ફેરફાર કરવો.