Nazalost situacija je prostija nego sto mislis, kazem nazalost zato sto to otezava programiranje. Naime, iako TCP podaci putuju u "paketima" sa klijentske (i serverske) strane TCP podaci se posmatraju kao kontinualni niz bajtova, dakle nema paketa/poruka. Hocu da kazem da je mopguce sledece:

1. klijent salje 10 puta po 10 bajtova - server prima svih 100 bajtova odjednom
2. klijent salje 10 puta po 10 bajtova - server prima 100 puta po 1 bajt
3. sve kombinacije izmedju 1. i 2. su moguce

Dakle to sto klijent posalje 20 bajtova u jednom send() pozivu ne znaci da ce server svih 20 da primi u jednom recv() pozivu, mozda primi manje, a mozda i vise (ako je posle posalto jos nesto)...

Dakle ... knjigu u ruke ... salim se.

I da, kada se bajtovi jednom procitaju sa recv() onda se brisu iz bafera (samo oni koji su procitani).

Hope this helps.
Pozdrav

OK, hvala!
Koliko sam shvatio, to znaci da nikada nisam siguran da cu jednim
recv(...) primiti jednu cjelovitu poruku (mada je dosada uvijek uspjevalo).

Šta tačno podrazumevaš pod "porukom"? Takođe, laboratorijske uslove ne treba mešati sa pravim Internetom... Za početak, u TCP komunikaciji postoji jedan parametar koji se zove MSS, tj. Maximim Segment Size. Probaj da izmeniš taj parametar u tvojoj laboratoriji pa da testiraš...

Marko.

Pod porukom podrazumjevam niz bajta (od 20 do 300)
koji salje od servera prema klijentu ili obratno, pri cemu ta poruka sadrzi odredjene podatke koji odredjuju sljedecu akciju koja se treba izvrsiti na serveru ili klijentu.
A, pravo da ti kazem, ne znam sta je taj >> Maximim Segment Size <<
i kako da ga izmjenim?

Mada u medjuvremenu sam nasao rjesenje mog problema sa porukama varijabilne duzine.
Poruke koje primam uzimam iz buffera u fiksnoj duzini smjestam u svoj interni buffer par puta veci od primljene poruke, a onda uzimanjem parametra i siftanjem ulijevo uspjevam da obezbjedim da se poruke predaju na obradu u svojoj originalnoj velicini (koja je varijabilna).

RFC 793, strana 18.

Marko.