BufferedReader input = new BufferedReader(new InputStreamReader(S.getInputStream()));
Ez jó vezető feljesztő :-)))))))))))))))))
Na akkor én most erre nem ragálnék mert még valami olyat irok amit megbánok.
Kössz hogy lenézel. Ezt Viszonzom és akkor én is semmibe veszlek ha megenged ha nem.
JAVA ban tényleg nem vagyok profi de. inkább haggyuk.
Másrészről olyan C++ -os programmal is kommonikálnia kell aminek közel sincsen meg a forássa mert egy külső cég fejlesztette aki meg becsődölt.
Leirom megint hátha nem jutott el a tudatodig mit irtam. Szóval megoldotam és mőködik.
Részemről a téma ejtve.
egyrészt írnék az aszinkron kommunikációról: IBM MQSeries. Nem triviális implementálni, speciális eseteit talán.
Másrészt egyértelmű, hogy benned a hiba, ha nem tudnak a Java és egyéb progrjamjaid összebeszélni. Amit mondasz, az típusos amatôr hiba: "nem csinálja". A BufferedReader egy streambôl olvas be, ami lehet IP csatorna, file, stb. Lehet probléma a buffer méretével (mert ez ugye, bufferelt), és valszeg mind a Java kliens, mind a Java szerveroldalon a default bufferméretet használod, és csodák-csodája, megy, míg az összes többi leszottyan. Egyáltalán, minek neked ez BufferedReader, miért nem sima socket kapcsolat, és arra egy InputStreamReader? A Java-ban ez nagyon szépen és általánosan van megírva, kezdôként nehéz a megfelelô osztályt kiválasztani.
Ha bevallottan amatôr vagy, kicsit kisebb arccal kellene közelítened a témához. Én vezetô fejlesztô vagyok egy cégnél, Javaban írok alaprendszereket, eddig nem találkoztam ilyen jellegű problémával, vagy ha igen, megoldottam, mert meg lehet. Nagyon kevés dolog van a Javaban, amit effektíve nem lehet megoldani, de azok nem ezen a szinten keresendôek, fôleg op.rendszer-specifikusak.
Hol lehet a JTable-nél letíltani, hogy az oszlopait ne lehessen a headernél megfogva összevissza felcsrélgetni?
A nyomtatásra még mindig várom a választ:
g.getFontMetrics().stringWidth(a)
printelés esetében mértnem ad vissza helyes értéket, mért csak a képernyőre történő kiírásnál megy rendesen? Progi részlet alább már leírva.
vakpal!
Te milyen java fórumot találtál, ahol segítettek? Nagy szívások közepette vagyok, és ez a java forum nem valami mozgalmas!
Én azért kérdeztem mert azt hittem akad itt olyan aki ért is hozzá egy kicsit.
Bocsesz mit is kérdeztél? Elolvasgattam írásaidat, ezt a szálat a következő kérdésed indította el:
Miért van az, hogy a JAVA egyetlen más programnyelven megirt programmal sem képes TCP/IP -n keresztül kommunikálni?
Erre a kérdésedre kielégítő választ kaptál:
Nem igaz, hogy a JAVA csak JAVA-ban megírt progival képes kommunikálni.
Eme kérdés óta az adott témában nem hangzott el újabb kérdés, így végülis nem értem: mire vártál választ?
Mostmáraztán tényleg ez volt az utsó. (bár még el lehetne morfondírozni azon,ki az amatőr/kezdő,de ennek itt semmi értelme)
Na látom kár volt ide irnom.
Más fórumon egyből megértetteék miről van szó.
És meg is van oldva a probléma.
Ha nem érted a kérdést az a te bajd, de forást nem fogok leközölni mert ez a cégbirtokában van.
Nem tudom neked hogy sikerült megálapitani, hogy kezdő vagyok. JAVA és C++ esetén igy van.
Valahogy rühelem ezeket a nyelveket.
De Ugy látom te még a 2000 soros programnál nem jutottál tovább. Ezeket hivájk amatőröknek.
Kezdőknek vagy ahogy akarod.
De a probléma megoldva.
Kössz a nagy semmit. de ha nem érteszz hozzá akkor inkább ne szólalj meg.
Én azért kérdeztem mert azt hittem akad itt olyan aki ért is hozzá egy kicsit. De tévedtem.
Kötözködni lehet, de nem érdemes. Én csak azt állítom, hogy amit te a Dzsáva hibájának tudtál be, az nem létezik. A kliensemet én nem írtam újra, a szerverrel kellett pepecselni egy kicsit, hogy minden okés legyen.
A kék könyv nem jó, de jobb magyarnyelvű, írott irodalmat nem találsz Dzsávához.
A C++ -os progit nem kellene minden platformra újraírnod. Jó tervezés mellett csak néhány osztályt (vagy függvényt) kellene újraírni a különböző platformokra. Adott protokolú hálózati kommunikáció esetén ez kb 100 sor újraírását jeleni platformonként (bár a UNIX szerű rendszerek között, lehet, hogy ennyit sem).
Amúgy milyen segítséget vársz? A klienshez nem akarsz hozzányúlni (ismét csak arrol a 100 sorról írok), Dzsávában meg nem tudsz megírni egy 15 soros függvényt (amivel az adatok fogadását lekezelnéd). Olyan problémát nem vetettél fel, amit meg lehetne válaszolni.
Elöbb tanulj meg programozni, aztán gyere ide sírni.
Ha majd megválaszolható kérdést teszel fel, akkor esetleg segít valaki. Addig részemről a téma ejtve.
Hát a C++ klienst nem lehet ujrairni vagy is
Ha válallod akkor mehet.
Jelenleg 3,5 év folyamatos fejlesztés áll mögötte.
10 Programozó által. Szóval ha ujra irod a klienst 3 perc alatt akkor baromi ugyi vagy.
Csak JAVA oldalon lehet megoldani.
Irtam egy C++ -os servert de mivel a szerverek összekapcsolása fontos lenne és ráadásul a paltform sem ugyanaz (AIX, SunSolaris, Nt, Linux Bár az NT hamarosan megszünik) szóval ezért jött szóba a JAVA. Mellesleg én sem kedvelem. :-) Nem valami kellemes meló minde platformon megirogatni a C++ -os programot.
Ráadásul eddig csak NT és Linux alatt irogattam.
Akkor is csak standard C++ -ban.
Sokkal egyszerübb egy kódot karban tartani mint
4 fajtát.
De látom itt senki nem tud segiteni.
Ja a kék könyv meg elég béna.
Csak összezavarodtam tőlle.
A JAVA doksi jobb.
Én tök hüje vagyok Jávához (meg aztán nem is kedvelem), de amit írsz, azt 3 perc alatt megoldottam (C-ben írt klienshez (ez már megvolt) írtam egy Java szervert a kék könyv alapján), és tökéletesen működik.
Azt irtad, hogy ha a kliens es a szerver is Java, akkor szot ertenek egymassal... nagy valoszinuseggel mondhato, hogy valaminek kell mennie ilyenkor a vonalon!
Protokoll alatt en itt olyasmit ertek, hogy pl eloszor atkuldi az adat meretet byteban, vagy az adatok utan kuld egy kocsivissza-soremelest, amit a a masik kliens nem kuld, mert nem is tudja hogy kuldenie kellene...
A network-monitort monitor nem lát semmit amikor a JAVA küld csomagot. C++ esetén meg igen.
Ezért irtam.
De uj protokolt nincsen kedvem irni.
Nem hinném, hogy pár sorral el lehetne intézni.
Eddigi tapasztalataim szerint nagyob a kód
mérete mint más programnyelvek esetén.
de ha tudsz valami doksit ahol le van irva
feltehetőleg, akkor ne titkold :-)
Ennyi erővel lassan uj programnyelvet is irhatnék.
:-)
Kezdünk közeledni a problémához:-)
Tkp te azt akarod kérdezni, hogy a Java-ban a BufferedReader milyen protokollal küldi/fogadja az adatot. Ezt én sem tudom, de ha érdekelne, akkor fognék egy network-monitort és megnézném.
Másik lehetőség: hogyan kell olyan Java kódot írni, ami nem használ 'saját protokollt', hanem egyszerűen adott címtől adott számú byte-ot küld/fogad...
Nem vagyok kezdő.
JAVA ban tényleg nem vagyok profi.
És nem is szándékozom az lenni.
De erre a problémára sehol nem lehet találni semmit sem. És eddig senki nem tudta megcsinálni.
Az lehet hogy hibás, de egy egyszerű Buffered Reader -el készült Srever nem képes csak JAVA klienstől adatokat fogadni TCP/IP -n.
Semmilyen más nyelven irt programtól nem képes.
Sorolom az eddig próbált nyelveket.
Assembly. Pascal(Delphi), Borland C++, Visual C++,
Progress. Egymással gyönyörüen komunikálnak, de JAVA servernek elküldik a csomagot,
a Server meg nem veszi észre, csak ha JAVA klienstől érkezik.
Tulajdonképpen C++ -os programmal kéne neki most
kommunikálni, de sehogyan sem akarja.
Valakinek van ötlete? Van, hogyne: hibas a programod! Kezdo programozokra jellemzo, hogy ha nem talaljak a hibat, elkezdik a vilagot vadolni: nem jo a JAVA, hibas a Windows stb...
A konkret program ismerete nelkul a hiba okat nem lehet meghatarozni, probalj tobb informaciot adni (mondjuk ezt magadtol is kitalalhattad volna ;-)
Miért van az, hogy a JAVA egyetlen más programnyelven megirt programmal sem képes TCP/IP -n keresztül kommunikálni?
Legalábbis a szerver csak vár vár a kliens meg elküldte a csomagot és vár vár.
Itt megakad a dolog. Valakinek van ötlete?
Lenne egy kérdésem. Java-ban programozok, és DataWindow-ba felvitt adatokat szeretnék lementeni Adaptive Server Anywhere adatbázisba. Ezzel annyi gond van, hogy ha hosszú magánhangzó is szerepel a szövegben, akkor leakad a mentés Unicode konverziós hibával. Esetleg van valakinek ezzel kapcsolatos tapasztalata, amit megosztana velem?
És merre lehet ilyet találni valami emberi nyelven?
Angolul nincsen semmi. Vagy is nem találtam.
Mellesleg megirtam C++ ban a programot 2 nap alatt.
Mig Java ban 4 hét alatt sem sikerült.
De mostmár csak azért is meg akarom
csinálni JAVA alatt is. :-))
C++ ból meg mégkevesebbet tudok mint JAVA ból.
Sziasztok! Java-ból szeretnék nyomtatni, és akadt egy kis problémám. Ime egy lebutított class:
public class EgyszeruDokumentumNyomtato implements Printable {
public int print(Graphics g, PageFormat pf, int pageIndex) throws PrinterException {
if (pageIndex>=1){
return Printable.NO_SUCH_PAGE;
}
g.setFont(new Font("Times New Roman",Font.BOLD, 8));
g.setColor(Color.black);
String a = new String("kwjhfkqhgfi4391734ö8127ö387513p4t23gő2ú34gű2úg<#>íííéggokew<<ÚŐÚŐÓÜSSOPÍÁÍYXÚ");
String b = new String("lgeiwhrkigh984293t2óüéúcőóc o 9keörfjecnr e rg e9rge9 r9 9erg 9q3p43ó1ü4óüepwf");
String c = new String("lgeifewrfergrwthtukéoÁPŐÁpőápŐáöÜ ö ü-üŐ_ü-őüŐ-8=8!65+T23G!");
g.drawString (a,100,100);
g.drawString (b,100,200);
g.drawString (c,100,300);
g.drawLine(100+g.getFontMetrics().stringWidth(a),90,100+g.getFontMetrics().stringWidth(a),110);
g.drawLine(100+g.getFontMetrics().stringWidth(b),190,100+g.getFontMetrics().stringWidth(b),210);
g.drawLine(100+g.getFontMetrics().stringWidth(c),290,100+g.getFontMetrics().stringWidth(c),310);
return Printable.PAGE_EXISTS;
}
}
A kérdésem az lenne, hogy az a három vonal mért nem tud pontosan a szövegek mögé kerülni, mért csúszik el?
nem azt jelenti, hogy egyszerü és bonyolult.
Henm azt hogy van egy szerver és egy kliens. :-)
Töbszálóra nem irom meg mert a JAVA nem éppen
a csodálots egyszerüségéről hires.
Mellesleg baromi nehéz megcsinálni többszálóra
meg kockáztatom, hogy lehetetlen.
Ugyszólvén csak inkább olyan programokat lehet megirni többszálúra JAVA alatt ahol az önáló szálnak neincsen szüksége semmilyen külső adatra a futásához. Itt pedig lenne bőven.
Egyébként a kliensnek nincsen szüksége a szerver felől érkezőadatokra feltétlenül.
Hanem önnáló program nak kell elképzelni.
Ha a figyelést meg egy külön szál müködteti akkor meg mit kezdjek vele?
A program számára az infó ami jött nem elérhető.
Vagy is elérhető csak éppen nem tud rólla hogy van.
Kicsit ez is hibádzik mint a konzolos felület.
Lassan az az érzésem, hogy kliens oldalra is szervert fogok csinalni. :-)
Ez ugyan már nem kliens-szerver kapcsolat hanem szerver-szerver kapcsolat, de legalább működni fog :-))
Hat ha a kliens/szerver nalad azt jelenti, hogy egyszeru/bonyolult program, akkor igazad van:-)
Ha a szokasos ertelmezest nezzuk, akkor a kliens az, aki kapcsolatba lep a szerverrel, es tole valamilyen szolgaltatast ker. Ebben az ertelemben nem szamit, hogy a kliens egy vagy tobbszalu, rovid vagy hosszu stb...
Bocsi, de végül is milyen üzenetről van szó? Mert ha a válasz egy olyan üzenet, amire a kliensnek szüksége van (mondjuk, adatok, amiket meg kell jeleníteni), akkor a kliensnek meg is kell várnia, hogy a kommunikáció véget érjen. Max. egy 'Cancel' gombot tudok elképzelni. Tehát nem árt megírni többszálúra a dolgot.
amikor megjelenik az input queue-n a válasz, az triggerel valamit Hat eppen ez a kerdest, hogy ezt hogyan lehet megcsinalni! UNIX-ban a select vagy a poll valo erre, WinSock-ban a select vagy a WSAAsyncSelect, java-ban, attol felek, csak a multi-thread segit...
Ezt úgy hívják, hogy aszinkron kommunikáció... Másképp kell megírni a dolgot. A logika az, hogy van két queue, egyik a kimenô, a másik a bejövô üzeneteknek. Belepakolod az kimenôbe az üzenetet, megjegyzed az azonosítóját, és amikor megjelenik az input queue-n a válasz, az triggerel valamit (meghív egy metódust, stb.) Nem triviális az üzenetek feldolgozása, sokfajta megoldás van, pl. az IBM MQSeries, az Oracle 9i is tud ilyet, de meg is írhatod magad. Mindenesetre alapból másképpen kell tervezni az egészet.
Azt a megoldást, hogy a kliens egy thread-ben elindítja a szinkron módú requestet, és a közben te garázdálkodhatsz a kliensen: nagyon ellenjavallom. Iszonyatosan sok nullpointerbe fogsz belefutni, szinkronizálnod kell, kurvára lelassul, stb. Ha túl sokáig tart a request kiszolgálása, akkor írd át a szervert :-) Elvileg 3s alatti response az bôven elég a júzernek.
Kicsit félreértettétek mert nem a szerverel van a baj. (Egyébként is már most több szálon fut az aranyos.) Hanem a kliens -el. Mert amedig vár az üzire addig a felhasználó nem tud semitsem csinálni.
nem figyeli közben az eseményeket.
Lassan az az érzésem, hogz kliens oldalra is szervert fogok csinalni. :-)
Ez ugyan már nem kliens szerver kapcsolat hanem szerver szerver kapcsolat, de legalább működni fog :-))
Probald meg a ready() metodust. Na jo, de milyen gyakran hivja meg? Szerintem ezt korrektul csak thread-ekkel lehet kezelni... (az viszont tragikus eredmenyeket hoz :)
Probald meg a ready() metodust.
true ertekkel ter vissza, ha van mit olvasni a stream-bol. Addig ne hivd meg a read() metodust, amig false a visszateresi erteke.
Igy aztan nem kell a szervernek varakoznia a kliensre.
