igen, fel, csak ekkor jon az exception a kliensoldalon:
com.sun.xml.internal.ws.client.ClientTransportException: HTTP transport error: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names present
ezen lehet segiteni ugy, hogy bekerul a certbe a subjectAltName az ip cimmel
(asszem egyebkent, ha ez benne van, alapbol figyelmen kivul hagyjak a CN erteket)
(tobb subjectAltName ertek is lehet benne)
Ugy tunik, hogy keytool arra nem hasznahato, hogy subjectAltName elemet vegyek fol a certbe, csak openssl. Az openssl altal generalt cuccost beimportalhatom keytoollal .jks-be, ezt viszon meg a glassfish nem szereti. itt a vege.
Kerdesed elsosorban a szerializacio temakorebe tartozik, nagyon sok irodalmat fogsz tudni talalni rola a neten. (kulcsszavak: java, serialization)
Az objektumot leirasod szerint adatkuldesre hasznalod, azaz egyedi adatot tartalmaz. Ekkor szerintem teljesen indokolt a peldanyositas (masolas).
Amennyiben nagymennyisegu adatforgalomrol van szo es a memoria lenne a szuk keresztmetszet, akkor el lehet gondolkodni egy resource pool megoldason.
A factory patternt szoktak ilyen esetekben alkalmazni a peldanyositasra es a semaphore-t a eroforras szamlalasara.
Egyebkent ha halozati kommunikaciorol van szo, sokkal valoszinubb hogy a szuk keresztmetszet a kapcsolat savszelessege/sebessege lesz mint a szerveroldali memoria.
Persze ez fugg attol is, hogy mit csinal a program utana a keppel, amennyiben vmi idoigenyes szamitast, ugy mar valtozhat a helyzet.
Vegszokent annyit, hogy ahogy latod nem lehet erre "tuti" valaszt adni, mint a legtobb esetben itt is merlegelni kell a fobb szempontokat es annak megfeleloen donteni/optimalizalni.
A következő problémám van:adott egy thread, ami egy tcp-ip kapcsolatból folyamatosan olvas pl. "EredmenyClass" típusú objektumot.
Az EredmenyClass tartalmaz két byte[] tömböt amelyekben jpeg képek vannak, illetve három int típusú adatmezőt, meg a megfelelő getter metódusokat.
A thread a beérkezett objektumokat egy EventObject-ben elküldi a beregisztrált különböző feldolgozó listener-eknek. És itt a gondom: hogyan adjam át az ilyen jellegű feladatokban az objektumokat?Mert ha az objektumot továbbadom feldolgozásra, de közben a "forrás" metódusban módosítom (nem hozok létre újat a tcp-ip kapcsolaton érkező adatokból, hanem a meglévőbe rakok új adatokat), akkor a feldolgozást végző programrész is hibás, változó adatokat lát (referencia szerinti átadás). Ha viszont mindig új objektumot hozok létre, az memóriaszivárgást okozhat, nem? Folyamatosan gyártok objektumokat, de a GC általi megszüntetésük kérdéses.Mi ilyenkor a szokásos hivatalos, "elegáns" eljárás?Eleve az egész referencia szerinti paraméter átadás egy kicsit ködös nekem, mert ha átadok egy objektumot, amit később valahol módosítok, annak rossz esetben ellenőrizhetetlen következményei is lehetnek. Mi a megoldás? Klónozás?Gondolom ez egy triviális probléma, a Java-val foglalkozó könyvekben mégsem nagyon tárgyalják. Talán mert annyira "alap"? :-)
persze ha a kliens a host fajljaba folveszi a szervert egy neven az adott ip-vel, es a cert-ben ezt a nevet hasznalom, es a wsdl-ben is a <soap:address location ez emlitett hostnevet alkalmazza akkor megy a dolog. dehat nem lehet minden klienst megkerni, hogy irja at a host-fajljat. Nem lehet esetleg a java kodban elerni azt, hogy wsdl-bol megkapott host nevet a host allomany hasznalata nelkul leforditsa ip cimme? Ez talan kerulo megoldasnak jo lenne.
Bocs, az eleje meg lemaradt: kb annyi, hogy webservice-szal kommunikal a vastagkliens a serverrel, es nem a szerverprogi, hanem az alkalmazasszerver autentikaltat.
<auth-method>BASIC</auth-method> <realm-name>webRealm</realm-name> (egy jdbc realm, de ez nem is fontos)
Viszont szertettem volna (ill muszaj) ssl-t tenni a kommunikacio ala, mert hogy igy kodolatlanul mennek a passwordok.
Itt jonnek a borzalmak. A servernek ugyanis nincs hostneve, csak ip cime.
("Change Certificates Subject Alternative Value: If youre connecting to your host by using IP address, then you must change the subject alternative value to your IP address value.")
A kliensnel ott van a keystore.jks, amiben ott van a ket cert, amit a server is hasznal. (glassfish az alkalmazasszerver. a keystore.jks ben van ket cert. Az aliasuk s1as es glassfish-instance).
Ha annak rendje-modja szerint a jdk keytool programjaval megcsinalom a kliens keystore.jks-et, a java kliens azert reklamal, hogy kell neki az alternate name. Tehat ilyenkor a certnek kell tartalmaznia egy ilyesmit:
Ez a feni reszlet viszont a az openssl conf filejanak egy reszelet, ugyanis a keytool-lal nem lehet altName-t beletenni a certbe. (aszongyak a kozertben)
Tehat a keytool helyett kenytelen vagyok openssl-t hasznalni, majd az openssl altal keszitett cuccost a keytoollal importalni
Nna az a vege, hogy megvan a keystore, benne a ket cert megfelelo aliasokkal. Ezt viszont mar a glassfish nem eszi meg.
Itt meg mar valoban elakadtam, hiaba bujtam a netet egy heten keresztul. Abban remenykedem, itt csinalt mar v.ki ilyesmit, azaz hogy host nevvel nem rendelkezo serverrel epitett ki ssl kapcsolatot, es mond valami biztatot.
idoszukeben csak nehany altalanos dolgot illetve linket tudok mondani.
Az egyik site amit tudok javasolni a javapassion.com ami mara fizetosse valt, de egeszen megfizetheto az ara es nagyon sok temakorben ad egesz korrekt tutorialt. Nem utolso sorban sokszor lehet gyorsan snippeteket lopni onnan. :-)
Amugy a vastagklienssel altalaban az van, hogy a funkcionalitas a kliensen belul van, tehat csak a kezdeti autentikacioert fordul a szerverhez. Ez tobbfelekepp megoldhato. Egy gyakori megoldas szokott lenni, h a bejelentkezesnel szerver oldalon generalnak egy session id-t es utana a klienstol erkezo tobbi request ezen a sessionon keresztul tud iro/olvaso muveleteket vegezni (amig a session el). Ilyenkor fontos az ssl, hogy a session id-t ne lehessen sniffelni.
Amit nem szabad komoly alkalmazasnal: visszaterni az autentikacio sikeressegevel es onnantol (sikeres esetben) szabadon vegezheto barmilyen muvelet. Konnyu belatni, h az ilyen szoftvert nem nehez meghekkelni.
Vegul pedig par link csak egy szimpla google utan:
J2EE webkontener nyujtotta automatizmust hasznalva (JDBC realm-mel, DB connection pool-t hasznalva, https-sel) sikerult megoldanom a webes reteg biztonsagi ugyeit. (http, ill. https, webbongeszo klienssel)
Most viszont szertenek vastagklienssel kapcsolodni az alkalmazasszerverhez, es ejb-ket hasznalni ott.
(Ugy kepzelem el a dolgot, hogy egy egyszeru username/password megadasaval authentikaltatom a klienst)
Nagyon jo lenne, ha titkositva jutnanak el legalabb az authentikacios adatok a szerverhez.
Sajnos a neten nem talaltam olyan forrast, ahol peldaprogrammal mutatnak be, hogyan kellene ezt lekodolni. Nagyon kellene egy kliensoldali kod is. Gyanitom, hogy sajnos nem lesz olyan egyszeru a dolog, mint a vekonyklienssel, mar csak az ssl miatt sem.
Persze a legjobb az lenne, ha egy mukodo kis peldaalkalmazas kodjat lathatnam. :)
Az lenne a keresem, ha v.ki tud olyan linkrol, ahol egy ilyesmi tutorial bujkal elolem ossza mar meg velem ezt az infot!
Ekkora mennyiségnél gyakorlatilag minden módszer működik. :)
A hálózati konfignál leginkább arra gondoltam, hogy van-e tűzfal vagy hasonló a szerver és a kliens között. Ha például a kliens egy user otthoni gépe, akkor nyugodtan feltételezheted, hogy van, tehát nem tudsz kapcsolatot kezdeményezni a kliens fele. Ami persze nem gond, mert nyit ő kétirányú kapcsolatot, de kétlem, hogy az EE-ben lenne erre bármifajta támogatás.
Ha csak ismerkedsz az EE-vel, akkor tényleg a klasszikus kliens-szerver megközelítést javasolnám elsőre, fix időközönként való rákérdezéssel, fölösleges egy bonyolult architektúrával kezdeni.
Nagyon-nagyon pici az adatmennyiseg. Par box koordinata, egy-ket rovidke string. Semmi kulonos. Kb 20 kliens egyszzerre, de ezek kozott is csak 3-4 kliens lenne egymassal realtime kapcsolatban, percenkent nehany uj adat lehet, amit frissiteni kell nekik. Halozati konfig: savszelessegre gondolsz? Internetes kapcsolat, nem local. Nem fontos a sebesseg abban az ertelemben, hogy egy csomo konnekt lenne, sok-sok binary adattal pl.
Valamifele EE megolddast szerettem volna a helyzetre, es nem azert, hogy majd klaszterezzem a rendszert vagymi. Kicsit okulni akartam volna a dologbol, mert most ismerkedem az EE specifikacioval.
Gyerekek, itt en alazatos vagyok, mert kerdezek mint a legkevesbe hozzaerto, es ti valaszoltok pedig nincs is kedvetek hozza. :)
Az alap helyzet, a "dolog" az volt, hogy egy SE-s RMI-s projektben siman hivom a klienst a szerverrol, igy:
reszlet a kliens oldal kodjabol: Registry reg = LocateRegistry.getRegistry(hostt,1099); AlarmServer server = (AlarmServer) reg.lookup("AlarmServer"); UnicastRemoteObject.exportObject(this, 0); server.alarm(this, ..., ..., ....);
rmi-s okossagok utan meghivaja a szerver alarm metodusat, paramaterkent kuldi magarol a referenciat: server.alarm(this, ..., ..., ....);
reszlet a server kodjabol: public void alarm(AlarmClient client, ..., ..., ....) throws java.rmi.RemoteException { azonnal visszaterek, uj szalon kezelem a kliens kereset }
egy masik szalon:
client.wakeUp("I am the server: ", ..., ....);
Nna ezt szertettem volna "portolni" EE-re.
Ez a dolog, aminek nincs megoldasa, abban az ertelemben, hogy semmifele EE autoatizmust nem hasznalhatok, mert nem tamogat ilyesfajta butasagokat az EE.
Mekkora adatmennyiségről van szó kérésenként? Hány kérést kell kiszolgálni percenként? Milyen a hálózati konfiguráció? Hogy oszlik el az aktivitás az időben egy kliens szempontjából? És a szerveréből?
Persze, hogy van megoldás, csak tudni kéne egy csomó paramétert, bár ismétlem, ha a sebesség tényleg fontos, akkor valami alacsonyabb szintű megoldást válassz, ahol jobban tudod kontrollálni az eseményeket.
De csak hogy egy példát mondjak megoldásra: egyfelől igen, a kliens fix időközönként rákérdez, hogy van-e valami a számára (a szerveren ez egy hashmap-be való bekukkantást és onnan a felsorakoztatott üzenetek átküldését jelent mindössze), másfelől meg minél inkább úgy kell megtervezni az üzeneteket, hogy ne múljanak a szerver belső állapotán, és végül: se a szerver, se a kliens ne dobjon hátast akkor, ha a szerver belső állapota nem az, amire a kliens számított.
"Én eleve kételkedem abban, hogy valóban szükség van real time értesítésre"
Akkor te mit javasolsz, ha azt szeretnem, hogy lehetoseg szerint minel hamarabb tudjon arrol a kliens, ha a szerveren ot erinto valtozas tortent? Tegyek be egy buttont, amit nyomkod, ha frissiteni akar a user? Vagy inditsak egy idozitot, ami idonkent megkerdezi a szervert, mizu?
Ja, sőt, még ennél is lehet tovább bonyolítani, csak minek.
Én eleve kételkedem abban, hogy valóban szükség van real time értesítésre. Iszonyúan ritka, hogy ilyesmi tényleg kelljen, és amikor kell, akkor az tuti, hogy EJB-nek közelébe se mennék. :)
Vagy, végső esetben egyetlen szálon is meg lehet próbálni, hogy nem várjuk meg az első kliens válaszát, mielőtt elküldjük a másodiknak is az üzenetet...
Gondolj csak arra az egyszerű esetre, amikor a sorban a legelső kliens cseszik válaszolni fél óráig.
Ha viszont sok szálon küldöd, akkor az egymás utániság csak IP csomagszinten lesz igaz, maguk az üzenetek párhuzamosan mennek át, és senki nem vár aránytalanul sokat amiatt, mert a másik lassú.
szóval szerinted, ha a szerver szálanként küldi ki azt az egy üzit, vagy 1 szál küldi ki mindenkinek azt az 1 üzit, az nem ugyanúgy egymás után fog megtörténni?
megneztem a laptopon amin irok a task managert. 114 task fut, osszesen tobb mint 1000 thread. semmilyen komolyabb cucc nem fut rajta, csak a windows, browser, levelezes, szovegszerkeszto.
