"Lepsze wykrywanie utraty połączenia z serwerem."
Można prosić o krótkie wyjaśnienie ?
v. 23.02.01
-
pzygmunt
- Posts: 20302
- Joined: Tue Jan 19, 2016 9:26 am
- Location: Paczków
- Been thanked: 59 times
Przy wywołaniu funkcji SSL_read sprawdzamy rezultat. Jeśli jest równy 0 to oznacza, że połączenie zostało zerwane.
Przy -1 powinno się sprawdzić SSL_get_error czy zwraca SSL_ERROR_SYSCALL lub SSL_ERROR_SSL co też może świadczyć o tym, że połączenie zostało zerwane. Celowo tego jednak nie robiliśmy ponieważ praktyka pokazała, że nie zawsze to oznaczało zerwanie połączenia przez drugą stronę, a dokładniej rzecz ujmując jeśli serwer sprawdzał SSL_get_error to w czasie testów obserwowaliśmy problemy z niektórymi urządzeniami. W związku z powyższym przez lata serwer sprawdzał tylko rezultat z SSL_read, a dodatkowo sprawdzał kiedy ostatnio klient/urządzenie przesłało jakieś dane. Ten sam kod dotyczy aplikacji klienckich więc tam to wyglądało tak samo choć miało mniejsze znaczenie z uwagi na liczbę połączeń równą 1.
Od jakiegoś czasu zaczęliśmy obserwować problem w aplikacjach klienckich, który zwykle uwidaczniał się wtedy gdy dokonywano zapisu ustawień na cloud.supla.org co wymusza restart połączenia. Problem objawiał się tym, że aplikacja traciła połączenie ale o tym nie wiedziała.
Użytkownicy zgłaszali np., że zmienili nazwę kanału, a w aplikacji nic się nie zmieniło. Być może problem się ujawnił przy którejś zmianie wersji ssl-a. Tak czy inaczej po zreprodukowaniu problemu u nas rozwiązaniem okazało się sprawdzanie SSL_get_error po stronie aplikacji klienckich. Po stronie serwera weryfikacja połączenia pozostaje bez zmian.
Przy -1 powinno się sprawdzić SSL_get_error czy zwraca SSL_ERROR_SYSCALL lub SSL_ERROR_SSL co też może świadczyć o tym, że połączenie zostało zerwane. Celowo tego jednak nie robiliśmy ponieważ praktyka pokazała, że nie zawsze to oznaczało zerwanie połączenia przez drugą stronę, a dokładniej rzecz ujmując jeśli serwer sprawdzał SSL_get_error to w czasie testów obserwowaliśmy problemy z niektórymi urządzeniami. W związku z powyższym przez lata serwer sprawdzał tylko rezultat z SSL_read, a dodatkowo sprawdzał kiedy ostatnio klient/urządzenie przesłało jakieś dane. Ten sam kod dotyczy aplikacji klienckich więc tam to wyglądało tak samo choć miało mniejsze znaczenie z uwagi na liczbę połączeń równą 1.
Od jakiegoś czasu zaczęliśmy obserwować problem w aplikacjach klienckich, który zwykle uwidaczniał się wtedy gdy dokonywano zapisu ustawień na cloud.supla.org co wymusza restart połączenia. Problem objawiał się tym, że aplikacja traciła połączenie ale o tym nie wiedziała.
Użytkownicy zgłaszali np., że zmienili nazwę kanału, a w aplikacji nic się nie zmieniło. Być może problem się ujawnił przy którejś zmianie wersji ssl-a. Tak czy inaczej po zreprodukowaniu problemu u nas rozwiązaniem okazało się sprawdzanie SSL_get_error po stronie aplikacji klienckich. Po stronie serwera weryfikacja połączenia pozostaje bez zmian.
SUPLA.... Nareszcie w domu.