Ügyféloldali lefagyások megakadályozása

Az ügyfél kétféleképpen tud lefagyni: a hálózati kapcsolat a kiszolgálókérések elvesztését okozhatja, vagy maga a kiszolgáló összeomlhat. Alapértelmezett beállításokkal az RPC soha nem lép időkorlátba a hívásoknál, és az ügyfélszál végtelen ideig várni fog a válaszra.

Ennek megelőzésére két módszer létezik: folyamatos működés és időkorlátok.

TCP Keep Alives

Az ügyfél beállítható úgy, hogy rendszeres időközönként pingelje a kiszolgálót, hogy a kiszolgáló életben legyen és fusson. A pingek TCP-életben tartást jelentenek a ncacn_ip_tcp és ncacn_http protokollütemezésekhez, és így hatékonyak a processzorhasználatban és a hálózati sávszélességben. Egy adott távoli eljáráshívás életben tartásának engedélyezéséhez használja a RpcMgmtSetComTimeout függvényt a hívás kezdeményezése előtt. Ez a függvény argumentumként egy kötési leírót és egy időtúllépési időt kap. Az RpcMgmtSetComTimeout az RpcMgmtSetComTimeout után minden távoli eljárás meghívja ezt a kötési leírót.

Az RpcMgmtSetComTimeoutfüggvényidőtúllépési paramétere azt határozza meg, mennyi ideig vár az RPC futási idő, mielőtt bekapcsolná a "keep alive"-okat. Az időtúllépés egy 0 és 10 közötti érték, ahol a 0 a minimális időtúllépés, a 10 pedig végtelen időtúllépés (nincs időkorlát). Az időtúllépés önmagában nem másodpercek alatt van; az RpcMgmtSetComTimeout függvény megadott időtúllépési értékről másodpercre történő fordítását az RPC futási ideje végzi, és implementációspecifikus.

Az alábbi táblázat a Windows 2000 és a Windows XP esetén másodpercre történő fordítást tartalmazza. A Windows jövőbeli verziói másodpercek alatt módosíthatják az időtúllépési paraméter és az időtúllépési érték közötti leképezést:

Ha az életben tartás be van kapcsolva, az ügyfél másodpercenként küld egy keep alive csomagot. Ha a kiszolgáló három vagy több "életben tartó" jelzésre nem válaszol, az ügyfél a kapcsolatot megszakadtnak nyilvánítja, és a távoli eljáráshívás sikertelen lesz. Ha a kiszolgáló az előírt időkifutáson belül választ küld, az életben tartás funkció nem lesz bekapcsolva. Ha a kiszolgáló válaszol az életjelekre, de nem válaszol a távoli eljáráshívásra, az ügyfél továbbra is küldi az életjeleket. Amint a kiszolgáló válaszol az RPC-hívásra, a keep-alive kapcsolatokat kikapcsolják. Windows 2000 esetén a Keep Alives csak szinkron RPC-hívások esetén van bekapcsolva. Windows XP esetén az aszinkron RPC-hívások esetében is be van kapcsolva az életben tartás.

Csábító, hogy az aktív kapcsolat fenntartását a legalacsonyabb értékre állítsa, hogy az ügyfélalkalmazás időben reagáljon a hálózati problémákra. Körültekintően kell mérlegelni az ilyen kísértést, és ellenőrizni kell, hogy az agresszív érték indokolt-e. Ha egy kiszolgáló átmenetileg elveszíti a kapcsolatot, előfordulhat, hogy a kapcsolat helyreállítása után számos ügyfél keep-alive üzenetei elárasztják. Emellett a hosszú számítási feladatok több mint két percet is igénybe vehetnek, és előfordulhat, hogy a kiszolgáló több processzoridőt tölt a válaszadással, mint ha hasznos munkát végezne. Ezért az életben tartó mechanizmusokat mérsékelten kell használni. Ha az ügyfél nem tudja elviselni, hogy a szál hosszú ideig meg van kötve, az aszinkron RPC-t kell figyelembe venni.

Más protokollütemezések különböző mechanizmusokat implementálhatnak a nem válaszoló kiszolgálók észlelésére, attól függően, hogy melyik átvitelt használják. A ncalrpc szállítás nem használ életben tartást. Mivel az ncalrpc összes kommunikációja helyi, ha a kiszolgáló nem válaszol a folyamatban lévő hívás alatt, az ügyfélen az RPC futtatókörnyezet azonnal meghiúsítja a hívást.

Időkérések kezdeményezése

A TCP életben tartása rendben van, ha a hálózati kapcsolat megszakad, vagy ha a kiszolgáló összeomlik. Ha azonban a szerver felhasználói módban holtpontba kerül, a TCP keep-alive csomagok sikeresen visszatérnek, de a hívás soha nem fog visszatérni. A forgatókönyv kezeléséhez hozzáadtak egy új futásidejű beállítást a Windows XP-hez: RPC_C_OPT_CALL_TIMEOUT. Ez a beállítás arra utasítja az RPC futási idejét, hogy minden alkalommal beállítson egy időzítőt, amikor kérést küld a kiszolgálónak. Ha az időzítő lejár, a hívás automatikusan megszakad, és RPC_S_CALL_CANCELLED állapottal zárul. Amíg a kiszolgáló a megadott határidőn belül válaszol, az ügyfél nem fogja megszakítani a hívást. Ez azt jelenti, hogy a többtényezős hívások végrehajtása több időt is igénybe vehet, mivel a kiszolgáló minden válasza az időtúllépési időszakon belül érkezik, annak ellenére, hogy az összes válasz érkezési ideje meghaladta az időtúllépési időszakot.

A hívás megszakítása esetén a kiszolgáló nem kap értesítést a lemondásról. A kiszolgáló ezért valószínűleg egy bizonyos ponton végrehajtja a hívást, és az ügyfél egyszerűen figyelmen kívül hagyja a kiszolgáló válaszát.

A hívásleállítások legveszélyesebb buktatója, ha rövid időkorlátot állítunk be, és újra megpróbáljuk a hívást ugyanazon a kiszolgálón. Az alábbi forgatókönyv a megközelítés veszélyeit mutatja be:

Képzeljen el egy kiszolgálót, amely kapacitás közelében működik. Számos ügyféllel rendelkezik, akiknél az időtúllépések nagyon rövidek, például öt másodperc. Az ideiglenes hálózati kapcsolatkiesés vagy egy útválasztónál fellépő torlódás néhány másodpercre megszakíthatja a kiszolgálói válaszokat. Ethernet-hálózatokon ezt a helyzetet könnyen okozhatja egy olyan kapcsolaton végzett tevékenységkitörés, amelyet a kiszolgáló egy másik géppel oszt meg. A kiszolgáló nem tudja elküldeni az összes választ az öt másodperces időtúllépés előtt. Az ügyfelek megszakítják a hívásaikat, és azonnal újra próbálkoznak. A kiszolgáló nincs tisztában azzal, hogy a hívások ismétlődések, így azokat is végrehajtja. Így a hívások normál számítási feladatainak végrehajtása helyett 30-50% több hívást hajt végre attól függően, hogy hány ügyfél időtúllépést eredményezett. Ha ez meghaladja a kapacitását, és a kiszolgáló öt másodpercen belül nem tud válaszolni az összes ügyfélre, a rendszer újabb hívásokat küld a kiszolgálónak. Az ügyfelek továbbra is ugyanazokat a hívásokat bocsátják ki, és mivel a kiszolgáló túlterhelt a korábbi hívások feldolgozásán, nem tud válaszolni az időkorláton belül. A válasz után az ügyfelek időtúllépést észleltek, új hívást adtak ki, és elvették a választ. Legrosszabb esetben a kiszolgáló csak az újraindításig áll helyre, és az ügyfélhozzáférési mintától függően előfordulhat, hogy nem áll helyre, amíg elegendő számú ügyfél le nem áll.