[Javalist] java socket multiple request
Gabor Szokoli
szocske at gmail.com
2016. Jan. 18., H, 22:04:34 CET
Szia!
Ha ez eles project, akkor meselj meg a kovetelmenyekrol, es segitunk
protokollt/konyvtarat valasztani.
Ha mar mukodo rendszer, es az ujrakonnektalagatas nem okoz
teljesitmenyproblemat, ne piszkald:
https://sites.google.com/site/interactiveflowchart/
Feltetelezve, hogy onkepzesrol van szo, a HTTP-t pedig gondolom ismered,
ott pont erre valo a Content-Length header, illetve a chunk meret minden
chunk elejen. Arra keress ra, hogy "Connection: keep-alive", meg
"Transfer-Encoding: chunked"
Lehet specialis karakterrel/karaktersorozattal is jelolni az uzenet veget,
de akkor az a karakter/sorozat az uzenetben nem fordulhat elo, ha megis,
akkor escape-elni kell, es azt mindenki utal.
Hasznalhatsz TCP helyett UDP-t, ha minden uzenet kisebb 64K-nal,
felcserelodhetnek uzenetek, es nem baj, ha neha egy-egy elvesz.
(ahanyszorosa az uzenet merete az MTU-nak, annal kevesbe "neha"...)
Van (Volt? Lesz?) olyan is, hogy SCTP, ami sok minden mas mellett azt is
tudja, amit te szeretnel, de ugy tunik csak DC tapos servereken mukodik (en
legalabbis mindig csak telco-knal latom.) De erdekes, es talan egyszer majd
elterjed.
Szocske
2016-01-18 8:07 GMT-05:00 Dénes Medzihradszky <medzihradszky.denes at gmail.com
>:
> 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
>>
>>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20160118/5e5088e7/attachment.html>
További információk a(z) Javalist levelezőlistáról