Jeg har fået løst problemet og det forholdte sig som een af de andre, som
svarede på min henvendelse, sagde nemlig, at tekststrengene blev korrekt
sendt, men ikke nødvendigvis blev modtaget pænt opdelt. For det var nemlig
dét, der spøgede her: tekststrengene var ved modtagelsen, blevet samlet til
2-3 portioner, hvilket mit modtager-program ikke kunne finde ud af. Men da
jeg streamede indkommende data ud i en fil, kunne jeg bekræfte, at der ingen
fejl var i sendingen.
WSAEWOULDBLOCK "twisten" mærkede jeg i praksis, da jeg i en test sendte 10 x
20 mb. over netværket - ved sending nr. 2, returnerede "send" nemlig
WSAEWOULDBLOCK, og endnu en WRITE event blev udløst. Så jeg fik den til at
vente på WRITE eventen, når "send" returnerede WASEWOULDBLOCK, for herefter
at forsøge med "send" igen, og alt kørte bare som det skulle
"bop" <bop@bop.dk> wrote in message news:abbhp7$13eg$1@news.cybercity.dk...
>
> "Klaus Petersen" <spektual@hotmail.com> wrote in message
> news:ab7367$4mu$1@sunsite.dk...
> > OnWrite sker ikke hver send. OnWrite sker kun efter en ny-etableret
> > forbindelse og når bufferne, efter at de har været fyldt op*, bliver
> > tilgænglige igen.
> >
> > *når send returnerer fejlen WSAEWOULDBLOCK
> >
>
> Ok, godt set. Der er en property (ClientType) på TClientSocket hvor du
> fortæller om den skal være blokerende, men det er nok ingen fordel for
dig.
> Beskrivelsen er i online-hjælp. Jeg har ikke rigtigt selv haft held med
det,
> men det ser ud som om du har fundet årsagen til problemet? Med TCP kan man
> forvente at få bytes i den rigtige rækkefølge og man kan være sikker på at
> de kommer alle sammen, uden transmissionsfejl, men man kan ikke stille så
> store krav til hvornår de kommer. Det er iøvrigt ikke kun Windows der
> opfører sig på den måde, det er ganske generelt.
>
> --
> Bop
>
>