[Javalist] java socket multiple request

2016. Jan. 18., H, 14:07:41 CET

Zsombor tökéletesen megfogalmazta a megoldást, de Magyusznak is igaza van :)

Valóban arról van szó, hogy az összetartozó  bájtsorozat (nevezzük
message-nek) átküldése után ezen a szinten nekünk kell valamilyen jelet
kitalálni, amit a kliens és a szerver is ismer és ezzel jelezhetjük a
szervernek, hogy a teljes üzenet átment.
Ha belegondolunk, rajtunk kívül senki sem tudja, hogy mit is jelent az
átküldött bájtsorozat.
Van viszont egy alternatív megoldás, a DatagramPacket, ami nem TCP, hanem
UDP alatt működik. Ott egyértelmű, hogy egy átküldött üzenet van csak a
csomagban.

Csatolom a mintakódokat.

Dénes

2016-01-18 13:51 GMT+01:00 Zsombor <gzsombor at gmail.com>:

> Erre szoktak kitalálni protokollt, hogy ilyen probléma ne forduljon elő :)
>
>
> Üdv
>
> 2016-01-18 13:00 GMT+01:00 József Keresztes <xesj.hu at gmail.com>:
>
>> Sziasztok !
>>
>> Megkaptam Dénes mintakódjait is köszönöm, azt is átnéztem.
>> Közben megfogalmazódott egy kérdés, amibe most bele is futottam, de csak
>> azért mert szerettem volna mélyebb szintre menni, és tényleg megérteni hogy
>> működik a dolog. A probléma a következő:
>>
>> A TCP kliens szépen elkezdi küldözgetni a byte-okat a szervernek az
>> OutputStream-en keresztül, a végén a flush() metódust is meghívja, majd a
>> bájtsorozat átküldése után elkezdené olvasni az InputStream-et.
>> A probléma az hogy a TCP server nem tudja hogy vége a byte-sorozatnak,
>> mert ugye honnan is tudná ??? Márpedig ő vár egy EOF jelre (-1), vagyis
>> kialakul egy olyan holtpont hogy mindkettő a másikra vár.
>> *A kliens az utolsó bájt átküldése után hogy jelezze azt hogy nincs több
>> küldendő adat ?* A neten erre azt a választ találtam hogy a kliens egy
>> close()-zal zárja le az outputstream-et, csakhogy akkor nincs több
>> kommunikáció, tehát ez nem jó megoldás.
>>
>> Addig persze nekem is jó volt a mintapéldám amíg magasabb szintű
>> DataOutputStream-mel bohóckodtam, és readUTF(), writeUTF()-fel küldözgettem
>> az adatokat, de most kizárólag natúr InputStream, OutputStream-met
>> szeretnék használni mindenféle varázslat nélkül.
>>
>> Joe
>>
>>
>> 2016. január 16. 10:32 Zsombor írta, <gzsombor at gmail.com>:
>>
>>> Ha az egyik oldal lezárja a socket-et, akkor az a másik oldalon is
>>> lezárul - a távolságtól függően pár milliszekundum múlva. Ettől
>>> függetlenül, ha csak nem zárja le a ServerSocket-et a szerver, ugyanúgy tud
>>> újra kapcsolódni a kliens.
>>>
>>> 2016-01-15 13:17 GMT+01:00 Dénes Medzihradszky <
>>> medzihradszky.denes at gmail.com>:
>>>
>>>> Üdv a listának!
>>>>
>>>> Nincs itt valami félreértés?
>>>> A kliens socket nem zárható le a szerver által, a szerver max a saját
>>>> socketjét zárhatja le - amit pl a ServerSocket-től kap - hiszen a kliens
>>>> tipikusan egy másik JVM-ben fut.
>>>> Inkább arról van szó, hogy a szerver oldali socket lezárásával a kliens
>>>> már nem tud ismételten kapcsolódni.
>>>> Oktatóprogramjaimban itt végtelen ciklusok pörögnek, és/vagy a
>>>> ServerSocket kapcsolódáskor - accept() - külön szálat indít a létrejött
>>>> socket objektummal.
>>>>
>>>>
>>>> Dénes
>>>>
>>>> 2016-01-15 12:48 GMT+01:00 József Keresztes <xesj.hu at gmail.com>:
>>>>
>>>>> Azt hiszem közben megoldódott. A szerver oldalon lehetett a hiba,
>>>>> ugyanis:
>>>>>
>>>>> Socket socket = serverSocket.accept();
>>>>> ...
>>>>> // input olvasás, output írás
>>>>> ...
>>>>> socket.close();
>>>>>
>>>>> és ez utóbbi miatt a kliens socketet a szerver zárta le, így a kliens
>>>>> már nem tudott több kommunikációt kezdeményezni.
>>>>> Valszeg a kliens és szerver kzötti kommunikációt kell egyeztetni (egy
>>>>> protokolt kitalálni) mikor és ki zárja le a kapcsolatot.
>>>>> Köszönöm a netty ötletet, de engem most pont a low level szint érdekel.
>>>>>
>>>>> Joe
>>>>>
>>>>>
>>>>> 2016. január 15. 12:34 László Magyar írta, <magyarl05 at gmail.com>:
>>>>>
>>>>>> Üdv,
>>>>>>
>>>>>> Ajánlanám TCP és egyéb I/O kommunikációra a netty <http://netty.io/>
>>>>>> projektet, ami a "low level" dolgokat elintézi.
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2016. január 15. 12:27 József Keresztes írta, <xesj.hu at gmail.com>:
>>>>>>
>>>>>>> Sziasztok !
>>>>>>>
>>>>>>> A neten keresgéltem, de nem találtam a problémára megoldást.
>>>>>>> A lényeg hogy TCP-s kommunikációt szeretnék egy szerverrel.
>>>>>>> A kliensben létrehozok egy Socket objektumot, és ezzel a socket-tel
>>>>>>> akarok
>>>>>>> több kérést(választ) csinálni. Tehát csak egyszer akarom a Socket-et
>>>>>>> létrehozni,
>>>>>>> majd ezen a csatornán írnék az outputstream-be, és olvasnám az
>>>>>>> inputstream-et,
>>>>>>> majd ismét írnék az outputstream-be, és olvasnám az
>>>>>>> inputstream-et...stb.
>>>>>>>
>>>>>>> A neten csak olyan példát láttam hogy a kliens egy kérés-válasz után
>>>>>>> lezártja a socket-et.
>>>>>>> Ha akar valamit újra létrehozza. Nekem ez kicsit furcsa, igaz
>>>>>>> méréseim szerint a gépemen egy socket 10-20 ms alatt létrejön, de miért
>>>>>>> kellene minden egyes kérésnél újra létrehozni ?
>>>>>>>
>>>>>>> Java-tól függetlenül: én eddig úgy gondoltam ha pl. egy adatbázishoz
>>>>>>> be vagyok jelentkezve egy klienssel, és percenként küldöm el az
>>>>>>> SQL-parancsaimat, akkor nem kezdi el mindig felépíteni nulláról a
>>>>>>> kapcsolatot az adatbázissal.
>>>>>>>
>>>>>>> Joe
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Javalist mailing list
>>>>>>> Javalist at lists.javaforum.hu
>>>>>>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Javalist mailing list
>>>>>> Javalist at lists.javaforum.hu
>>>>>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Javalist mailing list
>>>>> Javalist at lists.javaforum.hu
>>>>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Javalist mailing list
>>>> Javalist at lists.javaforum.hu
>>>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Javalist mailing list
>>> Javalist at lists.javaforum.hu
>>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>>
>>>
>>
>> _______________________________________________
>> Javalist mailing list
>> Javalist at lists.javaforum.hu
>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>
>>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20160118/f6cfc5dd/attachment.html>
--------- következő rész ---------
A non-text attachment was scrubbed...
Name: udp.zip
Type: application/zip
Size: 1279 bytes
Desc: nem elérhető
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20160118/f6cfc5dd/attachment.zip>