Kapcsolatvesztés kezelése

Az RPC-hívás befejeződése után a kapcsolat nincs lezárva; ingyenesként van megjelölve. Így a kiszolgáló leállhat, vagy a hálózati kapcsolat megszakadhat a hívások alatt vagy között, miközben a kapcsolat a kapcsolatkészletben van. Szabályzatként az RPC futási ideje csak akkor kísérli meg újra a hívásokat, ha az alábbi két feltétel teljesül:

• A kiszolgáló nem tudja végrehajtani a hívást, vagy a hívás idempotens.
• Az ügyfél teljesítményhatékony módon implementálhatja az újrapróbálkozásokat.

A következő bekezdések kibontják és tisztázzák a két feltételt.

Az idempotens hívás olyan hívás, amely többször is végrehajtható a kiszolgálón nemkívánatos mellékhatások nélkül. Például, ha egy RPC-hívás lekérdezi egy adott számla egyenlegét a bankban, ez idempotens. Ha ezt a hívást a kapcsolat megszakadása miatt kétszer hajtják végre, a rendszer nem okoz kárt. Egy másik példa az idempotens hívásra egy ügyfél címének módosítása az adatbázisban. A kétszeri végrehajtás rendben van, mivel a második végrehajtás egyszerűen lecseréli a már meglévő címet ugyanazzal a címmel. Az olyan műveletek, mint az "ötven dollár kivonása a xyz fiókból" nem idempotens. A hálózati kapcsolat megszakadása nem eredményezheti az ilyen hívások többszörös végrehajtását.

A biztonság érdekében az RPC futási ideje az összes hívást nem idempotensként kezeli. Az [idempotens] attribútum nem támogatott ncacn_ip_tcpesetén, és figyelmen kívül van hagyva. Így az előző lista első feltétele arra a kiszolgálóra vonatkozik, amely semmiképpen sem tudja végrehajtani a hívást.

Az RPC futási ideje sok esetben nem tudja egyértelműen megállapítani, hogy a hívás még nem lett végrehajtva a kiszolgálón. Ilyen esetekben az ügyfél nem próbálkozik újra a hívás végrehajtásával.

Az alábbi példák azt szemléltetik, hogy az RPC futási ideje mikor próbál meg vagy nem próbál meg újra hívást kezdeményezni.

• A kiszolgáló újraindul.

  Egy egyszerű, nem biztonsági RPC-hívás egy olyan felületen történik, amelyen az újraindítás után nem történt korábbi hívás. Mivel ezen a felületen nem történt hívás, az RPC futási ideje először megkísérli a felület használatának egyeztetését. Egy csomagot a poolban lévő kapcsolat használatával küld el. Mivel a kiszolgáló újraindult, és a kapcsolat már nem érvényes, hibát ad vissza. Mivel az ügyféloldali RPC-futtatási idő még nem kezdte el az adatok küldését a tényleges híváshoz, az ügyfél megállapítja, hogy a kiszolgáló nem tudta végrehajtani ezeket az adatokat. Ezért bezárja a kapcsolatot, és egy másik kapcsolatot keres a kapcsolatkészletben. Ha nem talál kapcsolatot, új kapcsolatot nyit meg, és megpróbálja újra egyeztetni a felület használatát. Ha ez sikerül, a hívás megtörténik (vagyis egy újrapróbálkozás történik, mert a hibát a hívás elindítása előtt észlelték).

• Az adatvédelmi szintű biztonsággal (titkosítással) rendelkező RPC-hívás egy már egyeztetett biztonsági környezettel rendelkező kapcsolaton történik.

  A hatékony teljesítmény biztosítása érdekében az RPC futási ideje inline, azaz valós időben, titkosítja a szerializált csomagot (a tiszta szöveges adatokon belül). Ha az adatok elküldésére tett kísérlet meghiúsul, az RPC futási ideje nem tudja újrapróbálkozza a hívást, mivel a tiszta szöveges adatok felülírva lettek a titkosított adatokkal, és nem tudja újra titkosítani az adatokat egy új biztonsági környezettel. Ezért nem történik újrapróbálkozás.

• A nem első töredék küldése sikertelen.

  Az újrapróbálkozás nem történik meg, mivel az RPC futási ideje dönthet úgy, hogy elveti az első töredék tartalmát, ha elkészült, és nincs lehetősége az első töredék újraküldésére.

• A rendszer elküldi az RPC-kérést.

  A kiszolgáló megszakítja a kapcsolatot. A rendszer nem kísérel meg újrapróbálkozást, mivel az RPC nem tudja megállapítani, hogy a kiszolgáló megkapta-e a hívást, és megkezdte-e a végrehajtást.

Ha a kiszolgáló dinamikus végpontot használ, az RPC nem oldja fel újra a végpontot az újrapróbálkozás során. Ez azt jelenti, hogy ha egy kiszolgáló le van állítva és újraindul, egy másik végponton helyezkedhet el, és az RPC nem fogja automatikusan újra feloldani a végpontot a hívás újrapróbálásához. A végpont újbóli feloldásának kényszerítéséhez az RPC-ügyfélnek meg kell hívnia RpcBindingReset, mielőtt újrapróbálkozna egy hívást.

Sok ilyen esetben, ha egy RPC-ügyfél meg tudja állapítani, hogy a hívás idempotens-e, vagy megtartja-e az RPC által elvetett adatokat, akkor dönthet úgy, hogy újrapróbálkozási mechanizmust hoz létre az RPC fölé.