netværk - Windows: TCP/IP: Tving tæt forbindelse: Undgå memleaks i kernel/bruger-niveau

Indlæg af Hanne Mølgaard Plasc

Problem



Et spørgsmål til Windows netværk programmeringseksperter.


Når jeg bruger pseudo-kode som denne:


reconnect:
    s = socket(...);
    // more code...

read\_reply:
    recv(...);
    // merge received data
    if(high\_level\_protocol\_error) {
        // whoops, there was a deviation from protocol, like overflow
        // need to reset connection and discard data right now!
        closesocket(s);
        goto reconnect;
    }


Kerner kernel un-associeret og frigiver alle data 'fysisk' modtaget fra NIC (da det virkelig skal være der allerede i kernelminne, venter brugerniveau at læse det med recv ()), når jeg lukker luk ()? Nå, det burde logisk, da data ikke er forbundet med noget internt objekt længere, ikke?


Fordi jeg ikke virkelig vil spilde ukendt tid til ren shutdown som ' ring recv () indtil returneringsfejl '. Det giver ikke mening: Hvad hvis det aldrig vil returnere fejl, siger, server fortsætter med at sende data for evigt og ikke lukker forbindelse, men det er dårlig opførsel?


Jeg undrer mig over det, da jeg ikke vil have min ansøgning for at forårsage hukommelse lækager overalt. Er denne metode til tvungen nulstilling af forbindelse, der stadig forventes at sende ukendt mængde data korrekt?


//valgfri tilføjelse til spørgsmål: Hvis denne metode anses for korrekt for Windows, kan den betragtes som korrekt (med ændring af closesocket() til close()) for UNIX-kompatibelt OS?

Bedste reference


Kerneldrivere i Windows (eller noget OS virkelig), herunder tcpip.sys, skal undgå alle hukommelseskilder, uanset hvad du gør i brugertilstand. Jeg tror, ​​at udviklerne har chartret de mulige tilstande, herunder fejltilstande, for at sikre sig, at ressourcerne ikke er lækket. Hvad angår brugertilstand er jeg ikke helt sikker på, men jeg ville ikke tro, at ressourcerne er lækket i din proces enten.


Sockets er kun filobjekter i Windows. Når du lukker det sidste håndtag til en fil, sender IO-manager en IRP\_MJ\_CLEANUP besked til den driver, der ejer filen, for at rydde op ressourcer, der er forbundet med den. De modtagende buffere, der er forbundet med stikket, vil blive frigjort sammen med filobjektet. [7]


Det står i dokumentationen closesocket, at ventende operationer annulleres, men at async-operationer kan fuldføres, når funktionen vender tilbage. Det lyder som at lukke stikket, mens det er i brug, er et understøttet scenario, og det vil ikke føre til hukommelsesleje. [8]

Andre referencer 1


Der er ingen lækage, og du er ikke forpligtet til at læse strømmen til EOS inden lukningen. Hvis afsenderen stadig sender efter at du har lukket det, vil den efterhånden få en 'resetilslutning'.