IDL-tekniker för bättre gränssnitts- och metoddesign

Överväg att använda följande IDL-specifika tekniker för att förbättra säkerhet och prestanda när du utvecklar RPC-gränssnitt och -metoder som hanterar både överensstämmande och variantdata. Attributen som anges i det här avsnittet är de IDL-attribut som anges för metodparametrar som hanterar antingen överensstämmande data (till exempel attributen [size_is] och [max_is] eller variantdata (till exempel attributen [length_is] och [sträng] ).

Använda attributet [range] med överensstämmande dataparametrar

Attributet [range] instruerar RPC-körningen att utföra ytterligare storleksvalidering under dataomfångsprocessen. Mer specifikt verifierar den att den angivna storleken på de data som skickas som den associerade parametern ligger inom det angivna intervallet.

Attributet [range] påverkar inte trådformatet.

Om värdet på kabeln ligger utanför det tillåtna intervallet utlöser RPC ett RPC_X_INVALID_BOUND eller RPC_X_BAD_STUB_DATA undantag. Detta ger ytterligare en nivå av dataverifiering och kan hjälpa till att förhindra vanliga säkerhetsfel som buffertöverskridningar. På samma sätt kan användning av [intervall] förbättra programmets prestanda, eftersom överensstämmande data som markerats med det har tydligt definierade begränsningar som är tillgängliga för övervägande av RPC-tjänsten.

Regler för minneshantering för RPC Server Stub

Det är viktigt att förstå reglerna för minneshantering av RPC-serverns stub-minne när du skapar IDL-filerna för ett RPC-aktiverat program. Program kan förbättra användningen av serverresurser genom att använda [intervall] tillsammans med överensstämmande data som anges ovan, samt avsiktligt undvika tillämpningen av IDL-attribut med variabel längd som [length_is] för att anpassa data.

Du rekommenderas inte att använda [length_is] för datastrukturfält som definierats i en IDL-fil.

Metodtips för dataparametrar med variabel längd

Följande är flera metodtips att tänka på när du definierar IDL-attributen för datastrukturer i variabel storlek, metodparametrar och fält.

• Använd tidig korrelation. Det är vanligtvis bättre att definiera parametern eller fältet för variabelstorlek så att den inträffar omedelbart efter den kontrollerande integraltypen.

  Till exempel

  earlyCorr
  (
  [in, range(MIN_COUNT, MAX_COUNT)] long size, 
  [in,size_is(size)] char *pv
  );
  

  är bättre än

  lateCorr
  (
  [in,size_is(size)] char *pv, 
  [in, range(MIN_COUNT, MAX_COUNT)] long size)
  );
  

  där earlyCorr deklarerar storleksparametern omedelbart före dataparametern med variabel längd och lateCorr deklarerar storleksparametern efter den. Att använda tidig korrespondens förbättrar prestandan totalt sett, särskilt i fall där metoden anropas ofta.

• För parametrar som har markerats med attributet [ut, size_is] och där datalängden är känd på klientsidan eller där klienten har en rimlig övre gräns, bör metoddefinitionen likna följande när det gäller parameterattributering och sekvens:

  outKnownSize
  (
  [in,range(MIN_COUNT, MAX_COUNT)] long lSize,
  [out,size_is(lSize)] UserDataType * pArr
  );
  

  I det här fallet tillhandahåller klienten en buffert med fast storlek för pArr, vilket gör att RPC-tjänsten på serversidan kan allokera en buffert av rimlig storlek med en god grad av säkerhet. Observera att i exemplet tas data emot från servern ([ut]). Definitionen liknar data som skickas till servern ([i]).

• I situationer där komponenten på serversidan i ett RPC-program bestämmer datalängden bör metoddefinitionen likna följande:

  typedef [range(MIN_COUNT,MAX_COUNT)] long RANGED_LONG;
  
  outUnknownSize
  (
  [out] RANGED_LONG *pSize,
  [out,size_is(,*pSize)] UserDataType **ppArr
  );
  

  RANGED_LONG är en typ som definierats för både klienten och servern och av en angiven storlek som klienten kan förutse korrekt. I exemplet skickar klienten ppArr som NULL-och RPC-serverprogramkomponenten allokerar rätt mängd minne. Vid returen allokerar RPC-tjänsten på klientsidan minnet för de returnerade data.

• Om klienten vill skicka en delmängd av en stor konform matris till servern kan programmet ange storleken på delmängden enligt följande exempel:

  inConformantVaryingArray
  (
  [in,range(MIN_COUNT,MAX_COUNT)] long lSize,
  [in] long lLength, 
  [in,size_is(lSize), length_is(lLength)] UserDataType *pArr
  );
  

  På så sätt överför RPC endast lLength- element i matrisen över tråden. Den här definitionen tvingar dock RPC-tjänsten att allokera minne av storlek lSize på serversidan.

• Om klientprogramkomponenten avgör den maximala storleken på en matris som servern kan returnera, men tillåter att servern överför en delmängd av matrisen, kan programmet ange ett sådant beteende genom att definiera IDL som liknar följande exempel:

  inMaxSizeOutLength
  (
  [in, range(MIN_COUNT, MAX_COUNT)] long lSize,
  [out] long *pLength,
  [out,size_is(lSize), length_is(*pLength)] UserDataType *pArr
  );
  

  Klientprogramkomponenten anger den maximala storleken på matrisen och servern anger hur många element som överförs tillbaka till klienten.

• Om serverprogramkomponenten behöver returnera en sträng till klientprogramkomponenten, och om klienten känner till den maximala storleken som ska returneras från servern, kan programmet använda en konform strängtyp som visas i följande exempel:

  outStringKnownSize
  (
  [in,range(MIN_COUNT, MAX_STRING)] long lSize,
  [out,size_is(lSize),string] wchar_t *pString
  );
  

• Om klientprogramkomponenten inte ska styra strängens storlek kan RPC-tjänsten specifikt allokera minnet, vilket visas i följande exempel:

  outStringUnknownSize
  (
  [out] LPWSTR *ppStr
  );
  

  Klientprogramkomponenten måste ange ppStr- till NULL- på när RPC-metoden anropas.