પરિચય

અમારી કંપની લીનિંગ ટેક્નોલોજીસ પરંપરાગત ડેસ્કટોપ એપ્લિકેશન્સને વેબ પર પોર્ટ કરવા માટે ઉકેલો પૂરા પાડે છે. અમારું C++ કમ્પાઇલર ખુશખુશાલ WebAssembly અને JavaScriptનું સંયોજન જનરેટ કરે છે, જે બંને પ્રદાન કરે છે સરળ બ્રાઉઝર ક્રિયાપ્રતિક્રિયા, અને ઉચ્ચ પ્રદર્શન.

તેની એપ્લિકેશનના ઉદાહરણ તરીકે, અમે મલ્ટિપ્લેયર ગેમને વેબ પર પોર્ટ કરવાનું નક્કી કર્યું અને પસંદ કર્યું Teeworlds. Teeworlds એ એક મલ્ટિપ્લેયર XNUMXD રેટ્રો ગેમ છે જેમાં ખેલાડીઓના નાના પરંતુ સક્રિય સમુદાય (મારા સહિત!) છે. ડાઉનલોડ કરેલ સંસાધનો અને CPU અને GPU આવશ્યકતાઓ - એક આદર્શ ઉમેદવારની દ્રષ્ટિએ તે નાનું છે.

Teeworlds બ્રાઉઝરમાં ચાલી રહ્યું છે

અમે પ્રયોગ કરવા માટે આ પ્રોજેક્ટનો ઉપયોગ કરવાનું નક્કી કર્યું નેટવર્ક કોડને વેબ પર પોર્ટ કરવા માટેના સામાન્ય ઉકેલો. આ સામાન્ય રીતે નીચેની રીતે કરવામાં આવે છે:

• XMLHttpRequest/fetch, જો નેટવર્ક ભાગમાં ફક્ત HTTP વિનંતીઓનો સમાવેશ થાય છે, અથવા
• વેબસોકેટ્સ.

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

ત્રીજી રીત છે - બ્રાઉઝરમાંથી નેટવર્કનો ઉપયોગ કરો: WebRTC.

RTCDataChannel તે વિશ્વસનીય અને અવિશ્વસનીય ટ્રાન્સમિશન બંનેને સપોર્ટ કરે છે (પછીના કિસ્સામાં જ્યારે પણ શક્ય હોય ત્યારે તે પરિવહન પ્રોટોકોલ તરીકે UDPનો ઉપયોગ કરવાનો પ્રયાસ કરે છે), અને રિમોટ સર્વર સાથે અને બ્રાઉઝર્સ વચ્ચે બંનેનો ઉપયોગ કરી શકાય છે. આનો અર્થ એ છે કે અમે સર્વર ઘટક સહિત સમગ્ર એપ્લિકેશનને બ્રાઉઝરમાં પોર્ટ કરી શકીએ છીએ!

જો કે, આ એક વધારાની મુશ્કેલી સાથે આવે છે: બે WebRTC સાથીદારો વાતચીત કરી શકે તે પહેલાં, તેઓએ કનેક્ટ થવા માટે પ્રમાણમાં જટિલ હેન્ડશેક કરવાની જરૂર છે, જેમાં ઘણી તૃતીય-પક્ષ સંસ્થાઓ (એક સિગ્નલિંગ સર્વર અને એક અથવા વધુ સર્વર્સ) જરૂરી છે. STUN/ટર્ન).

આદર્શરીતે, અમે એક નેટવર્ક API બનાવવા માંગીએ છીએ જે આંતરિક રીતે WebRTC નો ઉપયોગ કરે છે, પરંતુ UDP સોકેટ્સ ઇન્ટરફેસની શક્ય તેટલી નજીક છે જેને કનેક્શન સ્થાપિત કરવાની જરૂર નથી.

આનાથી અમને એપ્લિકેશન કોડ (જેને અમે અમારા પ્રોજેક્ટમાં શક્ય તેટલું ઓછું બદલવા માગીએ છીએ) પર જટિલ વિગતો દર્શાવ્યા વિના WebRTC નો લાભ લેવાની મંજૂરી આપશે.

ન્યૂનતમ WebRTC

WebRTC એ બ્રાઉઝર્સમાં ઉપલબ્ધ API નો સમૂહ છે જે ઑડિઓ, વિડિયો અને મનસ્વી ડેટાનું પીઅર-ટુ-પીઅર ટ્રાન્સમિશન પ્રદાન કરે છે.

ICE નામની મિકેનિઝમ દ્વારા STUN અને/અથવા ટર્ન સર્વર્સનો ઉપયોગ કરીને સાથીદારો વચ્ચે જોડાણ સ્થાપિત થાય છે (ભલે એક અથવા બંને બાજુએ NAT હોય). સાથીદારો SDP પ્રોટોકોલની ઓફર અને જવાબ દ્વારા ICE માહિતી અને ચેનલ પરિમાણોની આપલે કરે છે.

વાહ! એક સમયે કેટલા સંક્ષિપ્ત શબ્દો? ચાલો ટૂંકમાં સમજાવીએ કે આ શબ્દોનો અર્થ શું છે:

• NAT માટે સત્ર ટ્રાવર્સલ યુટિલિટીઝ (STUN) — NAT ને બાયપાસ કરવા અને હોસ્ટ સાથે સીધા ડેટાની આપલે કરવા માટે એક જોડી (IP, પોર્ટ) મેળવવા માટેનો પ્રોટોકોલ. જો તે તેનું કાર્ય પૂર્ણ કરવામાં મેનેજ કરે છે, તો પછી સાથીદારો સ્વતંત્ર રીતે એકબીજા સાથે ડેટાનું વિનિમય કરી શકે છે.
• NAT ની આસપાસ રિલેનો ઉપયોગ કરીને ટ્રાવર્સલ (ટર્ન) NAT ટ્રાવર્સલ માટે પણ ઉપયોગમાં લેવાય છે, પરંતુ તે પ્રોક્સી દ્વારા ડેટા ફોરવર્ડ કરીને તેનો અમલ કરે છે જે બંને સાથીદારોને દેખાય છે. તે લેટન્સી ઉમેરે છે અને STUN કરતાં અમલમાં મૂકવું વધુ ખર્ચાળ છે (કારણ કે તે સમગ્ર સંચાર સત્ર દરમિયાન લાગુ કરવામાં આવે છે), પરંતુ કેટલીકવાર તે એકમાત્ર વિકલ્પ હોય છે.
• ઇન્ટરેક્ટિવ કનેક્ટિવિટી એસ્ટાબ્લિશમેન્ટ (ICE) સાથીદારોને સીધા કનેક્ટ કરવાથી મેળવેલી માહિતી તેમજ કોઈપણ સંખ્યાબંધ STUN અને TURN સર્વર્સ દ્વારા પ્રાપ્ત માહિતીના આધારે બે પીઅરને કનેક્ટ કરવાની શ્રેષ્ઠ સંભવિત પદ્ધતિ પસંદ કરવા માટે વપરાય છે.
• સત્ર વર્ણન પ્રોટોકોલ (એસડીપી) કનેક્શન ચેનલ પેરામીટર્સનું વર્ણન કરવા માટેનું એક ફોર્મેટ છે, ઉદાહરણ તરીકે, ICE ઉમેદવારો, મલ્ટીમીડિયા કોડેક્સ (ઓડિયો/વિડિયો ચેનલના કિસ્સામાં), વગેરે... સાથીદારોમાંથી એક SDP ઑફર મોકલે છે, અને બીજો SDP જવાબ સાથે જવાબ આપે છે. . આ પછી, એક ચેનલ બનાવવામાં આવે છે.

આવું કનેક્શન બનાવવા માટે, સાથીઓએ STUN અને ટર્ન સર્વર્સમાંથી મેળવેલી માહિતી એકત્રિત કરવાની અને એકબીજા સાથે તેની આપલે કરવાની જરૂર છે.

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

સિગ્નલિંગ સર્વર ખૂબ જ સરળ હોઈ શકે છે કારણ કે તેનું એકમાત્ર કાર્ય હેન્ડશેક તબક્કામાં સાથીદારો વચ્ચે ડેટા ફોરવર્ડ કરવાનું છે (નીચેના ચિત્રમાં બતાવ્યા પ્રમાણે).

સરળ વેબઆરટીસી હેન્ડશેક સિક્વન્સ ડાયાગ્રામ

Teeworlds નેટવર્ક મોડલ વિહંગાવલોકન

Teeworlds નેટવર્ક આર્કિટેક્ચર ખૂબ જ સરળ છે:

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

ડેટા એક્સચેન્જ માટે WebRTC નો ઉપયોગ કરવા બદલ આભાર, અમે રમતના સર્વર ઘટકને તે બ્રાઉઝરમાં સ્થાનાંતરિત કરી શકીએ છીએ જ્યાં ક્લાયંટ સ્થિત છે. આ અમને એક મહાન તક આપે છે ...

સર્વરોથી છુટકારો મેળવો

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

જો કે, સિસ્ટમ કામ કરવા માટે, અમારે હજુ પણ બાહ્ય આર્કિટેક્ચરનો ઉપયોગ કરવો પડશે:

• એક અથવા વધુ STUN સર્વર્સ: અમારી પાસે પસંદગી માટે ઘણા મફત વિકલ્પો છે.
• ઓછામાં ઓછું એક ટર્ન સર્વર: અહીં કોઈ મફત વિકલ્પો નથી, તેથી અમે કાં તો આપણું પોતાનું સેટઅપ કરી શકીએ છીએ અથવા સેવા માટે ચૂકવણી કરી શકીએ છીએ. સદનસીબે, મોટાભાગે STUN સર્વર્સ દ્વારા કનેક્શન સ્થાપિત કરી શકાય છે (અને સાચું p2p પ્રદાન કરે છે), પરંતુ ફોલબેક વિકલ્પ તરીકે ટર્નની જરૂર છે.
• સિગ્નલિંગ સર્વર: અન્ય બે પાસાઓથી વિપરીત, સિગ્નલિંગ પ્રમાણિત નથી. સિગ્નલિંગ સર્વર ખરેખર શું માટે જવાબદાર હશે તે એપ્લિકેશન પર કંઈક અંશે આધાર રાખે છે. અમારા કિસ્સામાં, કનેક્શન સ્થાપિત કરતા પહેલા, થોડી માત્રામાં ડેટાનું વિનિમય કરવું જરૂરી છે.
• Teeworlds Master Server: તેનો ઉપયોગ અન્ય સર્વર્સ દ્વારા તેમના અસ્તિત્વની જાહેરાત કરવા અને ક્લાયન્ટ દ્વારા જાહેર સર્વર્સ શોધવા માટે કરવામાં આવે છે. જ્યારે તે જરૂરી નથી (ક્લાયન્ટ હંમેશા સર્વર સાથે કનેક્ટ થઈ શકે છે જેના વિશે તેઓ જાતે જાણે છે), તે સરસ રહેશે જેથી ખેલાડીઓ રેન્ડમ લોકો સાથે રમતોમાં ભાગ લઈ શકે.

અમે Google ના મફત STUN સર્વર્સનો ઉપયોગ કરવાનું નક્કી કર્યું, અને એક ટર્ન સર્વર જાતે ગોઠવ્યું.

છેલ્લા બે મુદ્દાઓ માટે અમે ઉપયોગ કર્યો ફાયરબેઝ:

• Teeworlds માસ્ટર સર્વર ખૂબ જ સરળ રીતે લાગુ કરવામાં આવ્યું છે: દરેક સક્રિય સર્વરની માહિતી (નામ, IP, નકશો, મોડ, ...) ધરાવતી વસ્તુઓની સૂચિ તરીકે. સર્વર્સ તેમના પોતાના ઑબ્જેક્ટને પ્રકાશિત કરે છે અને અપડેટ કરે છે, અને ક્લાયંટ આખી સૂચિ લે છે અને તેને પ્લેયર પર પ્રદર્શિત કરે છે. અમે હોમ પેજ પર એચટીએમએલ તરીકે સૂચિ પણ પ્રદર્શિત કરીએ છીએ જેથી ખેલાડીઓ સર્વર પર ક્લિક કરી શકે અને સીધા રમત પર લઈ જઈ શકે.
• સિગ્નલિંગ અમારા સોકેટ્સ અમલીકરણ સાથે ગાઢ રીતે સંબંધિત છે, જે આગળના વિભાગમાં વર્ણવેલ છે.

રમતની અંદર અને હોમ પેજ પર સર્વરની સૂચિ

સોકેટ્સનું અમલીકરણ

જરૂરી ફેરફારોની સંખ્યા ઘટાડવા માટે અમે એક API બનાવવા માંગીએ છીએ જે Posix UDP સોકેટ્સની શક્ય તેટલી નજીક હોય.

અમે નેટવર્ક પર સૌથી સરળ ડેટા એક્સચેન્જ માટે જરૂરી ન્યૂનતમને પણ અમલમાં મૂકવા માંગીએ છીએ.

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

તેથી, અમને અનન્ય IP સરનામાંની જરૂર નથી: અનન્ય ફાયરબેઝ કી મૂલ્યો (ડોમેન નામોની જેમ) સાથીદારોને અનન્ય રીતે ઓળખવા માટે પર્યાપ્ત છે, અને દરેક પીઅર સ્થાનિક રીતે દરેક કીને "નકલી" IP સરનામાં સોંપે છે જેનો અનુવાદ કરવાની જરૂર છે. આ વૈશ્વિક IP સરનામાં સોંપણીની જરૂરિયાતને સંપૂર્ણપણે દૂર કરે છે, જે એક બિન-તુચ્છ કાર્ય છે.

અમારે અમલ કરવા માટે જરૂરી ન્યૂનતમ API અહીં છે:

// Create and destroy a socket
int socket();
int close(int fd);
// Bind a socket to a port, and publish it on Firebase
int bind(int fd, AddrInfo* addr);
// Send a packet. This lazily create a WebRTC connection to the 
// peer when necessary
int sendto(int fd, uint8_t* buf, int len, const AddrInfo* addr);
// Receive the packets destined to this socket
int recvfrom(int fd, uint8_t* buf, int len, AddrInfo* addr);
// Be notified when new packets arrived
int recvCallback(Callback cb);
// Obtain a local ip address for this peer key
uint32_t resolve(client::String* key);
// Get the peer key for this ip
String* reverseResolve(uint32_t addr);
// Get the local peer key
String* local_key();
// Initialize the library with the given Firebase database and 
// WebRTc connection options
void init(client::FirebaseConfig* fb, client::RTCConfiguration* ice);

API સરળ અને પોસિક્સ સોકેટ્સ API જેવું જ છે, પરંતુ તેમાં કેટલાક મહત્વપૂર્ણ તફાવતો છે: કૉલબૅક્સ લૉગિંગ, સ્થાનિક IP સોંપવા, અને આળસુ કનેક્શન.

કૉલબૅક્સની નોંધણી કરી રહ્યાં છીએ

જો મૂળ પ્રોગ્રામ નોન-બ્લોકિંગ I/O નો ઉપયોગ કરે છે, તો પણ વેબ બ્રાઉઝરમાં ચલાવવા માટે કોડ રિફેક્ટેડ હોવો જોઈએ.

આનું કારણ એ છે કે બ્રાઉઝરમાં ઇવેન્ટ લૂપ પ્રોગ્રામથી છુપાયેલ છે (તે JavaScript અથવા WebAssembly હોય).

મૂળ વાતાવરણમાં આપણે આ રીતે કોડ લખી શકીએ છીએ

while(running) {
  select(...); // wait for I/O events
  while(true) {
    int r = readfrom(...); // try to read
    if (r < 0 && errno == EWOULDBLOCK) // no more data available
      break;
    ...
  }
  ...
}

જો ઇવેન્ટ લૂપ આપણા માટે છુપાયેલ છે, તો આપણે તેને કંઈક આના જેવું બનાવવાની જરૂર છે:

auto cb = []() { // this will be called when new data is available
  while(true) {
    int r = readfrom(...); // try to read
    if (r < 0 && errno == EWOULDBLOCK) // no more data available
      break;
    ...
  }
  ...
};
recvCallback(cb); // register the callback

સ્થાનિક IP સોંપણી

અમારા "નેટવર્ક" માં નોડ ID એ IP સરનામાં નથી, પરંતુ ફાયરબેઝ કી છે (તે આના જેવી સ્ટ્રીંગ્સ છે: -LmEC50PYZLCiCP-vqde ).

આ અનુકૂળ છે કારણ કે અમને IP ને સોંપવા અને તેમની વિશિષ્ટતા ચકાસવા માટે કોઈ પદ્ધતિની જરૂર નથી (તેમજ ક્લાયંટ ડિસ્કનેક્ટ થયા પછી તેનો નિકાલ કરવા માટે), પરંતુ સંખ્યાત્મક મૂલ્ય દ્વારા સાથીઓની ઓળખ કરવી ઘણી વખત જરૂરી છે.

આ બરાબર છે કે જે કાર્યો માટે વપરાય છે. resolve и reverseResolve: એપ્લિકેશન કોઈક રીતે કીની સ્ટ્રિંગ વેલ્યુ (વપરાશકર્તા ઇનપુટ દ્વારા અથવા માસ્ટર સર્વર દ્વારા) મેળવે છે અને તેને આંતરિક ઉપયોગ માટે IP એડ્રેસમાં કન્વર્ટ કરી શકે છે. બાકીના API પણ સરળતા માટે સ્ટ્રિંગને બદલે આ મૂલ્ય મેળવે છે.

આ DNS લુકઅપ જેવું જ છે, પરંતુ ક્લાયન્ટ પર સ્થાનિક રીતે કરવામાં આવે છે.

એટલે કે, IP એડ્રેસ અલગ-અલગ ક્લાયન્ટ્સ વચ્ચે શેર કરી શકાતા નથી, અને જો અમુક પ્રકારના વૈશ્વિક ઓળખકર્તાની જરૂર હોય, તો તેને અલગ રીતે જનરેટ કરવું પડશે.

આળસુ જોડાણ

UDP ને કનેક્શનની જરૂર નથી, પરંતુ જેમ આપણે જોયું તેમ, WebRTC એ બે સાથીદારો વચ્ચે ડેટા ટ્રાન્સફર કરવાનું શરૂ કરે તે પહેલાં તેને લાંબી કનેક્શન પ્રક્રિયાની જરૂર છે.

જો આપણે એબ્સ્ટ્રેક્શનનું સમાન સ્તર પ્રદાન કરવા માંગીએ છીએ, (sendto/recvfrom અગાઉના જોડાણ વિના મનસ્વી સાથીદારો સાથે), પછી તેઓએ API ની અંદર "આળસુ" (વિલંબિત) જોડાણ કરવું આવશ્યક છે.

UDP નો ઉપયોગ કરતી વખતે "સર્વર" અને "ક્લાયન્ટ" વચ્ચે સામાન્ય સંચાર દરમિયાન આવું થાય છે અને અમારી લાઇબ્રેરીએ શું કરવું જોઈએ:

• સર્વર કૉલ્સ bind()ઓપરેટિંગ સિસ્ટમને જણાવવા માટે કે તે નિર્દિષ્ટ પોર્ટ પર પેકેટો પ્રાપ્ત કરવા માંગે છે.

તેના બદલે, અમે સર્વર કી હેઠળ ફાયરબેઝ પર ઓપન પોર્ટ પ્રકાશિત કરીશું અને તેના સબટ્રીમાં ઇવેન્ટ્સ સાંભળીશું.

• સર્વર કૉલ્સ recvfrom(), આ પોર્ટ પર કોઈપણ હોસ્ટ તરફથી આવતા પેકેટો સ્વીકારવા.

અમારા કિસ્સામાં, અમારે આ પોર્ટ પર મોકલવામાં આવેલા પેકેટોની ઇનકમિંગ કતાર તપાસવાની જરૂર છે.

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

કૉલ બિન-બ્લોકિંગ છે, તેથી જો ત્યાં કોઈ પેકેટો ન હોય, તો અમે ફક્ત -1 પરત કરીએ છીએ અને સેટ કરીએ છીએ errno=EWOULDBLOCK.

• ક્લાયંટ કેટલાક બાહ્ય માધ્યમો દ્વારા સર્વરનો IP અને પોર્ટ મેળવે છે અને કૉલ્સ કરે છે sendto(). આ આંતરિક કોલ પણ કરે છે. bind(), તેથી અનુગામી recvfrom() સ્પષ્ટપણે બાંધ્યા વગર પ્રતિસાદ પ્રાપ્ત કરશે.

અમારા કિસ્સામાં, ક્લાયંટ બાહ્ય રીતે સ્ટ્રિંગ કી મેળવે છે અને ફંક્શનનો ઉપયોગ કરે છે resolve() IP સરનામું મેળવવા માટે.

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

અમે આડકતરી કામગીરી પણ કરીએ છીએ bind()જેથી સર્વર આગામી સમયમાં ફરીથી કનેક્ટ થઈ શકે sendto() જો તે કોઈ કારણોસર બંધ થઈ જાય.

જ્યારે ક્લાયન્ટ ફાયરબેઝમાં સર્વર પોર્ટ માહિતી હેઠળ તેની SDP ઑફર લખે છે ત્યારે સર્વરને ક્લાયંટના કનેક્શનની જાણ કરવામાં આવે છે અને સર્વર ત્યાં તેના પ્રતિસાદ સાથે પ્રતિસાદ આપે છે.

નીચેનો આકૃતિ સોકેટ સ્કીમ માટે સંદેશ પ્રવાહ અને ક્લાયંટથી સર્વર પર પ્રથમ સંદેશના ટ્રાન્સમિશનનું ઉદાહરણ બતાવે છે:

ક્લાયંટ અને સર્વર વચ્ચેના જોડાણના તબક્કાનો સંપૂર્ણ ડાયાગ્રામ

નિષ્કર્ષ

જો તમે આટલું વાંચ્યું હોય, તો તમને કદાચ સિદ્ધાંતને ક્રિયામાં જોવામાં રસ હશે. પર રમત રમી શકાય છે teeworlds.leaningtech.com, તેનો પ્રયાસ કરો!

સાથીદારો વચ્ચે મૈત્રીપૂર્ણ મેચ

નેટવર્ક લાઇબ્રેરી કોડ મફતમાં ઉપલબ્ધ છે Github. પર અમારી ચેનલ પર વાતચીતમાં જોડાઓ જીટર!

સોર્સ: www.habr.com