Jak w Sockecie wykryc ze druga strona zamknela polaczenie?
0
0
Dostajesz wyjatek gdy probujesz pisac lub czytac. Nie ma jako takiej metody Socket.checkIfOtherSideIsConnected() czy podobnej, ktorej pewnie oczekujesz.
0
A jakis callback/event/sygnal w momencie OnOtherSideDisconnect?
Problem polega na tym ze nie bardzo moge wysylac do drugiej strony danych, z kilku powodow.
- druga strona moze byc blackboxem.
- druga strona moze utracic polaczenie z netem i po prostu zmienic swoje ip (moze miec przydzielane dynamicznie)
- ustawienie timeoutu tez nie wchodzi w gre poniewaz drugie strony moga byc roznych typow, moga miec rozne timeouty w zaleznosci od nastawienie wlasnie drugiej strony, to nie ja decyduje o timeoucie tylko druga strona w tym ukladzie. przy czym nie jestem w stanie tego timeoutu odczytac (patrz pkt. 1)
No chyba mi nie powiecie ze JAVA nie posiada tak podstawowej funkcjonalnosci. Bobofrucie ratuj honor JAVY!!!
0
EgonOlsen napisał(a):
Jak w Sockecie wykryc ze druga strona zamknela polaczenie?
Jak druga strona zamknie połączenie poprawnie i dotrze do nas pakiet o tym, to jego InputStream zacznie zwracać -1 przy każdym odczycie.
Wyjątek o zamkniętym sockecie poleci tylko i wyłącznie wtedy, gdy to my zamkniemy socket ze swojej strony.
Wyjątek o socketowym timeoucie poleci, jeśli takowy ustalimy i przez ten czas nie dojdzie żaden odczyt - ale socket nie zostanie przez to zamknięty..
EgonOlsen napisał(a):
A jakis callback/event/sygnal w momencie OnOtherSideDisconnect?
-1
EgonOlsen napisał(a):
No chyba mi nie powiecie ze JAVA nie posiada tak podstawowej funkcjonalnosci.
No, chyba mi nie powiesz, że nie wiesz jak TCP działa, co?
1
Ja rozumiem ze Egon chce zeby np. jak druga strona straci polaczenie z netem, to jeszcze dala rade wyslac cos zeby nasza strona to odebrala i powiadomila wszystkich listenerow o tym fakcie. No przeciez to logiczne, ze jak sie straci neta to jeszcze mozna cos wyslac. Sam nie wiem dlaczego tro sie nazywa 'abnormal termination' lub podobnie, skoro mozna tak grzecznie to wszystko obsluzyc ;d W innych jezykach, rzecz jasna.
0
Kerai napisał(a):
EgonOlsen napisał(a):
Jak w Sockecie wykryc ze druga strona zamknela polaczenie?
Jak druga strona zamknie połączenie poprawnie i dotrze do nas pakiet o tym, to jego InputStream zacznie zwracać -1 przy każdym odczycie.
Druga strona nie musi zamykac polaczenia poprawnie, bo moze np. braknac jej pradu.
Kerai napisał(a):
Wyjątek o zamkniętym sockecie poleci tylko i wyłącznie wtedy, gdy to my zamkniemy socket ze swojej strony.
Wyjątek o socketowym timeoucie poleci, jeśli takowy ustalimy i przez ten czas nie dojdzie żaden odczyt - ale socket nie zostanie przez to zamknięty..EgonOlsen napisał(a):
A jakis callback/event/sygnal w momencie OnOtherSideDisconnect?
-1
EgonOlsen napisał(a):
No chyba mi nie powiecie ze JAVA nie posiada tak podstawowej funkcjonalnosci.
No, chyba mi nie powiesz, że nie wiesz jak TCP działa, co?
Useless...
1
This signal is emitted when the socket has been disconnected.
Tutaj nie ma mowy o tym ze druga strona zostala odlaczona. Ja rozumiem to tak, ze masz socket s i robisz s.disconnect(), i ten sygnal jest wysylany do sluchaczy.
0
Oto co wyczytałem z neta i z tego zrozumiałem:
- W TCP/IP nie da się stwierdzić, że coś jest odłączone bez przesyłania żadnych danych (jest to logiczną konsekwencją tego, iż TCP/IP jest route'owany i jeżeli meteoryt p*dolnie w San Francisco to następnym razem pakiety mogą lecieć przez Los Angeles).
- Jednak TCP/IP przewiduje pakiet ACK, na który zawsze trzeba odpowiedzieć i tą odpowiedzią zajmuje się sterownik (stos) TCP/IP.
- Przy sockecie można ustawić opcję SO_KEEPALIVE. Parametry tej opcji są ustawiane w jądrze i obejmują cały system. Domyślnie pakiety ACK są wysyłane po 2 godzinach od ostatniego otrzymania danych.
- Istnieje metoda Socket.setKeepAlive/getKeepAlive, która pewnie służy do ustawiania tej opcji.
- Oczywiście druga strona nie musi odpowiadać natychmiast na pakiet ACK, mogą być problemy na sieci, etc więc i tak od razu nie da się wykryć zerwania połączenia.
- SO_KEEPALIVE służy tylko i wyłącznie do sprawdzenia czy połączenie istnieje, nie sprawdza czy aplikacja przetwarzająca pakiety po drugiej stronie się nie wysypała.
- Nie jestem pewien jak parametr KeepAlive zmienia semantykę działania, ale chyba sprowadza się to do tego, że wywołanie metody read przy wykryciu braku połączenia od razu rzuca Exceptionem, zamiast czekać na odpowiedź.
Źródło: http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/index.html
Prawidłowym rozwiązaniem jest zaimplementowanie jakiegoś heartbeat'a (tzn wiadomości typu ping/ pong) w protokole, aby móc sprawdzić nie tylko, czy połączenie jest zerwane, ale także to czy usługa po drugiej stronie żyje i ma się dobrze.
2
Czyli tak jak napisalem, dostaja przy okazji minusa, pewnie od Egona - to jest przeciez logiczne, wystarcyz pomyslec jak dzialala te protokoly.
Padl mit EgonaOlsena, najwiekszego jebaki programsity jakiego wydala Ziemia. Ten gosc nie czai jak dziala TCP, cytuje inne jezyki ktore tez tego nie umieja, daje linki do bibliotek ktore tez tego nie umieja. Buahaha. Pewnie motora tez nie ma.