[Javalist] java socket multiple request
János Zsolt
zsoca8711 at gmail.com
2016. Jan. 19., K, 09:36:20 CET
Nálunk is ez van, bár "kicsiben": hetente 2.5 óra fejenként (jellemzően
péntek délután), pár havonta egy egész napos előadás-sorozat.
Az 1 nap sajnos kicsit sok lenne :)
On 2016-01-19 09:08, József Keresztes wrote:
> Sziasztok !
>
> Csak önképzésről van szó, ez is egy szokásos hobby projekt. Kicsit
> eltérve a témától mesélték hogy a skandináv államokban van olyan
> műszaki terület ahol a munkahelyeken 1 héten 1 napot kötelező
> hobby-projekttel tölteni. Nem is hülyeség. Csináltál már 1000 webes
> alkalmazást és azt mondod a főnöködnek hogy most 3 egymás utáni
> pénteken a TCP - UDP rejtelmeivel foglalkozol mert az érdekel,
> kitalálsz hozzájuk új protokolt stb.
> Én benne lennék, de sajnos nálunk ilyen nincs, illetve ha van időd a
> munkahelyen még mindig jobb ilyenekkel foglalkozni mint tetrist
> játszani :)
>
> Joe
>
> 2016. január 18. 22:04 Gabor Szokoli írta, <szocske at gmail.com
> <mailto:szocske at gmail.com>>:
>
> 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
> <mailto: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
> <mailto: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 <mailto: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 <mailto: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
> <mailto: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 <mailto: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
> <mailto: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
> <mailto: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
> <mailto:Javalist at lists.javaforum.hu>
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> <mailto:Javalist at lists.javaforum.hu>
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> <mailto:Javalist at lists.javaforum.hu>
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> <mailto:Javalist at lists.javaforum.hu>
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> <mailto:Javalist at lists.javaforum.hu>
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> <mailto:Javalist at lists.javaforum.hu>
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> <mailto:Javalist at lists.javaforum.hu>
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu <mailto:Javalist at lists.javaforum.hu>
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu <mailto: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/20160119/1e9e780b/attachment.html>
További információk a(z) Javalist levelezőlistáról