[so] tema 4 again

[Mihai Mincu]

Nu e vorba de a "scapa" repede de teme, caci daca vroiam asta
trimiteam direct tema si nu mai intrebam.

Problema e ca anul trecut desi era vorba de protocoale vroiam sa vad
daca e la fel, sau in caz contrar as vrea si o sugestie pentru
rezolvarea problemei.

Solutia pe care eu o am in cap e sa pun un header la fiecare mesaj
care sa imi spuna dimesiunea mesajului si sa stabilesc o dim maxima a
unui mesaj, iar la celalat capat sa folosesc un buffer cu dim de 2 ori
dim maxima pt a evita situatiile in care primesc finalul dintr-un
pachet si inceputul din altul.

Daca dupa fiecare pachet as astepta un ACK lucrurile s-ar mai
simplifica, dar asta nu e eficient, la fel cum ar fi si solutia cu un
pachet de dimensiune standard cu biti de padding in portiunile
libere...


Alte sugestii daca se poate...sunt home si cu dial-up nu prea merge
cautatul pe net. Pentru celelate 2 intrebari se poate un raspuns
scurt?
=20
=20

On Mon, 27 Dec 2004 20:40:22 +0200 (EET), Octavian Purdila
<tavi@cs.pub.ro> wrote:
> > 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.
> >
>=20
> 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.
>=20
> > 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=C3=A2=E2=82=AC=C2=A6 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?
> >
>=20
> 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.
>=20
> > Daca la raspuns folosesc scirere asincrona pe socketi problema de mai
> > sus apare???
> >
>=20
>     "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".
>=20
> [citat din  info libc, aio_return, deci problema apare si la scriere
> asincrona]
>=20
> 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.
>=20
> tavi
>=20
> _______________________________________________
> so mailing list
> so@cursuri.cs.pub.ro
> http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/so
>