Printable View
Zdravim, potreboval bych poradit, jak zjistim, jestli na druhe strane spojeni jeste nekdo prijima moje data nebo ne. Delam jednoduchy chat a kdyz je klient prihlaseny a sestrelim server, tak klient jeste chvili muze psat do streamu na server ... k vyjimce dojde az po nejake dobe a mezitim stihnu poslat treba jeste 2 zpravy ... isxxx metody jsou furt stejne ... nevite nekdo jak se da zjistit, jestli je socket/stream jeste pouzitelny?
Nech si data od serveru potvrzovat.
To se lehce rekne ale hur udela ... musel bych toho celkem dost prekopat ... preci musi existovat moznost, jak zjistit, jestli je spojeni jeste otevreno, nebo uz neni ...Citace:
Původně odeslal mraky
Slusnej srv/klient ti to pri ukonceni rekne - trebas posle rst.
On je maly, ale vcelku patrny rozdil mezi ukoncit a sestrelit ... alespon z meho pohledu ... proste se bavim o ukonceni, kdy mi server uz nic nemuze poslat, protoze proste nema sanci ... napr. hw reset ... hledal jsem ruzne a zatim jsem nasel jen to, ze java to proste asi neumi ... pokud ma nekdo jinou zkusenost, necht se podeli ...Citace:
Původně odeslal Jezevec
Co mas presne na mysli tim "odstrelit"?Citace:
Původně odeslal jaluvkap
Napr. hw reset ... proste situaci, kdy nemam sanci uz ze serveru neco odeslatCitace:
Původně odeslal jedik
Pohrat s setSoTimeout jsi zkousel?Citace:
Původně odeslal jaluvkap
[edit] Po zbeznem guglnuti jsem nasel totok , treba tam bude neco poucneho
Kvuli tomu sestreleni je tam prave ten timeout, nijak jinak to zjistit nemuzes. Muzes si maximalne zmenit timeout, ale u toho pozor, protoze by se ti mohlo lehce stat, ze neco zvojtis a prestane ti fungovat sitovani obecne.
S tim timeoutem to nebude moc staiblni reseni imho. Socket by mel mit property (nevim jak je to v Jave) .Connected nebo .CanWrite a tu bys mohl testovat. Exception trochu trva nez se vypropaguje nahoru. Nevim jak to tam delas, ale pokud mas treba nejaky buffer zprav, tak bys mel premyslet o protokolu (treba BEGIN{pocet_znaku}zpravaEND a cekat na ACK{bytes_received} a pak teprve posilat dalsi zpravu.
O ACKovani se snad stara uz samotny TCP protokol, tak proc to duplikovat?
Pravda o ACKovani se stara TCP ... nakonec jsem to uhral na vlastnost javy ... byl to projekt do jednoho predmetu, takze to proslo ... pro priste se budu drzet pravidla 2xsi prostuduj jazyk a pak navrhuj protokol
Prenos dat urciteho formatu se bez protokolu prakticky neobejde. To o cem mluvis je na urovni socketu kdy pokud neprijde ACK, tak se znovu posle packet, ktery selhal, nebo se ceka na ACK a pak se timeoutne. To ale muze v zavislosti na rychlosti spojeni trvat dele, takze kdyz da timeout na Xms tak mu to muze timeoutovat az se bude divit. Tenhle problem to neresi, neni to ACK serveru, ale socketu na druhe strane. Pokud to dela tak, ze sype data do socketu a na druhe strane si je ze socketu odebira, tak jak prijdou a o nic se nestara, tak mu to bude tohle chovani vykazovat dal. Nejsem si jisty implementaci socketu v Jave, ale jestli to vyuziva winsock (nebo jinou zajimavost podle OS), tak to sype do bufferu a kdyz na drueh strane server spadne, tak bude sypat dal nez se buffer naplni nebo se mu vypropaguje vyjimka. Mel by implementovat jednoduchy protokol (treba to begin{}&end+ack{}) a cekat na ACK serveru predtim, nez zacne posilat dalsi zpravu, to mu zajisti to, ze kdyz se neco potento a server z jakychkoliv duvodu neprijima, tak neposle nic dalsiho a muze vesele vyhodit dialog "previous message in progress". Server nemusi byt jen sestrelen, staci, aby selhalo neco jineho treba ukladani vetsich zprav na disk do mezi bufferu nebo cokoliv jineho.