c + + - Overlappede besked kaldet rør, ERROR\_MORE\_DATA og CancelIoEx

Indlæg af Hanne Mølgaard Plasc

Problem

Jeg bruger $ SUB for første gang og har stødt på dette problem. Både klient og server bruger overlappede operationer, og her er den specifikke situation, jeg har problemer med. Klient C1. Forbinder til serveren.
C2. Sender beskeden større end en rørbuffer og buffer overført til overlappede læsning i serveren.
C3. Afbryder afsenderen med succes.
Server S1. Opretter og venter på klienten.
S2. Når klienten er tilsluttet, læser den beskeden.
S21. Fordi meddelelsen ikke passer ind i bufferen (ERROR\_MORE\_DATA), er den læst del af del.
Det forekommer mig, at der ikke er nogen måde at fortælle hvornår er hele meddelelsen, som en isoleret enhed, annulleret. I særdeleshed, hvis klienten annullerer afsendelsesoperationen, modtager serveren ikke hele meddelelsen, bare en del af den, og deraf følger, at aflæsningsoperationen vender tilbage med ERROR\_IO\_PENDING (i mit tilfælde), hvilket betyder, at der ikke er nogen data, der skal læses og læseoperationen har været i køen. Jeg ville forvente at have en form for midler, der fortæller læseren, at meddelelsen er blevet annulleret, så læseren kan reagere på det. Relevant dokumentation er imidlertid spredt over MSDN, så jeg kan lige så godt mangle noget. Jeg vil virkelig sætte pris på, om nogen kan kaste lys over det. Tak.

Bedste reference

Du er korrekt, der er ingen måde at fortælle. Hvis du annullerer Writefile halvvejs igennem, vil kun en del af meddelelsen blive skrevet, så kun den del bliver læst af serveren. Der er ingen 'bogholderi' information sendt om, hvor stor beskeden skulle være før du annullerede det - det, der sendes, er kun de rå data. Så svaret er: Afbestill ikke IO, vent bare på, at det lykkes. Hvis du gør nødt til at annullere IO delvist igennem, skal du sandsynligvis afbryde forbindelsen og starte igen fra begyndelsen, ligesom du ville for et netværkstab. (Du kan tjekke din OVERLAPPED-struktur for at finde ud af, hvor meget der faktisk blev skrevet, og fortsæt derfra, men hvis du ville gøre det, ville du sandsynligvis bare ikke annullere IO i første omgang.) Hvorfor ønskede du at annullere IO alligevel? Hvilken række omstændigheder udløser dette krav?