Diskuze: Tcp - ukončení servru
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.

Člen

Zobrazeno 7 zpráv z 7.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
Ze serveru si musíš při ukončování poslat zprávu, podle který poznáš, že máš klienta odpojit.
Díky, ale tohle řeší jen půlku mého problému. Co když server spadne nebo se nějak přeruší spojení.
Nezbývá ti než třeba každých třeba 5 sekund to spojení kontrolovat a pokud do dalších 5 sekund neodpoví, tak spadl - odpojit.
servery by ale neměly moc často padat a když k tomu dojde, prostě nastane nějaká chyba. Však to je jedno, spadlý server ti v aplikaci nijak nepomůže.
Ahoj,
jak už zde bylo řečeno výše, pokud server bude ukončovat spojení, měl by o tom informovat klienty kteří na to adekvátně zareagují (odpojí se).
To jak budeš zjišťovat zda je server dostupný záleží na povaze aplikace. Buď můžeš v určitých časových intervalech posílat na server něco jako ping a čekat na odpověď s tím že pokud nepříjde, budeš server považovat za nedostupný. A nebo pokud ti stačí s o nedostupnosti serveru dozvědět až ve chvíli kdy posíláš data, hoď to do try-catch bloku (tomu se stejně nevyhneš).
Ono obecně, neboj se ten try-catch blok používat, vliv na výkon to samozřejmě má, ale znatelné to je až ve chvíli kdy ho voláš opravdu hodněkrát během krátké chvíle. Neříkám že by se měl cpát všude, ale obecně bych doporučoval ho používát "za vrátky" tvé aplikace. Tzn. všude tam kde se může cokoli stát vinou někoho jiného (špatné spojení, nefunkční server, poškozený soubor atd.) a ty to nemůžeš nějak ovlivnit.
Díky, doufal jsem ze to nebudu muset použít ale vypadá to že ano. Jen doufám, že to přece jen neubere moc výkon.
Zobrazeno 7 zpráv z 7.