Delen via


Socket-handles dupliceren voor een SAN

Meerdere toepassingen die in verschillende processen worden uitgevoerd, kunnen de Windows Sockets-switch gebruiken om bewerkingen uit te voeren op een gedeelde onderliggende socket. Er kan echter slechts één toepassing tegelijk bewerkingen uitvoeren op die gedeelde onderliggende socket.

Als u een gedeelde onderliggende socket wilt gebruiken, moet een toepassing op een van de volgende manieren een dubbele ingang naar die onderliggende socket ophalen:

  • Rechtstreeks door de functie Windows Sockets WSADuplicateSocket aan te roepen

    De aanroep wordt gedaan in de context van het besturingsproces (het proces waarin de socket is gemaakt).

  • Indirect, door de functie Win32 DuplicateHandle aan te roepen

    De aanroep wordt uitgevoerd in de context van een niet-controleproces (anders dan het proces waarin de socket is gemaakt).

  • Het handvat overervingsmechanisme gebruiken

    Een onderliggend proces (het subproces) erft alle of enkele handlers over die in het bovenliggende proces (het controleproces) zijn aangemaakt.

  • Tijdens het zorgvuldig sluiten van een verbinding

    Als een toepassing in het besturingsproces een socket sluit en afsluit terwijl sommige gegevens nog moeten worden verzonden, worden deze resterende gegevens gebufferd in het DLL-bestand van Windows Sockets. Een andere toepassing in de context van het systeemserviceproces (het niet-controleproces) verzendt deze gegevens vervolgens.

De Windows Sockets-switch, in combinatie met de TCP/IP-provider, detecteert en verwerkt elk van de voorgaande voorwaarden. De switch staat slechts één proces tegelijk toe om bewerkingen uit te voeren die gegevens overdragen of de status wijzigen voor een onderliggende gedeelde socket. Processen wisselen dynamisch de controle over de onderliggende socket, als dat nodig is, om aangevraagde bewerkingen uit te voeren. De switch serialiseert bewerkingen die verschillende processen aanvragen om uit te voeren op een gedeelde socket en voert deze bewerkingen uit in fifo-volgorde (first-in-first-out). De switch wacht tot alle actieve bewerkingen zijn voltooid voordat de controle van een onderliggende socket naar een ander proces wordt overgedragen. Logisch neemt de schakelaar de controle over de onderliggende socket weg van het besturingsproces zodra een niet-besturend proces een kwalificerende operatie aanvraagt. Nadat de controle is weggenomen, behandelt de switch het oorspronkelijke controlerende proces als een niet-controlerend proces als het oorspronkelijke proces kwalificerende bewerkingen aanvraagt. Houd er rekening mee dat de switch geen actie onderneemt op een dubbele sockethandgreep totdat het niet-controleerbare proces daadwerkelijk de dubbele sockethandgreep gebruikt voor een gegevensoverdracht of statuswijzigingsbewerking.

Zowel de switch als de juiste SAN-serviceprovider worden geladen in alle processen die toegang tot een bepaalde onderliggende socket delen. De switch onderhoudt zijn eigen socketcontext- en verbindingsstatusgegevens in alle processen die de socket delen. De SAN-serviceprovider is verplicht om zijn socketcontext- en verbindingsstatusinformatie alleen te behouden in het proces dat controle heeft over de onderliggende socket op elk moment. De SAN-serviceprovider moet de controle over de context en de verbindingsstatus van het huidige besturingsproces wisselen naar het volgende controleproces wanneer de switch de wissel vereist, zoals beschreven in de volgende volgorde. Om de hoeveelheid resources te minimaliseren die nodig zijn voor het wisselen, kan een SAN-serviceprovider de context- en verbindingsstatusgegevens behouden in alle processen die een onderliggende socket delen.

Omdat de switch de SAN-socket die overeenkomt met een applicatiesocket pas maakt wanneer een applicatie ofwel de connect of de listen functie aanroept, kan de switch niet aanvragen dat de SAN-serviceprovider een wisselbewerking uitvoert voordat de applicatiesocket verbonden is of luistert. Zelfs nadat de toepassingssocket is verbonden of luistert, moet aan een van de volgende voorwaarden worden voldaan voordat aan de switch wordt gevraagd of de SAN-serviceprovider het beheer van de socket wisselt:

  • Een proces dat geen controle heeft over de socket, initieert een gegevensoverdracht. De SAN-serviceprovider wisselt de besturing van de socket pas nadat alle bewerkingen voor gegevensoverdracht die zijn gestart door het controleproces zijn voltooid.

  • Een proces dat de socket niet bepaalt, roept de WSAAccept-, WSPAccept-of AcceptEx--functie aan om een verbindingsacceptatiebewerking op een listening socket te starten. De SAN-serviceprovider draagt de controle over de socket niet over voordat alle aanvragen die zijn gestart door het controlerende proces zijn afgerond.

De switch voert de volgende stappen uit om het beheer van een verbonden SAN-socket van het besturingsproces te wisselen naar het volgende besturingsproces (Zie de tabel in het gedeelte Opmerkingen van de documentatie voor de WSPDuplicateSocket functie voor een overzicht van het wisselproces.):

  1. De switch onderbreekt de verwerking van nieuwe aanvragen van de toepassing in het controleproces. Wanneer alle actieve verzend- en RDMA-bewerkingen op de SAN-socket zijn voltooid, roept de switch de WSPSend--functie van de SAN-serviceprovider aan om een bericht te verzenden naar een verbonden peer om een schorsing van de sessie aan te vragen en roept de san-serviceprovider de WSPDeregisterMemory--functie aan om alle lokale buffers vrij te geven die worden gebruikt voor verzendbewerkingen. Als gevolg hiervan pauzeert de switch bij de peerverbinding de verwerking van nieuwe toepassingsaanvragen, wacht tot alle verzend- en RDMA-bewerkingen die worden uitgevoerd op de SAN-socket zijn voltooid, en geeft vervolgens al het RDMA-geheugen vrij. De peerverbinding verzendt vervolgens een antwoordbericht dat aangeeft dat de sessie is onderbroken. Wanneer u dit bevestigingsbericht ontvangt, roept de switch op het lokale eindpunt de WSPDeregisterRdmaMemory- functie van de SAN-serviceprovider aan om alle RDMA-geheugen vrij te geven. Op dit moment kunnen SAN-sockets op beide eindpunten van de verbinding alleen aanvragen ontvangen die in behandeling zijn. Deze ontvangen aanvragen blijven in behandeling op de SAN-socket van de externe peer om het opnieuw activeren van de sessie mogelijk te maken. De ontvangen verzoeken via de lokale SAN-socket in het controleproces worden in de volgende stap voltooid. Terwijl de verbinding is onderbroken, plaatst de switch bij de verbinding met de externe peer nieuwe blokkerende of overlappende aanvragen in de wachtrij, buffert nieuwe niet-blokkerende verzendingen binnen de SO_SNDBUF-instelling, wijst nieuwe niet-blokkerende verzendingen af nadat de bufferlimiet is bereikt, en wijst alle nieuwe niet-blokkerende ontvangen gegevens af met WSAEWOULDBLOCK. De lokale switch in het besturingsproces verwerkt nieuwe aanvragen op de toepassingssocket alsof het proces geen controle over de socket heeft.

  2. Nadat de sessie is opgeschort, roept de switch in het controlerende proces de WSPDuplicateSocket-functie van de SAN-serviceprovider aan om de socketcontext over te brengen naar het adresbereik van het volgende controlerende proces. De switch geeft het volgende besturingsproces op in de dwProcessId parameter van WSPDuplicateSocket. De functie WSPDuplicateSocket moet de functie WPUCompleteOverlappedRequest aanroepen om alle openstaande ontvangstaanvragen op de socket met successtatus en nul bytes te voltooien. De SAN-serviceprovider moet ook automatisch alle buffers vrijgeven die aan deze aanvragen zijn gekoppeld. De SAN-serviceprovider geeft alle buffers vrij omdat de switch geen bewerkingen meer aanvraagt op de SAN-socket nadat WSPDuplicateSocket retourneert. De enige mogelijke uitzondering is een WSPCloseSocket functieaanroep, zoals beschreven in de volgende stap. Nadat WSPDuplicateSocket is geretourneerd, slaat de switch de waarde op in het dwProviderReserved lid van de WSAPROTOCOL_INFOW-structuur waarnaar de lpProtocolInfo uitvoerparameter punten. De switch gebruikt deze waarde om de onderliggende socket te identificeren in de context van het volgende besturingsproces. Daarom moet de waarde in dwProviderReserved de onderliggende socket en de verbinding voor die socket uniek identificeren voor alle processen in het systeem. Bovendien moet deze waarde alleen geldig zijn in de context van het proces dat is opgegeven in de dwProcessId parameter van WSPDuplicateSocket.

  3. Nadat de socketcontext is overgebracht naar de adresruimte van het volgende besturingsproces, roept de switch de WSPSocket--functie van de SAN-serviceprovider aan in de context van het volgende controleproces. In deze aanroep geeft de switch de waarde door voor de onderliggende socket die is geretourneerd in de WSPDuplicateSocket aanroep naar het dwProviderReserved lid van de WSAPROTOCOL_INFOW-structuur waarnaar de lpProtocolInfo invoerparameter punten. Als het volgende controleproces het maken van de SAN-socket niet heeft aangevraagd, moet de SAN-serviceprovider een nieuwe socket maken en de WPUCreateSocketHandle-functie aanroepen om een ingang te verkrijgen, zoals vereist voor een nieuwe socket. Als de SAN-socket is gemaakt in de context van het volgende controleproces, kan de SAN-serviceprovider de voormalige socket opnieuw activeren en dezelfde descriptor retourneren voor de socket die eerder is gebruikt. In dit geval moet de SAN serviceprovider geen WPUCreateSocketHandle-aanroepen, maar moet de oorspronkelijke socketgreep blijven gebruiken die door de switch is verstrekt. De SAN-serviceprovider kan ook een nieuwe socket maken, ongeacht of er eerder een socket in het proces bestond. In dit geval moet de switch de functie WSPCloseSocket van de SAN-serviceprovider aanroepen in de context van het volgende controleproces om de vorige socketdescriptor te verwijderen.

  4. De switch start de verwerking van nieuwe aanvragen van de toepassing opnieuw op in het volgende beheerproces.

De switch dupliceert een luistersocket op een vergelijkbare manier, behalve dat de switch niet verplicht is om een sessie op te schorten. De schakelaar wacht totdat alle WSPAccept-aanroepen, die zijn geïnitieerd door de accept- en AcceptEx-aanroepen van een toepassing, zijn voltooid voordat de WSPDuplicateSocket-functie van de SAN-serviceprovider in het besturingsproces wordt aangeroepen.

Omdat de switch de verwerking van nieuwe aanvragen op een SAN-socket onderbreekt voordat de WSPDuplicateSocket-functie van de SAN-serviceprovider wordt aangeroepen, kan de SAN-serviceprovider alle resources vrijgeven die zijn gekoppeld aan een lokaal eindpunt in het beheerproces. De SAN-serviceprovider kan zelfs een onderliggende verbinding beëindigen. Als de SAN-serviceprovider een onderliggende verbinding in het beheerproces sluit, moet de SAN-serviceprovider de verbinding herstellen nadat de switch de WSPSocket--functie van de SAN-serviceprovider aanroept binnen het volgende controleproces. Nadat de WSPSocket-aanroep is geretourneerd, moet de SAN-socket in het volgende beheerproces vanuit het perspectief van de switch in dezelfde staat zijn als waarin de SAN-socket in het besturingsproces was voordat de switch de WSPDuplicateSocket- functie van de SAN-serviceprovider aanriep.

Als een SAN-NIC ondersteuning biedt voor het delen van resources tussen eindpunten die in verschillende processen worden uitgevoerd, hoeft de SAN-serviceprovider geen resources vrij te geven voor een lokaal eindpunt in het beheerproces voordat een WSPDuplicateSocket aanroep wordt ontvangen. In dat geval blijft de SAN-socket die is gekoppeld aan een lokaal eindpunt inactief in het voormalige beheerproces totdat de switch de socketcontext terugwisselt van het volgende beheerproces of de WSPCloseSocket-functie van de SAN-dienstverlener aanroept om de socket expliciet te sluiten. Omdat de meeste toepassingen hun uiteindelijke toegang tot de socket uitvoeren in het proces dat deze oorspronkelijk heeft gemaakt — meestal om de verbinding te sluiten — kan de SAN-serviceprovider de prestaties verbeteren als de SAN-serviceprovider de socketcontext in het controlerend proces behoudt nadat de switch de controle over de socket heeft overgedragen aan het volgende controlerende proces.

In alle gevallen moet een SAN-socketdescriptor geldig blijven totdat de switch de WSPCloseSocket-functie van de SAN-serviceprovider aanroept om de socket expliciet te sluiten. Zelfs als de SAN-serviceprovider alle resources voor de socket in een bepaald proces vrijgeeft voordat een WSPDuplicateSocket aanroep wordt ontvangen, mag de SAN-serviceprovider de descriptor voor de socket pas opnieuw gebruiken als de switch WSPCloseSocket op die descriptor aanroept.

Een onverwachte procesafsluiting of een andere foutconditie kan de socket-duplicatiebewerking van een SAN-serviceprovider onderbreken. Een tekort aan resources kan bijvoorbeeld een dergelijke onderbreking veroorzaken. De schakelaar behandelt dergelijke foutcondities zoals het andere foutsituaties doet. Indien nodig sluit de switch alle descriptors die zijn gekoppeld aan de onderliggende socket in alle processen om de verbinding van de socket geforceerd te beëindigen. Indien mogelijk moet de SAN-serviceprovider op de externe peer WSPRecv aanroepen voltooien die binnenkomende gegevens ontvangen met een juiste foutcode, zoals WSAECONNRESET. Deze foutcode informeert de externe peer van de beëindiging van de verbinding. Als de switch op de externe peer deze indicatie voor verbindingsbeëindiging niet ontvangt, treedt er een time-out op van een onderbroken verbinding als het systeem dat de schorsing heeft aangevraagd mislukt.