On Thu, 27 Jan 2005, Claudiu Cismaru wrote:
>
> Salut,
>
> Am citit in RFC 793 cum se realizeaza comunicatia prin TCP...
>
> 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?
>
> 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.
>
> 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?
>
teoria e teorie....
cel mai simplu de inteles lucrurile ar sta cam asa:
sursa destinatie
#####......... ----> ########.......
si la sursa si la destinatie sunt niste buffere de o anumita dimensiune
depinde de SO, da io stiu ca in medie e undeva la 8k
aplicatia care trimite face o cerere catre SO sa trimita o anumita
cantitate de octeti spre o anumita destinatie. cererile sun trecute in
niste buffere de transmisie pe care partea de retea din kernel o citeste
regulat si face transmisia de date dupa anumite reguli. tragand concluzii,
daca cererile de transmisie sunt suficient de rapide (consecutive) incat
SO nu a apucat sa trimita spre retea info, poate trimite un singur paket
(de 250 octeti in cazul tau) sau 2 pakete (100 respectiv 150 octeti).
totul depinde de calculatorul pe care ruleaza aplicatia si de SO folosit.
acum trecem de partea cealalta
receptorul:
SO pe partea de retea e condus de evenimente.
vin cele 2 pakete de 100 resp 150 octeti. SO adauga cele 2 pakete la
bufferul de receptie (cat poate primi, in cazul ca bufferul el plin nu
primeste nimic) si trimite la transitator paket in care zice cati octeti a
receptionat (pe care transmitatorul ii goleste din buffer).
acum vine aplicatia care vrea sa citeasca din soket ce date o primit.
aceasta face o cerere catre SO sa ii dea un nr MAXIM de 200 de octeti din
streamul tcp de comunicatie. SO se uita la buffer cati octeti are
disponibili si sunt 2 cazuri: nu are suficienti -> ii da doar pe cei care
ii are in buffer si functia read iti intoarce dimensiunea lor si ii sterge
din buffer. al 2-lea caz: iti returneaza doar cati octeti ai cerut MAXIM
pe care ii goleste din buffer si ii lasa pe restu in buffer.
na acum sunt diverse situatii:
in cazul tau cu pakete de 100 si 150 octeti
daca ajung in bufferul de receptie amandoi
cand faci pop de 200 iti da 200 octeti
daca o ajuns numa primul paket cand faci pop de 200 iti da numa 100
si la urmatorul pop iti da cat mai ceri (in limita disponibilului din
buffer)
dar mai sunt si alte cazuri:
sa zicem ca vrei sa transmiti un paket de 3500 octeti
poti face push de 3500 octeti fata probleme pentru ca ii baga in buffer
dat stii ca MTU pentru ethernet e 1500 (daca ai tunele poate fi mai
mic,...) deci ce trimiti tu ca O SINGURA BUCATA de 3500 octeti SO cand o
ia din buffere o fragmenteaza in 3 pakete de
1500, 1500 si 500 octeti pe care le trimite spre destinatie.
daca acolo ajunge doar primul paket si aplicatia face un pop de 3500 nu i
se va da decat 1500 octeti :) restul dupa ce ajung si celelalte pakete
de asta in principiu cand faci o aplicatie care transmmite date pe net,
primadata se transmite un intreg in care se trece dimensiunea datelor ce
urmeaza, urmat de date (record)
iar la citire se citeste dimensiunea (un intreg pe 2 octeti in general
ajunge si e si relativ simplu de trimis)
dupa care se intra intr-o bucla in care se asteapta citirea de date pana
sau citit cati octeti trebuiau
Sper ca te-ai lamurit cu TCP
PS. nu conteaza ca sursa si destinatia e acelasi calculator sau
salculatoare aflate pe parti diametral opuse ale globului :)
Cristi
> Partea din RFC care e relevanta in acesta problema, este:
> "The data that flows on a connection may be thought of as a stream of
> octets. The sending user indicates in each SEND call whether the data
> in that call (and any preceeding calls) should be immediately pushed
> through to the receiving user by the setting of the PUSH flag.
>
> A sending TCP is allowed to collect data from the sending user and to
> send that data in segments at its own convenience, until the push
> function is signaled, then it must send all unsent data. When a
> receiving TCP sees the PUSH flag, it must not wait for more data from
> the sending TCP before passing the data to the receiving process.
>
> There is no necessary relationship between push functions and segment
> boundaries. The data in any particular segment may be the result of a
> single SEND call, in whole or part, or of multiple SEND calls.
>
> The purpose of push function and the PUSH flag is to push data through
> from the sending user to the receiving user. It does not provide a
> record service.
>
> There is a coupling between the push function and the use of buffers
> of data that cross the TCP/user interface. Each time a PUSH flag is
> associated with data placed into the receiving user's buffer, the
> buffer is returned to the user for processing even if the buffer is
> not filled. If data arrives that fills the user's buffer before a
> PUSH is seen, the data is passed to the user in buffer size units."
>
>
---
Detalii despre listele noastre de mail: http://www.lug.ro/
