poate sa imi zica cineva si mie o solutie pentru reliable UDP packet transmission. Am inteles ca trebuie sa trimit ACK, dar cand si cum ? in fiecare packet sa am un (last) ACK number ? sau sa trimit packets cu ACKs, etc. As dori un mic workflow explanation, care ati facut si va merge, thanks.

(sau macar niste C sample code de pe undeva, ceva simplu ca sa inteleg)

A... vezi in Epic Pong? :>

Fiecare pachet are un sequence number. Inainte sa pui un pachet pe sirma, ii dai urmatorul sequence number si-l bagi intr-o coada de retransmitere, ca sa ai de unde sa-l retrimiti daca se pierde.

Fiecare parte tine minte urmatorul sequence number pe care-l asteapta de la peer. Daca vine un pachet cu un sequence number mai mare decit ce te astepti, il ignori cu totul. Daca vine ce te astepti sau mai mic, trimiti inapoi un pachet cu un cod special, numit de obicei ACK, in care pui sequence number-ul pachetului primit. In felul asta ii semnalezi peer-ului ca ai auzit ce-a zis. Nu procesezi mai departe decit pachetele cu secventa la care te astepti, adica le ignori p-alea cu secventa mai mica, deoarece le-ai procesat deja. Evident, ACK-urile nu se pun in coada de retransmit si nu trimiti ACK-uri pentru ACK-uri. Cind primesti un ACK, scoti din coada de retransmit pachetul cu secventa respectiva.

In fiecare frame verifici elementele din coada de retransmit (pina la o limita, de exemplu primele 3), care au un timestamp. Daca dai de pachete pentru care au trecut mai mult de X milisecunde de la ultimul retransmit, le pui din nou pe fir, ca probabil s-au pierdut.

In felul asta asiguri ca e reliable si ordered. Functioneaza corect in orice scenariu imaginabil, de exemplu:

- daca se pierde pachetul X, dar pachetul X+1 este trimis la scurt timp dupa si ajunge, X+1 va fi ignorat pentru ca peer-ul asteapta secventa X. Dupa un timp vei retrimite X si cind va ajunge in sfirsit, vei primi ACK pentru el. Dupa aia vei observa ca n-ai primit ACK pentru X+1 (d-aia e important sa nu trimiti ACK-uri pentru secvente mai mari decit te astepti), si vei retransmite si X+1. Pina la urma vor ajunge toate, si in ordinea corecta.

- daca se pierde un ACK, pachetul va fi retransmis. Peer-ul a procesat deja pachetul de prima data si a incrementat sequence number-ul la care se asteapta, deci nu-l va procesa si a doua oara. Totusi, deoarece am zis ca ACK-urile se trimit pentru secvente mai mici sau egale decit cea asteptata, se va retransmite ACK-ul. Pina la urma va ajunge si comunicarea va continua.

Poti acumula pachete undeva cind au secventa mai mare decit cea asteptata si sa reordonezi pe-acolo (in loc sa le ignori complet), dar devine mai complicat. Iti poate reduce traficul in conditii de packet loss mare, dar in general nu merita.

Timpul de retransmit trebuie sa fie mai mare decit lag-ul, altfel vei face retransmit in prostie. E bine sa-l faci adaptiv, adica sa masori lag-ul curent si sa pui retransmit-ul putin peste cit estimezi ca ai lag. Asta e foarte agresiv si va genera o groaza de trafic suplimentar pe conexiuni instabile, dar depinde si ce vrei sa faci - pentru un shooter (sau pong) e OK. Daca faci asta e bine sa pui si o limita inferioara pentru timpul de retransmit, ca oricum n-are rost sa fie mai mic de citeva frame-uri, adica 30-50 de milisecunde.

TCP isi dubleaza timpul de retransmit la fiecare attempt (si are un decay pe-acolo pentru pachete reusite), ceea ce e foarte bine pentru downloadat porn pe dialup, dar e foarte nasol pentru jocuri twitch. Scopul TCP-ului e sa maximizeze throughput-ul si sa fie stabil pe conexiuni dubioase, pe cind scopul unui joc este sa minimizeze latenta. D-aia nu e recomandat sa faci scalari d-astea, ca daca dai de un spike solitar in conexiune vrei sa te recuperezi cit mai rapid posibil, iar daca nu e un spike ci intr-adevar o conexiune proasta oricum nu vei putea sa te joci pe ea.

Poti sa mai faci diverse trick-uri, cum ar fi sa comasezi pachetele din coada de retransmit si sa le dai pe toate de-odata cind le vine rindul (pina la MTU, ca mai mult nu duce UDP-ul), dar e discutabil daca asta va aduce beneficii reale in general. E bine pentru MMO-uri pe dial-up, e useless pentru shootere pe DSL. Alta chestie care poate fi imprumutata de la TCP e windowing, adica sa nu pui un pachet pe fir decit daca in coada de retransmit sint maxim N pachete, dar din nou beneficiile sint mici daca conexiunea e buna in general (adica daca jocul are nevoie de o conexiune buna in general).

Daca vrei, poti sa pui o limita maxima de retransmit-uri sau o lungime maxima a cozii de retransmit si cind una din ele este depasita sa zici "connection lost".

Principiile sint simple si logice, dar ca de obicei "the devil is in the details". Dureaza mai mult sa pilesti timpul de retransmit si sa te prinzi de interactiunile teribil de dubioase intre VSync si lag decit sa scrii codul propriu-zis.

Hm. UDP e prin definitie unreliable. ACK e un termen care tine de infrastructura network protocolului, sper ca nu te apuci sa il rescrii.

Daca te referi la a folosi un compromis dintre incredere(reliability) si viteza cu care primesti datele, respectiv ai de rezolvat o problema ce necesita date realtime si nu isi permite worst case scenario al TCP de zeci de secunde pt. obtinerea datelor, atunci trebuie sa iti faci tu un fel de handshake bazat pe packete UDP rezistent la problemele esentiale UDP: pachete lipsa si pachete venind out-of-order. Insa depinde f. mult de ce vrei sa obtii.

Nu poti sa faci un compromis la reliability, ca "aproximativ reliable" e tot aia cu "unreliable". Trebuie sa faci un protocol peste UDP care sa fie optimizat pentru latenta si sa fie reliable. Depinde doar intr-o anumita masura de ce vrei sa faci, dar ideea e tot timpul la fel si e implementata in aproape toate jocurile multiplayer (mai putin MMO-uri, unde TCP e considerat acceptabil in general). In functie de situatie pilesti la parametrii aia de retransmit si la unele feature-uri, da' partea cu trimis ACK pentru pachete e tot timpul la fel.

Da pot sa adaug doar ca folosesc o implementare asemanatoare cu ce a descris Dark (cea cu o coada care pastreaza pachetele cu id mai mare decat cel asteptat si le proceseaza doar cand au fost procesate toate cele dinaintea lor). Si pare sa functioneze perfect.

Da, evident ca nu mai e complet de incredere. Idea era ca algoritmul se poate optimiza pt. diverse situatii. De ex., pt. jocuri de tip FPS, packetele de pozitie/orientare/etc care nu ajung in timp util pentru ceasul intern al jocului pot fi aruncate direct din stadiul acesta, pentru a evita procesarea lor inutila (I smell a roasting din cauza ca nu e kosher sa combini nivelele de abstractie ). In plus e periculos sa denumesti packetul "ACK" fara calificarea "packet UDP cu mesaj ACK" intrucat te poti trezi ca cineva incearca sa reinventeze TCP-ul.

Btw, cum se traduce corect "reliable" in romana? Ca nu gasesc cuvinte care sa contina sensul complet din engleza.

Pai da, aia nu e treaba partii low-level care se ocupa de retransmit. FPS-urile au doua canale, unul reliable pe care trimit hit-uri, chat-uri etc. si unul unreliable, pe care trimit pozitii si orientari. Ce se duce pe care canal se stabileste mai sus in logica, nu in protocolul de dedesubt.



P-asta n-am inteles-o. Intr-o anumita masura incerci sa reinventezi TCP-ul, doar ca ai alte criterii de design in cap.



"Sigur" sau "garantat"?

Pai ideea e sa trimiti unreliable tot ce nu este foarte important (si aici in general intra si pozitie/orientare) si sa ai si optiunea de a trimite reliable informatiile strict necesare (spawn de entitati, remove de entitati ... ).



"De incredere" ?, dar in contextul de fatza cred ca se potriveste mai bine "sigur".

multumesc Dark pentru detalii, asa ma gandisem si eu, insa packet order asta ar trebui sa fie separat pt reliable si unreliable, ca nu trebuie sa astept daca imi vin unreliable, defapt ot seta un flag in pachet.. adica cum ziceai de -canale-.

Alta intrebare, am inteles ca TCP + UDP deodata incetineste UDP-ul, adica sa am un socket sa trasmit reliable date critice pe TCP (rar), si UDP pt fast paced data..

Da, daca vrei un canal unreliable, tii sequence number-uri separat pentru fiecare canal. E in continuare oarecum important sa te asiguri de ordering si pe canalul unreliable, adica daca-ti vine un pachet cu sequence mai mic decit ce astepti, sa-l ignori, dar la unreliable nu mai procesezi doar EXACT ce asteptai, ci merge orice e mai mare sau egal cu urmatorul sequence number asteptat (ca altfel la primul pachet pierdut ti-a murit canalul). E un eveniment destul de rar si ciudat sa-ti vina doua pachete UDP in alta ordine decit au fost trimise, dar nu e complet imposibil pe internet.



Pai nu poti sa trimiti si TCP si UDP pe acelasi socket. Trebuie sa faci socketi diferiti, unul cu SOCK_DGRAM si unul cu SOCK_STREAM si nu exista interactiuni intre ei. Da' oricum, daca muncesti sa faci canalul ala reliable peste UDP, ce-ti mai trebuie TCP?

Mda, asta e alcoolul de sarbatori impleticind limba, aparent doar limba romana....

Ma gandeam la situatia in care alti novici citind chestiile astea despre ACK s-ar putea apuca sa rasfoiasca documentatii in cautarea unui pachet/API special pentru tehnologia ACKnowledge. E preferabil sa spunem clar ca este vorba despre un simplu packet UDP cu flag logic, pus de catre coder in pachet ca byte sau chiar bit, cu sensul de ACKnowlegde.

Nekitu:
Despre TCP+UDP, cum zice si Dark, nu se poate de pe acelasi socket. Daca te referi la performanta aplicatiei in cazul in care folosesti si TCP si UDP asta depinde de environment, dar in majoritatea cazurilor nu trebuie sa ai grija de lucrul asta fiindca functioneaza bine, atata timp cat nu gatui banda accesibila utilizatorului respectiv.

A, da, corect.

In treacat fie spus, UDP-ul e stricat pe Windows de la Windows 2000 incoace. Un cretin inimaginabil de mare n-a inteles despre ce e vorba in acest protocol care avea venerabila virsta de 20 de ani cind a scris el codul si l-a facut sa fie connection-oriented. Cretini sint peste tot, dar ce ma minuneaza si mai tare este ca in ditamai firma cu ditamai QA-ul nu s-a prins nimeni de imbecilitatea aluia. Si mai amuzant e ca in Windows 9x si NT e implementat bine, doar la 2000 s-au simtit revolutionari.

Bug-ul este ca atunci cind inchizi un socket UDP, Windows-ul binevoieste sa trimita un pachet spre peer sa-i spuna ca l-ai inchis. Mai mult, Windows-ul din partea ailalta inchide si el socket-ul propriu cind vede pachetul ala. Asta este mirobolant deoarece pe un socket UDP poti trimite date catre mai multi peeri, si poti vorbi si cu acelasi peer de 30 de ori daca vrei, chiar daca el se opreste si reporneste de 70 de ori intre timp. Cretinului trebuia macar sa i se aprinda un beculet cind a scris codul deoarece daca ai vorbit cu mai multi peeri, el poate sa-l ia doar pe ultimul sa-l pricopseasca cu mesajul, ca n-are o lista cu toate IP-urile spre care ai trimis. Da' nici macar asta nu l-a facut sa gindeasca, el a scris cod mai departe.

Partea nasoala survine in jocurile client-server care nu stiu de prostia asta. Acolo ai un server, care are un socket UDP, pe care vorbeste cu o multime de clienti. Cind un client iese, Windows-ul ii zice serverului ca s-a inchis socket-ul, iar serverului i se inchide si lui socket-ul automat, stricind tot jocul. Daca v-ati intrebat vreodata de ce, cind iese un client de pe un server de Q2, moare tot jocul, asta e motivul.

Lu' Microsoft nu le-a luat decit vreo 2 ani sa inteleaga ca au o problema. Si atunci ce-au facut? Pai au facut un hotfix pentru Windows 2000, dar hotfix-ul nu repara nimic. In loc sa revina la comportamentul corect specificat intr-un standard de 20 de ani, ei au facut un IOCTL pe care trebuie sa-l apelezi ca sa obtii UDP care merge. By default, ai UDP care nu merge si trebuie sa te rogi de el sa-si bage mintile-n cap. "Comportamentul" s-a pastrat si pe XP si pe Vista.

Pe scurt, socketii UDP se fac in felul urmator pe Windows:



Misto, nu?

M-am exprimat gresit, nu pe acelasi socket, evident, ci doua sockets fiecare cu treaba lui TCP si UDP, pe TCP sa transmit rar date critice si pe UDP sa pompez la greu pachete care se pierd sau nu.

Citisem din cateva surse cum ca traficul pe socketul TCP ar gatui socketul UDP, si in alte locuri am citit ca nu ar fi vreo dovada tehnica ca s-ar intampla asta, si nush pe cine sa cred, nu cunosc mecanismele low level.

Insa intr-adevar, daca tot am UDP working ok, nu e mare lucru sa ii bag si reliable stuff in el, sa nu mai stau cu doua fire in mana...

Nu exista o regula sau o preferinta dupa care TCP sa gituie UDP sau invers. Poti avea diverse politici de fairness sau quality of service intre doua capete ale conexiunii daca esti pe internet, dar nu poti sti nimic despre ele. Se poate ca unui ISP sa-i casuneze sa prioritizeze traficul TCP peste UDP ca sa mearga downloadu' la porn mai bine, la fel cum altul poate prioritiza invers, ca sa mearga streaming-ul la webcam porn mai bine. Mult mai probabil nu va fi nici o regula si vor merge la fel de bine (sau prost) ambele. Mai mult, problemele n-ar putea sa apara decit cind forjezi ambele conexiuni, ceea ce probabil nu-i cazul pe TCP pe unde vorbesti mai rar.

TCP e bun intr-un joc de twitch doar pentru chat. Chiar si pentru pachetele reliable vrei sa minimizezi latenta, ca e nasol daca afli abia dupa 2 secunde ca ala dupa care alergai ti-a dat cu railu' in boase. D-aia e bine sa trimiti tot peste UDP si sa-i faci un canal garantat, pe unde faci retransmit-uri agresiv, nu odata la 50 de ani ca TCP-ul (si cu granularitate pe pachet, nu pe numar de bytes). Daca ai canalul ala, e mai multa bataie de cap sa faci inca un socket TCP pe unde sa dai doar chat-ul si chestii minore. Mai usor dai totu' pe UDP, daca tot te-ai apucat.

O exceptie ar fi downloadu' fisierelor de pe server, cum face quake cu modele, arme, sunete etc. P-alea e bine sa le iei pe TCP, ca vrei throughput maxim si protocolul reliable peste UDP nu e optimizat pentru asta.

Eh, asta e o meteahna apartinand probabil religiei Microsoft. Cam greu ca indienii de la tech support sa ia in serios idea ca "o parte de baza a sistemului de operare are bube".

Iar solutia... din acelashi departament cu limitarea numarului de conexiuni TCP simultane.