[Javalist] java socket multiple request

József Keresztes xesj.hu at gmail.com
2016. Jan. 19., K, 09:08:43 CET


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>:

> 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
>>
>>
>
> _______________________________________________
> 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/210b5d31/attachment.html>


További információk a(z) Javalist levelezőlistáról