On Thu, 27 Jan 2005, Claudiu Cismaru wrote: > > Salut, > > Am citit in RFC 793 cum se realizeaza comunicatia prin TCP...
Nu am citit. > > Am urmatoarea nelamurire. Se da urmatoarea situatie: > > P1, P2 = peer 1, 2 > > P1: write (100 bytes). > P1: write (150 bytes). > P2: read (max 200); > > Conform acelui RFC, spune ca datele sunt date catre utilizator, de catre > stiva, la primirea flagului PUSH. Intrebarea vine: la fiecare write (am > cautat in manual la send si nu se specifica daca se poate controla > PUSH, deci o face automat stiva TCP/IP) stiva, dupa transmisia celor > 100byes, activeaza PUSH? Adica P2 va primi PUSH dupa cei 100byes si > inca un PUSH dupa cei 150? Cum va reactiona read ();? Va citi 200 > bytes: 100 din primul write si 100 din cel de-al doilea? Sau stiva se > asigura ca primeste cei 100 la un read si urmatorii 150 la un alt read? Habar nu am ce face PUSH dar ideea e ca nu ai nici o garantie daca se vor trimite cei 250 de bytes intr-un singur segment, sau doar 200, sau doar 100 , etc. De asemenea nu ai nici o garantie daca read()-ul va citi 0 bytes (in NONBLOCK), 10, sau maximul de 200 dat la read. TCP (cel putin interfata BSD sockets) iti asigura doar ca datele sunt receptionate in ordinea in care au fost trimise, fara sa fie corupte si cu o singura copie (fara duplicate). Alte presupuneri nu sunt valide. Priveste un socket TCP ca un "stream" bidirectional, pt ca asta e si interfata ta la el prin read/write. > Singura specificatie in legatura cu PUSH-ul este urmatorul: stiva poate > notifica utilizatorul ce primeste datele si poate pune datele available > daca bufferul intern alocat respectivei conexiuni este plin si inca nu > a ajuns o "comanda" de PUSH. Adica verifici rezultatul comenzii write() si vezi daca s-au scris toti bytes-ii in buferul TCP out al socketului, altfel ai grija sa mai incerci "data viitoare" de unde ai ramas. Eu cred ca tot ce ai nevoie sa stii despre TCP dpdv al programarii sunt paginile de manual pt read/write unde iti scrie ce inseamna return result-ul si de ce trebuie sa-l verifici. Restul de detalii low level al unei stive TCP/IP nu ar trebui sa te afecteze in general. > > Se poate intampla ca de la primul write sa primesc mai putin de 100 > bytes pe available, la read, necesand un al doilea read pentru a citi > in totalitate cei 100bytes de la primul write? Desigur. Nu exista nimic sa iti garanteze altfel. Exista un workarround care sa iti garanteze ca datele trimise la write sunt sigur puse toate in bufferul de output al TCP al socketului respectiv, dar nimic AFAIK care sa te asigure cum sunt transmise aceste date. Despre ce zic eu vezi low water mark setting si poll/select (care iti va returna un socket ca fiind write ready daca low water mark bytes sunt free in bufferul de output si deci poti sti sigur ca urmatorul write va fi acceptat complet in functie de dimensiunea de write). Ce vrei tu mai degraba s-ar face cu UDP. Acolo nu exista buffer de output in sensul TCP si datagramele sunt transmise complet sau deloc. -- Mihai RUSU Email: [EMAIL PROTECTED] GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net "Linux is obsolete" -- AST --- Detalii despre listele noastre de mail: http://www.lug.ro/
