[so] tema 4 again

[Octavian Purdila]

> 1.In man se specifica pentru functiile send/recv faptul ca in anumite
> conditii kernelul nu trimite toti nbytes specificati in apelul
> functiei ci un numar mai mic, n pe care de altfel functia il si
> intoarce. Sunt perfect de acord cand datele de trimis sunt >1500 oct,
> si datorita procesului de encapsulare segmentul de date trebuie spart.
> Nu se specifica exact cam care ar fi dimensiunea maxima a datelor de
> trimis pentru care as putea fi sigur ca se trmit toate odata.
>

Pentru ca exista intotdeauna o probabilatate (cateodata mica, cateodata
mai mare) ca aceste date sa nu fie trimise toate odata, oricat de mica ar
fi dimensiunea buferului.

> Atunci cand trimit cei len octeti de la client catre server (pentru
> scriere) sau invers (la citire) fac verificarea sa fiu sigur ca sunt
> trimisi toti.
> In schimb toate celelate mesaje schimbate intre client si server sunt
> extreme de mici (<64 octeti) si cum lucrez pe local loop le trimit si
> presupun ca intregul mesaj e tranmis odata. E vreo problema??? As
> putea face si aici verificari dar singura solutie ce imi vine acum in
> minte e sa fac propria mea encapsulare, si nu cred ca scopul acestei
> teme e sa reinventez TCP-ul… n-am facut-o nici anul trecut la PC
> :-).
>
> So, e OK sa fac presupunerea ca toate mesajele mai mici de 64 oct sunt
> sigur transmise dintr-o bucata si doar pentru cele mai mari sa fac
> verificarile de rigoare?
>

Nu. SO poate sa faca (si face) buffering inainte de a trimite datele. Asa
ca nu este extrem de improbabil ca si la mesajele mai mici e 64 octeti sa
fie trimise din cel putin doua bucati.

> Daca la raspuns folosesc scirere asincrona pe socketi problema de mai
> sus apare???
>

     "Once the request is finished this function can be used exactly
     once to retrieve the return value.  Following calls might lead to
     undefined behavior.  The return value itself is the value which
     would have been returned by the `read', `write', or `fsync' call".

[citat din  info libc, aio_return, deci problema apare si la scriere
asincrona]


PS: Dupa cum am mai spus, ar fi bine sa scapati de aceasta atitudine de a
incerca sa "scapati" de teme. Altfel, aceasta atitudine o sa va aduca
prejudicii in viitor: dureaza mai mult sa va dezvatati de obiceiuri
proaste in programare, decat sa invatati sa programati corect de la
inceput.



tavi