Názory k článku Síťování v Javě: Úvod
-
Zajimavy pristup, pouzit vice vlaken. Proc to delat jednoduse, ze ;-))
Copak se v Jave neda pouzit neco na zpusob syscallu select(2)? Tzn. funkce/trida ktere predam pole streamu ze kterych chci cist (stdin, net) a ona bude cekat az do doby nez jeden z tech streamu ma k dispozici data. Pak mi rekne ktery to byl a ja muzu vesele pokracovat. To je, rekl bych, mnohem jednodussi a standardnejsi pristup nez machrovani s threadama... -
Jednak je rozdil mit thready dva nebo jich mit dva tisice, kdyz mate tisic spojeni.Tak to je určitě rozdíl.
A potom, nejde ani tak o rychlost, jako o jednoduchost kodu (s thready musite davat bacha, co musi byt synchronized atp.)To bych ani neřekl. Přece jen se každý thread stará o své vlastní spojení a s ostatními "spojovacími" vlákny nemá důvod komunikovat. Jediné, co je nutné synchornizovat (ale to vždycky), jsou objekty společné všem vláknům. Psal jsem (přiznávám, jednoduchý) komunikační program pro LAN (v C#) a pro každého uživatele, kterého jste měl v seznamu, běžel jeden thread, který zjisťoval jeho stav (tj. to vlákno bylo skoro pořád ve stavu sleep) + další vlákna pro otevřená okna, kde jste si chatoval s tím daným uživatelem. Rozdělení do threadů bylo velmi jednoduché a přineslo daleko větší možnosti. Max počet vláken toho programu co jsem zkoušel byl 60, což není vůbec moc.
-
Dovolil bych si podotknout, ze pokud v Jave pouzivate GUI - a urcite i v jinych pripadech (zalezi na implementaci dotycne oblasti) - tak Vase aplikace JE vicevlaknova, aniz byste se toho jako aplikacni programator ucastnil... Takze hrani si na pidimetry vykonu pres Select/Poll aniz bych znal technologii mi prijde usmevne...:-)
-
Ale ono je to tak správně. Tento přístup (neblokující) se v praxi samozřejmě využívá s několika vlákny, nejen s jedním. Jejich počet je ale výrazně nižší (např. roven násobku počtu procesorů - 4, 8 a podobně). Dost dobře nechápu Tvůj komentář. Jinak ale přístup s více vlákny zde bude pořád - někde se třeba hodí lépe.
-
Dost dobře nechápu Tvůj komentář.
Pouze mě zaráží, že se "tolik" píše proti použití vlákna na každé spojení. Nic víc nic míň.
I procesory x86 udělali hodně velký pokrok, co se týče zpracování mnoha procesů (např. rychlejší přepínání kontextu, masivní paralelismus uvnitř CPU -- na GPU to ještě nemá, ale snad časem, "inteligetní" prefetch do cache). A bude se to zlepšovat. Budou přibývat jádra, zvětšovat se cache, měnit se celá architektura PC (AMD například používá NUMA ve svých multiprocesorových řešeních, místo "klasického" SMP na FSB jak má Intel). Tak nevidím důvod, proč nemít v programu třeba 512 vláken. Možná se mýlím a rád se nechám poučit.
-
Palo (neregistrovaný)Treba rozlisovat medzi Threadmi na klientovi a v servri. Na servri treba setrit pretoze uz iba kontext switching medzi 1000 threadmi ti zozerie dost velku cast CPU.
Na servri je pouzitie select() nevyhnutnostou. Specialne co sa tyka triedy java.net.Socket ma problem ze za urcitych okolnosti nie je mozne rozlisit ze socket bol z druhej strany zatvoreny (programovo alebo z dovodu sietovej chyby) takze takto napisany server po case lahne.
Nadmerna zataz (sietova,...) zlozi akykolvek server. V dobrom servri ktory ma byt odolny aj proti DoS utoku musis mat dobre vyriesene fronty, cakacie stavy a aj odmietanie poziadaviek. -
Blera (neregistrovaný)V baliku NIO samozrejme select() je a i ostatni veci tady funguji na podobnem principu, jako v "C-cku".
S temi vlakny je spis problem ten, ze pokud bude tech komunikaci vice, pak nam vlakna budou narustat a narustat.
Druha vec je ta, ze uvedeny kod se netyka Telnet klienta, ale TCP trubky. Telnet zpracovava signaly typu Ctrl-C, Ctrl-Z a podobne veci, ktere by zarizeni typu TTY melo umet. -
Jarda (neregistrovaný)Takze misto 'machrovani s Threadama' (= dvakrat pouziti stejne jednoduchoucke tridy) nasadime nejake podminky/pomocne struktury na rozhodovani kam se ma zapisovat, zacneme resit problemy se zablokovanim vystupu a tim padem zablokovanim obsluzneho vlakna atd? Tomu se ted rika jednoduchost?:)
Vzhledem k tomu, ze melo jit o jednoduchou ukazku prace se siti, tak je to imho v pohode, az budete mit server obsluhujici tisic spojeni najednou, tak jsou selecty na miste. A co se standardnosti tyce, tezko rict, ale co jsem videl, tak mi prijde, ze se tenhle pristup opravdu hodne pouziva, prace s vlakny je v Jave jednoducha a dokud jich staci par... -
Straw (neregistrovaný)Tak za takovýhle kód bych vraždil. Pokud uzavírám stream, socket, a já nevím co všechno ještě, vždycky ve finnaly bloku. Možná budete namítat, že tohle je jen "ukázkový zdroják", ale pak k vám přijde do týmu nějaký ucho, co se učí z článků na internetu a dělá takovýhle prasárny a diví se, že má stovky neuzavřených connection třeba na databázi.
-
Po přečtení následujících komentářů je mi jasné, že s vámi je zbytečné se bavit, ale dneska mám dobrou náladu.
Takže, představme si výstup na konsoli z nějakého prográmku na zpracování speciálních obrázků:
$imageprocess: -i image.bin -offt image.fft -ostats image.stats
Processing Image
[Warning] Image file is in deprecated format, version 0.5.
[Warning] Image does not contain statistical information.
Starting Fast Fourier Transformation...
[Warning] Image size is not compatible with FFT, cropping image.
Done
Gathering Statistical Information...
Done
image.fft Saved
image.stats Saved
Takhle by to vypadalo po vypisu všeho do System.out. A to jsem vzal ještě mírnější versi, kde nenastaly ty "velké chyby", kterých může být klidně přes sto. Uživatel ví, že obrázek není čtvercový a že se bude ořezávat, uživatel ví, že v obrázku staré verse nejsou statistické informace. Proto preferuje výpis:
$imageprocess: -i image.bin -offt image.fft -ostats image.stats 2&>/dev/null
Processing Image
Starting Fast Fourier Transformation...
Done
Gathering Statistical Information...
Done
image.fft Saved
image.stats Saved
Zdá se mi to přehlednější, vám ne? A ten váš very simple grep není všude a ne každý s ním umí pracovat. Přesměrovnání do souboru ano. -
A ja pro zmenu trvam, ze chybove hlasky patri tam, kam je ocekava obsluha, aby na ne mohla aktivne a adekvatne reagovat... coz je treba remote konzola, nejake sofistikovane zarizeni, soubor atd... - to, ze lze zajistit presmerovani FD 2 na jine (s omezenimi) je z historickych duvodu a neodpovida soucasnym potrebam... - log4j je dobry priklad, jak to resit... To, ze Cckari tuto vymozenost bezne neznaji, jednoduse proto, ze GLIBC nic takoveho neobsahuje, neznamena, ze tato potreba neni i zde... - treba ovladani technologickych procesu (jichz jsem se ucastnil) bylo sice implementovano v C, ale jiz pred 15 lety byly potreby naprosto shodne s tim, co umoznuje log4j... - (log4c neexistovalo) takze opakuji - stderr je hezky, historicky, ale neodpovida casto potrebam... zejmena pokud potrebujete dalsi veci - muzete mi rici, jak FD 2 "presmerujete" do Event loggeru ve Win32 platforme?
-
kvr (neregistrovaný)... z hlediska navrhu by me spis zajimalo, co tam dela ta dedicnost??
Ad close() - namet na flame ;) : tady to neni az tak moc videt, ale k cemu je mi pak cely ten system s garbage collectorem, kdyz se o lifetime objektu (coz v tomto pripade defakto close je) musim starat sam? To sme pak nekde zpatky pred 20ti lety na strukturovanem programovani :-/ -
Straw (neregistrovaný)V případě soketů se při ukončení JVM ten socket zavře, ale obecně je to pěkně fuj. Vezměte si například spojení na databázi, kde je to "obdobné", jenže než se GC dostanek tomu, aby ty objekty zlikvidoval, tak vám ty spojení dojdou. Nehledě na to, že se ve větších aplikacích používá ConnectionPooling, takže reference na Connection stále je, ale vy ji neuzavřete, takže si tam prostě visí dokud nedojdou spojení.
-
Culibrk (neregistrovaný)Aha, takze kdyz chci udelat jednoduche IP spojeni, pak musim pouzit connection pool, protoze jiny pristup v Jave je riskantni. Neni to nahodou "trochu" narocne na systemove prostredky?
Jiste, Java neni na kdejakou utilitku, je to "nastroj" pro velke masiny, kde je (casto) vykonu na rozdaj. Trebaaaaa - hm, treba mobil! :-D
PS: V Jave ani Basicu nekoduju, protoze jsem si zvykl delat design v jistem smyslu objektovy. Neberte to jako osobni utok, jen se strasne bavim na ucet <no flame please> tech cvoku co Javu vymysleli a tech, co si mysli, ze je to v poradku. </no flame please> -
empty (neregistrovaný)Vlakna jsou fajn, uz jsem je nekolikrate pouzil, vzdy to prisli tak nejak jako
blesk z nebe, problem bude, ze a ted nechci soudit, jim tady stejne nikdo
poradne nerozumi, vcetne me. Bez urazky.
Proti selectu(poolu) taky nemam nic, kdyz je dobre pouzit je tez fajn.
pochopitelne vyuzivat stderr, o tom zadna. stejne jako uvolnovat spojeni,
to vi kazdy, flush() je super bez diskuze, klasicky duraz na cem bazirujou na
skole, kontrola navratovych hodnot a to i u takoveho close() !
Osobne nemam rad Javu, proto bijte ji dokud nezdechne. Jen zertuji,
sitove programovani v Jave je stejne useless, ping v ni nenapisete, tak
cemu to. Enjoy JDBC(silene rozhrani). bytecode is useless.
42. A co slysi webmaster ve vlaku? TD TD TD, http://hovnocucy.predseda.com/; init 0 -
Palo (neregistrovaný)- Ak nerozumies threadom tak si to dostuduj. Ja si myslim ze im rozumiem dost dobre.
- Multithreading v klientskych aplikaciach nie je problem. 2-6 threadov je absolutne v pohode. Na problemy na dnesnom zeleze narazite tak pri 80-140 threadoch. Threadmi treba setrit v server aplikaciach.
- NIO a select v jave ma jeden vedlajsi problem. Suvisi to z blokovacimi readmi a serializaciou.
- close() je bez diskusie ale musi byt vhodne pouzite. Tiez to nie je celkom logicke. Ucebnicovy priklad:
FileInputStream fInput=new FileInputStream("aa.txt");
try {
fInput.....
} catch (Exception ex) {
ex.printStackTrace();
} finally {
fInput.close();
}
Kedze ale aj new FileInputStream moze vyhodit FileNotFoundException tak najlepsie to bude vyzerat asi takto:
FileInputStream fInput=null;
try {
fInput=new FileInputStream("aa.txt");
fInput.....
} catch (Exception ex) {
ex.printStackTrace();
} finally {
if (fInput != null) {
fInput.close();
}
}
- A na zaver aj odkaz pre ostatnych: "Na javu mi nesahajte". -
Culibrk (neregistrovaný)Dyd jo, v poradku. Jen me dorazilo, jak to vypada: 2 thready jsou OK. No, aby nebyly! Cekal bych neco jako "20 thready je ok" nebo lepe "200 threadyu je ok". Nic proti, to jen tak na vysvetlenou. Treba tvuj prispevek z "Dnes 1:20" by se mel tesat do kamene. Tak to jen tak na vysvetlenou.
Ano, vesela kopa jsem, protoze je patek a bavime se o Jave. To nejde prezit jinak nez s usmevem.
Hezky den. :-) -
kvr (neregistrovaný)Fajn, zpatky k tematu ke close(), neucebnicovy, avsak realnejsi priklad:
try {
fout = new FileOutputStream("aa.txt");
log1 = SomeLogger.createUsingStream(fout);
log2 = SomeLogger.createUsingStream(fout);
create more objects using fout, log1, log2
}
catch (whatever) {
}
finally {
fout.close();
throw FailedInitialization();
}
... some stuff, use created objects in threads, ...
A kdo ted zavola close() na fout? Tohle vyresil napr. COM uz pred 15-20ti lety ;) -
Dobrý den,
mám problém s kódem zmíněným v článku. Když tento kód spustím, tak čekám docela dlouhou dobu, a poté mi to jenom napíše "Vstupní proud uzavřen." a pak se program ukončí. Argumenty hlavní metody používám stejné, jako jsou v příkladu (www.google.com, port 80).
Děkuji za odpovědi. -
No ty sa pripajaš na HTTP server.
Preto musiš ešte zavolať metodu
"GET / HTTP/1.1" //vyziadas si dokument z rootovskeho adresara web servra
a ešte zadaš "Host: www.google.com" //cim specifikuješ v pripade virtualnych web servrov z ktoreho chceš dany dokument stiahnuť, ale aj keby si nemal virtualne servre tak v HTTP GET hlavicke sa tento udaj vyplna automaticky.Tieto udaje už nie su sučasťou tohto telnetu ale metodami HTTP protokolu (hlavičiek), ktore sa vo web prehliadaci vyplňaju automatcky.
ČLÁNKY DO MAILU