Oma pelipalvelu!
Sivustoni on siis tässä -> http://temp4322.dy.fi
Olen tässä jo useita kuukausia kasannut Java sotalautapelipalvelua, minulla tosin meni todella kauan ennen kuin löysin sopivan palvelin palvelun käyttöön.
Taasen minulla jo 80 luvun lopulla MSX ja C64 vuosina, iskeytyi ajatus omista puoli kaupallisista sotalautapeleistä, ja kaikenlaista on vuosien varrella ollut yritystäkin, ei kuitenkaan aina julkaistuun.
Tarvitsen hieman neuvoja Java ohjelmointi rakenteluissa koska olen ilman ammattitaitoa tietokoneitten kanssa.
Tarkoitus on rakentaa peruspelit shakki, tammi, jne.. ja myös nämä sotapelitkin, niin, kaikki live että tallenne muotoon, ajattelin että palvelimessa olisi kaksi huonetta jokaiselle eri lautapelille, live huone ja tallenne huone, näissä kahdessa huoneessa sitten voisi olla eri määrä live pelejä taikka tallenne pelejä käynnissä, ajattelin että live pelejä voisi olla 256 jokaiselle lautapelille ja tallenteita voisi olla jotain 100000 kerrallaansa kaikille lautapeleille palvelimessa.
Olen valmis vastaanottamaan neuvoja siintä kuinka tämänkaltainen palvelu olisi paree rakentaa.
Minulla on itselläni seuraavasti suunnitteilla palvelin ohjelmaani ->
0) Yksi pää thread joka ohjaa muita threadeja.
1) Palvelin pää threadiin asetetaan yksi thread joka tallentaa ja lataa tiedostoja kovalevyltä, sekunnissa voi olla noin 250 eri kovalevy toimintaa.
2) Palvelin pää threadiin asetetaan yksi pää TCP thread joka pitää sisälläänsä useita kymmeniä pienempiä TCP threadeja, joissa luetaan SOCKETteja, mietin että 25 sockettia yhteen pieneen TCP threadiin, Read timeout 1, readbuffersize 16384, sendbuffersize 4096.
3) Palvelin ohjelma antaa aina luvan asiakkaille ja peleille kun on valmis vastaanottamaan paketteja, asiakkaat eivät voi lähettää kuin enintään 4 pakettia sekuntti ja vain kun palvelin antaa luvan, palvelin ei anna lupaa ennen kuin asiakkaan edellinen paketti on kokonaan käsiteltynä.
4) Palvelin vastaanottaa OBJECT STRING muodossa tekstiä, olen rakentanut oman STRINGBUFFER pohjaisen SKANNERI luokan, jolla tekstiä käsitellään.
Nämä kohdat olen tähän palvelin ohjelmaani asentamassa, olisin kiitollinen kaikenlaisesta neuvosta ja vinkistä, kuinka palvelin ohjelma olisi hyvä kasata, jotta ei ihan koko ikää tässä perus säätelyssä kulu :)
----
kpzpt kirjoitti:
Oma pelipalvelu!
Olen valmis vastaanottamaan neuvoja siintä kuinka tämänkaltainen palvelu olisi paree rakentaa.
0) Yksi pää thread joka ohjaa muita threadeja.
1) Palvelin pää threadiin asetetaan yksi thread joka tallentaa ja lataa tiedostoja kovalevyltä, sekunnissa voi olla noin 250 eri kovalevy toimintaa.
Onko tämä sitä varten että levytoiminnoista saadaan asyncronisia? Mitä tapahtuu jos aletaan tallentamaan async käyttäjän tietoja ja sitten tapahtuukin jokin virhe, samalla client/ui on jo edennyt eteenpäin...
kpzpt kirjoitti:
2) Palvelin pää threadiin asetetaan yksi pää TCP thread joka pitää sisälläänsä useita kymmeniä pienempiä TCP threadeja, joissa luetaan SOCKETteja, mietin että 25 sockettia yhteen pieneen TCP threadiin, Read timeout 1, readbuffersize 16384, sendbuffersize 4096.
Miksi pitää olla näin monimutkainen kyhäelmä? Mistä olet keksinyt magic number 25? Eikö olisi järkevämpää että on serverillä vaikka Client luokka, jonka sisällä on vain sen tarvitsemat socket yhteydet ja jos niitä pitää käyttää async niin niitä vastaava thread tai paremminkin käyttäisit java.nio tarjoamia palveluita.
kpzpt kirjoitti:
4) Palvelin vastaanottaa OBJECT STRING muodossa tekstiä, olen rakentanut oman STRINGBUFFER pohjaisen SKANNERI luokan, jolla tekstiä käsitellään.
Kiintoisaa, minkälainen on OBJECT STRING muodossa oleva teksti?
ööh!
En ymmärrä sinua _Pete_, olen jo pyytänä että et vastaisi minun viesteihini, minä katson että se on häirintää jos vastaat, sinä olet minulle liian loukkaava, tämä viesti ei ollut niitä törkeimpiä mitä olet minulla kirjannut, mutta, minä kuitenkin alan ilmoittamaan ylläpidolle jos et jätä minua rauhaan.
Minä TODELLA pyydän että et vastaisi enää minun viesteihin ja kyselyihin, sinä pyrit aina loukkaamaan minua, kirjoitus sävysi on turha ja minulla on vaikeata vastaanottaa asiallisia vastauksia kun sinä aina olet ensimmäisenä loukkaavaan sävyyn kirjaamassa vastauksia !
----
Harmi, kun tällä foorumilla ei voi laittaa käyttäjiä ignoreen. Ainakin itse olen todennut muutaman käyttäjän kohdalla, että olisi parempi vaan jättää vastaamatta heidän kysymyksiin, mutta ei sitä aina muista.
Toisaalta voithan sinäkin kpzpt jättää _Pete_n viestit lukematta. Ei sitä varmaan ole sinulle sen vaikeampi muistaa olla lukematta _Pete_n viestejä kuin _Pete_lle muistaa, ettei vastaile sinun viesteihin.
Mielestäsi _pete_n kommentit oli ihan hyviä. Jos joku muu olisi kirjoittanut täsmälleen saman viestin niin olisit ilmeisesti ottanut sen ilolla vastaan? Eikös tuo ole syrjintää?
Viestien ohittaminen !
Minä koen että ongelmana on tämä, että, ainakin minun kirjoitustapani ja ohjelmointi taitoni alittavat ne odotukset mitä _Pete_ nimimerkin henkilöllä on forumeitten käyttäjille.
Kuitenkin _Pete_:nkin tulisi hyväksyä tämä, että, eri forumeilla on eri taitoisia ja eri ammatillisia henkilöitä, joilla, ei voi olla kaikilla samaa kykyä kirjoittaa tekstiä taikka koodia, vaikka ohjelmointia pitävätkin harrastuksenaansa ;)
----
En tajua, miksei _Pete_ voi vastata. Aikaisemmista vastauksista en tiedä, koska noh... asia ei edes jaksa kiinnostaa, mutta tämä kyseinen viesti kyllä herättää kysymyksiä, joihin ei ole pakko vastata, mutta kannattaa silti itsekseen miettiä, että oletko oikeasti miettinyt järjestelmän logiikkaa, vai keksinyt asiat vain etukäteen päässäsi ja olettanut ne toimiviksi.
ja toiseksi, olet avoimella foorumilla, johon jokainen Putkan jäsen voivat vastailla. Vaihda toki foorumia, jos käyttäjät eivät miellytä.
Avoin foorumi!
Eteenkin avoimilla foorumeilla tulee olla ilman loukkaavaa ja vähättelevää sävyä, vaikka sitten itse olisikin kuinka paljon laadukkaampi henkilö mitä toinen.
Minä olen hieman tätä mieltä, että henkilöitä jotka jatkuvasti kirjaavat toisesta joko suoria henkilökohtaisuuksiin meneviä loukkauksia, taikka sitten lähes aina ylläpitävät loukkaavaa sävyä vastaillessaan, niin, tälläisiä henkilöitä tulisi ohjata ylläpidon puolesta, muutenhan sivuston yleisilme on ei ihan niin laadukasta mitä se voi oikealla tavalla ylläpidettynä olla, tästä asiasta voisi jokin etusivun lappunen olla täällä forumin etusivulla.
Meidän tulisi täällä pohjolassakin muistaa, että, olemme Euroopan Unionin jäsen valtio ja EU on antanut yleisohjeistus sääntöjä foorumin ylläpitäjille.
Eteenkin tilanteissa joissa jollekkin henkilölle saattaa kehittyä tilanne että hän joutuu kokemaan loukkauksia taikka loukkaavaa sävyä ja foorumien käyttäminen alkaa muodostua epämiellyttäväksi, aika vastenmielinen ajatus, kun etukäteen tietää mitä sävyä tulee kokemaan kysyessään "tyhmiä" taikka "yleisesti jo käsiteltyjä asioita joita ei aleta toistamaan".
Minä koen rasismia _Pete_ nimimerkin kohdalla koskien aivojani, _Pete_ ei pidä minua älykkäänä ja myös kirjaa tähän sävyyn säännöllisesti jotta muutkin ymmärtäisivät saman, hän toimii samoin niin täällä putkassa kuin Ubuntu forumillakin kohdallani, jotenka aika hassua juttua.
----
Olen _Pete_n kanssa samalla linjalla tuon socket tcp thread virityksen kanssa.
Miksi pitää valmiina sekavaa staattista verkostoa, kun voit luoda aina uuden Client olion kun uusi yhteys saapuu ja hallinnoida olioita?
TCP Threadit!
Ajattelin että useat threadit hidastaisivat palvelin koneeni tehoja RAM ja CPU kun kaikki samanaikaisena pyörivät.
Mietin että jos laitan 25 - 50 sockettia yhteen threadiin, jossa thread lukee socket kerrallaansa 1 ms timeoutin kanssa jonossa socketteja, näin minulla on 25 - 50 kertaa vähemmän threadeja kerrallaansa palvelimen RAM ja CPU kuormituksena.
Kun minä vielä rajoitan tämän tcp pakettien vastaanoton, niin, että asiakkailla ei ole lupaa lähettää seuraavaa tcp pakettia ennenkuin palvelin on kokonaansa käsitellyt edellisen tcp paketin ja lähettänyt uuden lähetys lupa paketin asiakkaalle.
Minulla on ihan hyvä palvelin kone käytössä, ei mikään super palvelin, mutta, ihan hyvä, ajattelin heti rakentaa sellaisen palvelin ohjelmiston joka käyttää palvelimen koko kapasiteetin ja mahdollisimman hyvin.
Minä koen että olen oikeassa tässä kun laitan yhteen threadiin useampia socketteja joita luetaan 1 ms timeoutin kanssa jonossa, kyseessä on siis lautapeli palvelu jossa paketteja ei juuri milloinkaan lähetetä kuin 1 / sekuntti taikka 1 / useampi sekuntti.
Minä koen että teillä on hieman tuota olio sokeutta, jokaiselle toiminnalle ei ole hyvä asettaa omaa threadia, vaan toimintoja voi keskittää yksittäisiin threadeihin useita, eli jonottaa.
----
Palvelin ohjelmistosta ->
Palvelimeen 50-150 kpl tcp threadeja, jokaiseen 25-50 kpl tcp socketteja siirtoja varten ja 250-500 stringbufferia viestejä varten.
Java socket asetukset, kuten ne olen säätämässä, en näitä täysin ymmärrä jotenka otan vinkkejä vastaan.
this.vars.socket [ fslot ].setSoTimeout ( 1 ); this.vars.socket [ fslot ].setReceiveBufferSize ( 16384 ); this.vars.socket [ fslot ].setSendBufferSize ( 8192 ); this.vars.socket [ fslot ].setKeepAlive ( false ); this.vars.socket [ fslot ].setPerformancePreferences ( 0,1,2 ); this.vars.socket [ fslot ].setTcpNoDelay ( false ); this.vars.ois [ fslot ] = new ObjectInputStream ( this.vars.socket [ fslot ].getInputStream ( ) ); this.vars.oos [ fslot ] = new ObjectOutputStream ( this.vars.socket [ fslot ].getOutputStream ( ) );
----
Kysymyksenä vielä kuinka olisi paree rakentaa, kaikki tämä stringbuffereihin tallentuvan tekstin käsittely ?
Myöskin mitä käskyjä on yleisesti suomenkielisenä palvelin ohjelmistoissa, olen ilman aiempaa palvelin ohjelmointi kokemusta, olisi mukavaa kuitenkin jos suurinpiirtein yleisesti tunnettua sanastoa olisi käytössä myös omassa palvelimessani ?
Entä kuinka olisi paree rakentaa, ihan koko palvelin ohjelmiston yleinen kulku ?
Esim. juuri nyt minulla on ->
1 kpl pää thread.
1 kpl kovalevyn luku & kirjoitus threadi, yhteensä jotain 50-150 luku tai kirjoitus toimea sekuntti.
50-150 kpl tcp socket luku threadeja.
Mutta, en vielä ole osannut hahmottaa tätä ihan koko palvelin ohjelmiston kulkua, mitenkäs nämä tcp threadien tuomat viestit olisi parasta käsitellä !
Niin tosiaankin pyydän anteeksi että olen toisinaan turhan kärkkäästi vastaillut
juttuihisi.
Mutta kuten tuo eka vastaus ja tämä, pyrin jatkossa olemaan asialinjalla vaikka
olisi miten idioottimainen kysymys ja vielä kysyttynä 1000*.
kpzpt kirjoitti:
TCP Threadit!
Ajattelin että useat threadit hidastaisivat palvelin koneeni tehoja RAM ja CPU kun kaikki samanaikaisena pyörivät.
Niin ne threadit nimenomaan tekee. Siksi ei ole järkevää yltiöpäisesti joka
väliin tunkea threadia jos on olemassa sellainenkin vaihtoehto, että yhksi threadi voi käsitellä saman. Tällainen juurikin on ehdottamani java.nio
kpzpt kirjoitti:
Mietin että jos laitan 25 - 50 sockettia yhteen threadiin, jossa thread lukee socket kerrallaansa 1 ms timeoutin kanssa jonossa socketteja, näin minulla on 25 - 50 kertaa vähemmän threadeja kerrallaansa palvelimen RAM ja CPU kuormituksena.
Tuossa 25-50 / thread ei ole Javassa mitään järkeä. Se voisi ehkä sopia jos kyseessä funktionaalinen ohjelmointi kieli. Olio maailmassa kuuluu(!!), ja on paljon selkeämpää, tehdä niin että ominaisuudet sidotaan tiettyy olioon ja sillä
tapaa että ne kuuluvat vain kyseiselle instanssille.
Tuosta 25-50 tulee väistämättä suuria ongelmia:
1) Kun jotain liikennettä tulee, miten loppujen lopuksi päätetään missä se oikeasti käsitellän
2) Mahdolliset synchronized ongelmat, threadien kanssa kun toimii pitää *oikeasti* tietää mitä tekee.
kpzpt kirjoitti:
Kun minä vielä rajoitan tämän tcp pakettien vastaanoton, niin, että asiakkailla ei ole lupaa lähettää seuraavaa tcp pakettia ennenkuin palvelin on kokonaansa käsitellyt edellisen tcp paketin ja lähettänyt uuden lähetys lupa paketin asiakkaalle.
Tässä on nyt sellainen oletus, että kun lähetät asiakkaalle jotain oletat että se myös vastaanottaa sen. Mistä tiedät tämän varmasti? Jotta tuo varmasti toimisi pitäisi olla jonkinlainen kuittaussysteemi, client varmistaisi että on
saanut odotus pyynnön.
Eikö olisi varmempaa/helpomaa serveri päässä vain jättää huomioimatta ne paketit
joita ei halua käsitellä.
kpzpt kirjoitti:
Minulla on ihan hyvä palvelin kone käytössä, ei mikään super palvelin, mutta, ihan hyvä, ajattelin heti rakentaa sellaisen palvelin ohjelmiston joka käyttää palvelimen koko kapasiteetin ja mahdollisimman hyvin.
Tämä nykyinen suunnitelma käyttää melko varmasti kapasiteetin. Se että onko se mahdollisimman hyvin onkin eri asia.
kpzpt kirjoitti:
Minä koen että olen oikeassa tässä kun laitan yhteen threadiin useampia socketteja joita luetaan 1 ms timeoutin kanssa jonossa, kyseessä on siis lautapeli palvelu jossa paketteja ei juuri milloinkaan lähetetä kuin 1 / sekuntti taikka 1 / useampi sekuntti.
Minä koen että et ole oikeassa. Socketteja ei tarvitse erikseen lukea/pollata. Riittää että odottaa kunnes niihin tulee jotain. Sama pätee kaikkiin muihinkin
(io) tapahtumiin.
kpzpt kirjoitti:
Minä koen että teillä on hieman tuota olio sokeutta, jokaiselle toiminnalle ei ole hyvä asettaa omaa threadia, vaan toimintoja voi keskittää yksittäisiin threadeihin useita, eli jonottaa.
Kun on kyseessä puhdas oliokieli eli Java niin silloin on syytäkin olla "olio sokeutta". Jos se tuntuu sinusta vieraalta tee systeemisi vaikka C:llä.
kpzpt kirjoitti:
Palvelin ohjelmistosta ->
Palvelimeen 50-150 kpl tcp threadeja, jokaiseen 25-50 kpl tcp socketteja siirtoja varten ja 250-500 stringbufferia viestejä varten.
Edelleenkin herää kysymys, mistä olet keksinyt nämä magic numberit? Mihin ne perustuu ja miksi pitää (jos pitää) olla juuri tuo määrä?
kpzpt kirjoitti:
Java socket asetukset, kuten ne olen säätämässä, en näitä täysin ymmärrä jotenka otan vinkkejä vastaan.
this.vars.socket [ fslot ].setSoTimeout ( 1 ); this.vars.socket [ fslot ].setReceiveBufferSize ( 16384 ); this.vars.socket [ fslot ].setSendBufferSize ( 8192 ); this.vars.socket [ fslot ].setKeepAlive ( false ); this.vars.socket [ fslot ].setPerformancePreferences ( 0,1,2 ); this.vars.socket [ fslot ].setTcpNoDelay ( false ); this.vars.ois [ fslot ] = new ObjectInputStream ( this.vars.socket [ fslot ].getInputStream ( ) ); this.vars.oos [ fslot ] = new ObjectOutputStream ( this.vars.socket [ fslot ].getOutputStream ( ) );
Nämä on kaikki selostettu täällä:
http://download.oracle.com/javase/6/docs/api/java/net/Socket.html
Jos ei ole mielestäsi tarpeeksi tarkkaan, googleta unix sockets, niistä löytyy
vielä tarkempaa teknistä tietoa.
kpzpt kirjoitti:
Mutta, en vielä ole osannut hahmottaa tätä ihan koko palvelin ohjelmiston kulkua, mitenkäs nämä tcp threadien tuomat viestit olisi parasta käsitellä
Palvelinohjelmisto on paras rakentaa näin:
1) On joku joka odottaa eventtejä
2) Sitten kun sellainen tulee, käsitellään
kpzpt kirjoitti:
Ajattelin että useat threadit hidastaisivat palvelin koneeni tehoja RAM ja CPU kun kaikki samanaikaisena pyörivät.
Itse lähtisin varmaankin liikkeelle siitä, että olisi yksi säie per asiakas.
En ole Javan säikeisiin tutustunut, mutta luulen, että tässä tapauksessa olisi turha pelätä koneen tehojen loppumista. Yleensähän säie blokkaa odottaessaan tavaraa sockettiin, jolloin se käytännössä nukkuu.
jalski kirjoitti:
En ole Javan säikeisiin tutustunut, mutta luulen, että tässä tapauksessa olisi turha pelätä koneen tehojen loppumista.
Ja vaikka olisikin, on typerää yrittää optimoida ohjelmaa, ennen kuin on nähnyt, mikä sitä oikeasti hidastaa. Jos luokkarakenne on hyvin suunniteltu, tuota on helppo muuttaa jälkikäteen. (Tosin jos on nähnyt kpzpt:n aiemmat aiheet, herää epäilys, että tässä projektissa harva asia on hyvin suunniteltu.)
lainaus:
Itse lähtisin varmaankin liikkeelle siitä, että olisi yksi säie per asiakas.
En ole Javan säikeisiin tutustunut, mutta luulen, että tässä tapauksessa olisi turha pelätä koneen tehojen loppumista. Yleensähän säie blokkaa odottaessaan tavaraa sockettiin, jolloin se käytännössä nukkuu.
Minä ajattelin jonottaa nämä socketit ainoastaan tämän tilanteen varalta että kaikki asiakkaat siirtävät samaan aikaan, kun jos taas minulla on socketit jonossa jossa on aina jotain 25-50 kappaletta socketteja, niin, minulla ei ole käytännön riskiä usean threadin CPU piikeille aivan näin helposti ?
lainaus:
Tässä on nyt sellainen oletus, että kun lähetät asiakkaalle jotain oletat että se myös vastaanottaa sen. Mistä tiedät tämän varmasti? Jotta tuo varmasti toimisi pitäisi olla jonkinlainen kuittaussysteemi, client varmistaisi että on
saanut odotus pyynnön.Eikö olisi varmempaa/helpomaa serveri päässä vain jättää huomioimatta ne paketit
joita ei halua käsitellä.
Aina kun asiakas lähettää paketin, niin tämän jälkeen asettuu lippu joka kieltää lähettämästä uutta, ja tämä lippu sitten avataan palvelimen toimesta kun palvelin on kokonaan käsitellyt edellisen paketin, jätän pienen säätö varan siihen että asiakas voisi lähettää 1 paketin sijaan 1-4 pakettia, ennen asiakkaan lähetys lippu lukkoa.
lainaus:
Edelleenkin herää kysymys, mistä olet keksinyt nämä magic numberit? Mihin ne perustuu ja miksi pitää (jos pitää) olla juuri tuo määrä?
Magic numberit ??? tämä on ohjelmointi sivusto ei psykologia taikka psykiatria ?
Jokin sopiva luku täytyy valita, yksi socket on timeout 1 ms jotenka jos otan alle 50 sockettia yhteen threadiin (<50ms), niin se on minusta vielä varmasti sopivaa !
Voisi olla vielä 100 sockettiakin, mutta, jos yksi thread 100 lähettää, niin kestää aina 99ms ennenkuin sitä luetaan.
lainaus:
Tuossa 25-50 / thread ei ole Javassa mitään järkeä. Se voisi ehkä sopia jos kyseessä funktionaalinen ohjelmointi kieli. Olio maailmassa kuuluu(!!), ja on paljon selkeämpää, tehdä niin että ominaisuudet sidotaan tiettyy olioon ja sillä
tapaa että ne kuuluvat vain kyseiselle instanssille.Tuosta 25-50 tulee väistämättä suuria ongelmia:
1) Kun jotain liikennettä tulee, miten loppujen lopuksi päätetään missä se oikeasti käsitellän
2) Mahdolliset synchronized ongelmat, threadien kanssa kun toimii pitää *oikeasti* tietää mitä tekee.
Jälleen kerran hieman turhaa sanailua joka ei ole sopivaa ohjelmointi sivulle, liian loukkaavaa sävyä koskien minun ajatteluani, järkeni ja selkeyteni ja oikeasti kahdesti mainittu turhaan ;)
EUssa jos ylläpitää keskustelu palstaa niin ylläpidon tulee huolehtia että viestit pitää todellakin rakentaa, sellaiseen muotoon että toinen ei pysty kokemaan epämiellyttävää oloa kun kyselee "tyhmiä" taikka "jo hyvin tunnettuja asioita joita ei mielellään toisteta", eteenkään säännöllisesti jonkin tietyn henkilön kohdalta ;)
Tässä kuitenkin toiminta malli tämän hetkinen ->
Main alustus ja kulun ohjaus thread 1kpl.
Kovalevy thread 1kpl.
TCP pakettien käsittely thread 1kpl.
50-150 kpl TCP threadeja, 25-50 sockettia yhdessä, 250-500 stringbufferia yhdessä.
1 kpl kaikki kriittisten toimien muuttujat.
Pääsääntöisenä kulkua ohjataan tästä erillisestä luokasta joka sisältää vain toiminnan kannalta kriittisiä muuttujia. Tämä muuttuja luokka sitten löytyy kaikista muista koodi luokista ja koodi luokat toimivat löytyvien muuttujien mukaan.
Toimii ihan hyvin, tahtoisin vain vielä jotain lausetta joltain toiselta, kaiken jo sanotun lisäksi.
kpzpt kirjoitti:
Jälleen kerran hieman turhaa sanailua joka ei ole sopivaa ohjelmointi sivulle, liian loukkaavaa sävyä koskien minun ajatteluani, järkeni ja selkeyteni ja oikeasti kahdesti mainittu turhaan ;)
Ei siinä puhuttu sinun järjestäsi, vaan siitä onko esittämäsi toteutustapa järkevä vai ei. Kannattaa huomioida, että esittämiesi asioiden käsittely asioina ei nimenomaan ole henkilöön menevä hyökkäys.
Monissa ohjelmointikielissä on järkeviä ja vähemmän järkeviä tapoja tehdä asia. Usein harjaantumattomat ohjelmoijat käyttävät vähemmän järkeviä menetelmiä, vaikka ihmisinä ovat ihan fiksuja.
Minultakin löytyy, varsinkin alkuaikoina tekemistäni koodeista, aivan idioottimaisia ratkaisuja. En todellakaan vedä hernettä nenään jos joku huomauttaa niistä. Nykyään huomaan vanhemmissa koodeissa niitä itsekin.
Grez kirjoitti:
kpzpt kirjoitti:
Jälleen kerran hieman turhaa sanailua joka ei ole sopivaa ohjelmointi sivulle, liian loukkaavaa sävyä koskien minun ajatteluani, järkeni ja selkeyteni ja oikeasti kahdesti mainittu turhaan ;)
Ei siinä puhuttu sinun järjestäsi, vaan siitä onko suunnitelmasi järkevä vai ei. Kannattaa huomioida, että esittämiesi asioiden käsittely asioina ei nimenomaan ole henkilöön menevä hyökkäys.
Monissa ohjelmointikielissä on järkeviä ja vähemmän järkeviä tapoja tehdä asia. Usein harjaantumattomat ohjelmoijat käyttävät vähemmän järkeviä menetelmiä, vaikka itse ovat ihan fiksuja.
Aivan, mutta, kun tämä kyseinen kirjoittaja _Pete_ on aikaisemmissa viesteissäänsä kutsunut minua tampioksi tai sivariksi nimeni yhteydessä ja vähätellyt useasti kykyäni ajatella aika suoraan, tämä on vain hänen tapansa muistuttaa minua noista kerroista.
Kuten jo sanoinkin kenellekkään ei pidä tulla epämiellyttävää oloa kun käyttää foorumia, tämä on ihan EU laki, _Pete_
Myös että tässä joutuu kirjoittamaan tämän kaltaista viestiä, osoittaa mitenkä huonosti meillä suomessa otetaan hyvä käytös huomioon keskustelupalstoilla.
EU:ssa on kielletty että joutuu kokemaan loukkauksia kun käyttää foorumeita joko ryhmän taikka yksittäisen henkilön kohdalta.
Nämä suositukset ovat jopa niin kireitä että on suosituksia että tiettyjä sanoja ei käytetä lainkaan ja lauseet rakennetaan ajatellen kaikki mahdolliset sana yhdistelmät mitkä voivat loukata.
kpzpt kirjoitti:
Minä ajattelin jonottaa nämä socketit ainoastaan tämän tilanteen varalta että kaikki asiakkaat siirtävät samaan aikaan, kun jos taas minulla on socketit jonossa jossa on aina jotain 25-50 kappaletta socketteja, niin, minulla ei ole käytännön riskiä usean threadin CPU piikeille aivan näin helposti ?
Kuten aiemmin mainitsin, normaalitilanteessa suurin osa säikeistä on blokkaus tilassa odottaessaan tavaraa sockettiin. En oikeasti usko, että jokunen sata asiakasta palveltuna jokainen omassa säikeessään saisi vuoropohjaisia hidastempoisia pelejä pyörittävää palvelinta polvilleen.
Luulen jopa, että normaalitilanteessa lukuisten timeout sockettien käyttäminen kuormittaa palvelinta enemmän (jatkuva kuorma), puhumattakaan toteutuksen paljon suuremmasta monimutkaisuudesta (kirjanpito timeout socketeista, asiakkaista ja peleistä).
jalski kirjoitti:
kpzpt kirjoitti:
Minä ajattelin jonottaa nämä socketit ainoastaan tämän tilanteen varalta että kaikki asiakkaat siirtävät samaan aikaan, kun jos taas minulla on socketit jonossa jossa on aina jotain 25-50 kappaletta socketteja, niin, minulla ei ole käytännön riskiä usean threadin CPU piikeille aivan näin helposti ?
Kuten aiemmin mainitsin, normaalitilanteessa suurin osa säikeistä on blokkaus tilassa odottaessaan tavaraa sockettiin. En oikeasti usko, että jokunen sata asiakasta palveltuna jokainen omassa säikeessään saisi vuoropohjaisia hidastempoisia pelejä pyörittävää palvelinta polvilleen.
Luulen jopa, että normaalitilanteessa lukuisten timeout sockettien käyttäminen kuormittaa palvelinta enemmän (jatkuva kuorma), puhumattakaan toteutuksen paljon suuremmasta monimutkaisuudesta (kirjanpito timeout socketeista, asiakkaista ja peleistä).
Minulla on myös tämä Java kokemattomuus, ja tämä että en halua myöhemmin parantaa koodiani, ja tämä suomenkielikin vähän mitä on.
Minä en osaa arvioida kuinka paljon säästän CPU tehoja, mutta arvioisin että säästän ainakin RAM muistia merkittävästi, minulla on 512m muistia palvelimessani, ja tahdon että palvelimeni pystyy palvelemaan satoja jos laitan sitten tuon 50-150 TCP threadia ja jokaiseen 25-50 sockettia, kun jos taas jokaiseen sockettiin oman threadin ja jokaisessa threadissa on oma koodikin joka vie RAM muistia muutaman sataa kiloa vaikkapa 200kiloa ja vaikka 1000 threadia, tämä on 200000 kiloa muistia minun 512000 kilostani.
Minä kun laitan yhteen threadiin koodin ja 25-50 sockettia, niin koodi muistia säästyy 25-50 kertaisena, kenties myös vaikka tuo 50-100 sockettia yhteen threadiin olisikin paree.
Ja juuri tuo monimutkaisuus mitä tämä hieman aiheuttaa on saanut minut kirjoittamaan tämän viestin - kuinka tämän kaltainen koodi olisi parasta rakentaa kulun puolesta ?
Tässä kuitenkin toiminta malli tämän hetkinen ->
Main alustus ja kulun ohjaus thread 1kpl.
- Kovalevy thread 1kpl.
- TCP pakettien käsittely thread 1kpl.
- 50-150 kpl TCP threadeja, 25-50 sockettia yhdessä, 250-500 stringbufferia yhdessä.
- 1 kpl luokka jossa kaikki kriittisten toimien muuttujat.
Pääsääntöisenä kulkua ohjataan tästä erillisestä luokasta joka sisältää vain toiminnan kannalta kriittisiä muuttujia. Tämä muuttuja luokka sitten löytyy kaikista muista koodi luokista ja koodi luokat toimivat löytyvien muuttujien mukaan.
kpzpt kirjoitti:
riskiä usean threadin CPU piikeille
Ketä se piikki muka haittaa? Tietokone on tehty käytettäväksi; jos et käytä sitä, olet maksanut siitä ihan turhaan.
Onko sinusta parempi pakottaa monta käyttäjää odottamaan aivan turhaan siksi, että palvelin saisi olla tyhjän panttina, vai jättää pari käyttäjää odottamaan pieneksi hetkeksi, kun palvelin tekee parhaansa muiden eteen?
Järkevät vaihtoehdot ovat joko säie per socket, jolloin socket voi olla blokkaava, tai kaikki socketit ilman timeouttia yhdessä säikeessä, jolloin käydään aina kaikki socketit läpi ja nukutaan sitten kierroksen lopussa, jos kenelläkään ei ollut asiaa. Kumpi tahansa näistä luultavasti riittäisi palvelullesi aivan hyvin.
Jos jossain vaiheessa näyttää, että verkkoyhteydet ovat molemmilla tavoilla rajoittava tekijä (mitä ei varmaankaan tule tapahtumaan), voit kehittää jonkin optimointikikan. Kuten sanoin, hyvin tehtyä on helppo korjata. Jos olet sitä mieltä, että korjaaminen on vaikeaa, luultavasti kyse on vain siitä, ettö koodisi on huonosti tehty (tai et ymmärrä itse, mitä olet tehnyt).
kpzpt kirjoitti:
Minulla on myös tämä Java kokemattomuus, ja tämä että en halua myöhemmin parantaa koodiani
No eikö sitä suuremmalla syyllä kannattaisi tehdä se jo ensimmäisellä yrityksellä niin, että se varmasti toimii? Molemmilla mainitsemillani tavoilla koodi on hetkessä valmis ja toimii lähes idioottivarmasti (mikä ei toki tarkoita, etteikö osaamaton koodari voisi kämmätä). Sen sijaan sinun tapasi on hirveän mutkikas ja sekava, sen toteuttaminen kestää kauan ja siihen luultavasti tulee monenlaisia bugeja.
Metabolix kirjoitti:
Järkevät vaihtoehdot ovat joko säie per socket, jolloin socket voi olla blokkaava, tai kaikki socketit ilman timeouttia yhdessä säikeessä, jolloin käydään aina kaikki socketit läpi ja nukutaan sitten kierroksen lopussa, jos kenelläkään ei ollut asiaa. Kumpi tahansa näistä luultavasti riittäisi palvelullesi aivan hyvin.
Tuon säie per socket olen jo hylännyt ihan tosissani, perustelin jo edellisessä viestissäni lopullisesti tuon vaihtoehdon, sekä CPU että RAM.
Tämä taas että socketit olisivat samassa threadissa vaikkapa 25-75 kappaletta, ja ilman timeouttia, minun java kokemattomuuteni vähän iski taas, jos laitan sotimeout (0) niin tämähän tarkoittaa sitten sitä että socket odottaa ikuisesti 0 = infinite ?
Heh, minä juuri näin olin rakentamassa, mutta siis tuolla 1 ms waitin kera, kun olen luullut että 0 wait ms on mahdotonta 0 = infinite, jos tuo 0 ms on mahdollista, niin, sitten voin laittaa vaikka 75-125 sockettia yhteen säikeeseen.
Odottelen vain niitä neuvoja tuohon koodin kulkuun ja luokka rakenteisiin :)
Main alustus ja kulun ohjaus thread 1kpl.
- Kovalevy thread 1kpl.
- TCP pakettien käsittely thread 1kpl.
- 50-150 kpl TCP threadeja, 25-50 sockettia yhdessä, 250-500 stringbufferia yhdessä.
- 1 kpl luokka jossa kaikki kriittisten toimien muuttujat.
Pääsääntöisenä kulkua ohjataan tästä erillisestä luokasta joka sisältää vain toiminnan kannalta kriittisiä muuttujia. Tämä muuttuja luokka sitten löytyy kaikista muista koodi luokista ja koodi luokat toimivat löytyvien muuttujien mukaan.
----
Myös metabolix:illa on painatusta sanoissa joittenka käyttö ei ole suotavaa EU foorumeilla.
( Idioottivarma, järkevä, sekava, jne.. )
kpzpt kirjoitti:
Nämä suositukset ovat jopa niin kireitä että on suosituksia että tiettyjä sanoja ei käytetä lainkaan ja lauseet rakennetaan ajatellen kaikki mahdolliset sana yhdistelmät mitkä voivat loukata.
Surullista, jos näin tosiaan on.
Olen kuvitellut, että eurooppalaiset olisi sentään vähän jenkkejä järkevämpiä tässä "poliittisessa korrektiudessa", mutta väitteesi valossa vaikuttaisi olevan päinvastoin. Onko sinulla mahdollisesti esittää linkkiä ko. direktiiviin?
kpzpt kirjoitti:
Myös metabolix:illa on painatusta sanoissa joittenka käyttö ei ole suotavaa EU foorumeilla.
( Idioottivarma, järkevä, sekava, jne.. )
Henkilökohtaisesti (ja väittäisin että yleisesti kaikki järkevät ihmiset) olen sitä mieltä, että jos joku on niin idiootti että ymmärtää esim. idioottivarma sanan haukkumasanana, niin sietääkin harmistua.
kpzpt kirjoitti:
Tuon säie per socket olen jo hylännyt ihan tosissani, perustelin jo edellisessä viestissäni lopullisesti tuon vaihtoehdon, sekä CPU että RAM.
Taas siis sama juttu: kysyit, miten kannattaisi toteuttaa, ja kun sinulle vastataan, sanot, että olet jo päättänyt tehdä tavalla, jonka moni vastaaja on tuominnut huonoksi. Miksi sitten edes kysyit?
kpzpt kirjoitti:
Tämä taas että socketit olisivat samassa threadissa vaikkapa 25-75 kappaletta, ja ilman timeouttia
Sanoin "kaikki" enkä "25-75 kappaletta". Näin huono ei sinunkaan suomen kielen taitosi voi olla.
kpzpt kirjoitti:
minun java kokemattomuuteni vähän iski taas, jos laitan sotimeout (0) niin tämähän tarkoittaa sitten sitä että socket odottaa ikuisesti 0 = infinite ?
Niin, sitä ei toteutetakaan samalla tavalla vaan luokilla ServerSocketChannel ja SocketChannel. Näistä löytyy tietoa ja lukuisia esimerkkejä aivan yksinkertaisilla hakusanoilla kuten "ServerSocketChannel", "SocketChannel" ja "non-blocking sockets" yhdistettynä sanoihin "Java" ja "example".
kpzpt kirjoitti:
Odottelen vain niitä neuvoja tuohon koodin kulkuun ja luokka rakenteisiin
Juuri niitä neuvoja olet saanut: Tee luokka, joka kuvaa yhtä asiakasta. Joko tee yhdestä asiakkaasta itsessään säie tai laita kaikki asiakkaat yhden hallintasäikeen sisään.
kpzpt kirjoitti:
tämä suomenkielikin vähän mitä on
Miksi edes olet suomenkielisellä foorumilla, jos suomi on sinulle niin hankala kieli? Kai nyt jokainen ohjelmointitaitoinen ihminen edes yhtä ihmistenkin kieltä osaa kunnolla (korjaa toki, jos olet poikkeus), joten kannattaisi valita foorumikin sen kielen mukaan.
kpzpt kirjoitti:
sanoissa joittenka käyttö ei ole suotavaa EU foorumeilla.
Olet varmaankin käsittänyt jotain väärin EU:n ohjeistuksesta. Ehkä kannattaisi lukea ne uudestaan jollain kielellä, jota ymmärrät paremmin.
kpzpt kirjoitti:
Idioottivarma, järkevä, sekava
Jos tällaisten tapotavallisten sanojen käyttö koodin tai ohjelmointitavan kuvailussa aiheuttaa sinulle sietämättömän pahan mielen, kannattanee konsultoida asian tiimoilta psykologia. Tai jos jotenkin onnistuit lukemaan viestin niin, että kyseiset sanat viittaisivat itseesi henkilönä, kannattaa konsultoida suomen kielen opettajaa.
lainaus:
Tämä taas että socketit olisivat samassa threadissa vaikkapa 25-75 kappaletta, ja ilman timeouttia
Sanoin "kaikki" enkä "25-75 kappaletta". Näin huono ei sinunkaan suomen kielen taitosi voi olla.
öh, joo mutta, en kykene ymmärtämään että kaikki socketit olisivat samassa threadissa, myönnän että se saattaa olla parempi CPU ja RAM kannalta, mutta, ei ihan näin tarkkaa tarvi olla.
kpzpt kirjoitti:
minun java kokemattomuuteni vähän iski taas, jos laitan sotimeout (0) niin tämähän tarkoittaa sitten sitä että socket odottaa ikuisesti 0 = infinite ?
Niin, sitä ei toteutetakaan samalla tavalla vaan luokilla ServerSocketChannel ja SocketChannel. Näistä löytyy tietoa ja lukuisia esimerkkejä aivan yksinkertaisilla hakusanoilla kuten "ServerSocketChannel", "SocketChannel" ja "non-blocking sockets" yhdistettynä sanoihin "Java" ja "example".
ServerSocketChannel ja SocketChannel, kiitosta noista, en ollut tietoinen tuollaisista ollenkaan, googlaan ne heti viikonloppuna ja vielä non-blocking sockets, hienoa, hieman epäilen kuitenkin että päädyn blockkaaviin socketteihin sittenkin.
kpzpt kirjoitti:
Odottelen vain niitä neuvoja tuohon koodin kulkuun ja luokka rakenteisiin
Juuri niitä neuvoja olet saanut: Tee luokka, joka kuvaa yhtä asiakasta. Joko tee tästä luokasta säie tai laita nämä kaikki luokat yhden hallintasäikeen sisään.
Juuri tuon olen suurinpiirtein jo kirjannut kun kysyin ekassa viestissä, toivoin myös hieman tarkempaa keskustelua koodin kulusta, minä olin ajatellut tästä ihan niin syvää ketjua että olisi mahdollisesti myöhemissä viesteissä puhuttu jopa yleisesti käytössä olevista muuttuja nimistä ja funktio nimistä, ja kerrottu sanoja joita suomalaisissa webbi ohjelmissa käytetään, mutta, minä olinkin rakentanut keskustelun suunnan hieman toiseen suuntaan kun se sitten eteni.
kpzpt kirjoitti:
Olet käsittänyt jotain väärin EU-säädöksistä. Ehkä kannattaisi lukea ne uudestaan jollain kielellä, jota ymmärrät paremmin.
Ei kyllä tämä on ihan totta, EU parlamentissa on ollut monta isoa keskustelua netti foorumeista ja niissä on myös päädytty asioihin, eteenkin siintä että yksittäisiä henkilöitä taikka ryhmiä ei aleta kohdella huonosti joko ryhmän taikka yksilön puolelta, EUssa netti on tarkoitettu, niin, jotta tiettyjä sana valintoja ja painoja ei käytetä lainkaan ja myös, niin, että ei pyritä ohjaamaan yleistä ymmärrystä ajattelemaan negatiivista toisesta kirjoittajasta. lähinnä syyt ovat eri ikäiset ihmiset ja myös eri kulttuuri taustoista tulevat. Mutta sama laki koskee myös kahdella suomi paidalla liikkujaa.
kpzpt kirjoitti:
Jos tällaisten tapotavallisten sanojen käyttö koodin tai ohjelmointitavan kuvailussa aiheuttaa sinulle sietämättömän pahan mielen, kannattanee konsultoida asian tiimoilta psykologia. Tai jos jotenkin onnistuit lukemaan viestin niin, että kyseiset sanat viittaisivat itseesi henkilönä, kannattaa konsultoida suomen kielen opettajaa.
Sinä et tunne sitä Eurooppaa taikka Suomea mitä minä tunnen, olet roskien tunkija, olen oikeassa tässä kun moitin sivustonne sana valintoja ja pyrkimystä tiettyyn yya alikersantti sävyyn keskustelu ketjuissa.
Te tarjoatte ajan kanssa loukkauksia, mutta, ette kykene rakentamaan lauseita jotka olisivat selkeitä kattavia vastauksia, minun kohdallani myönnän että minäkään en kykene täysin rakentamaan lauseita jotka ovat selkeitä kattavia kysymyksiä.
Saanen huomauttaa, että tuossa sinun tekstissäsi on jopa esimerkiksi minun tekstiäni tiheämmin sanoja, joita voi pitää loukkaavina tai tiettyä ihmisryhmää alentavana.
En silti itke niistä.
kpzpt kirjoitti:
Metabolix kirjoitti:
Olet käsittänyt jotain väärin EU-säädöksistä. Ehkä kannattaisi lukea ne uudestaan jollain kielellä, jota ymmärrät paremmin.
Ei kyllä tämä on ihan totta, EU parlamentissa on ollut monta isoa keskustelua netti foorumeista ja niissä on myös päädytty asioihin, eteenkin siintä että yksittäisiä henkilöitä taikka ryhmiä ei aleta kohdella huonosti joko ryhmän taikka yksilön puolelta
Väitteesi ei silti ole Metabolixin väitteen kanssa ristiriidassa. Siis, varmaankin EU:ssa on voitu käydä keskustelua, mutta olet ilmeisesti ymmärtänyt sen monelta osin väärin.
Jos sellaista sanaa tai sanayhdistelmää ei saa kirjoittaa, jonka jokin yksittäinen henkilö voi kokea loukkaavaksi, niin se tarkoittaa yksiselitteisesti sitä, että yhtään mitään ei voi kirjoittaa. Tuossakin äskeisessä lauseessa oli sana "voi", jonka joku painonsa kanssa epävarma saattaisi kokea loukkaavaksi.
Ymmärrän tavoitteen, että yritetään kitkeä tahallinen kiusaaminen. Kuitenkin jos "loukkaaminen" johtuu lähes yksinomaan siitä, että loukattu ei ymmärrä lukemaansa tai ymmärtää sen väärin, keksii siihen taka-ajatuksia joita kirjoittajalla ei ole ollut, tms. niin ei se voi olla kirjoittajan vastuulla.
En puutu offtopicciin vaan hyppään kysymykseesi stringbuffer-käsittelystä.
Oikeastaan vain sivuutan sitä.
En huomannut kertovasi mitä oikeastaan haluat tehdä stringbuffereissa oleville teksteille, mutta oletan että nämä tekstit ovat ohjaus komentoja tai muuta sellaista. Oletan myös että asiakasohjelmissa kirjoitat streameihin näitä ohjauskomentoja ja palvelimessa haluat parsia ne ja myös toisinpäin.
Itse teksisin keskustelun komento-olioilla, joita sitten kirjoittaisin ja lukisin streameista käyttäen javan serialisointia. Näin tiedot pysyisivät järjestyksessä olioiden sisällä automaagisesti.
Tietoa serialisoinnista:
http://java.sun.com/developer/technicalArticles/
Tämä on monimutkainen asia, minua sanotaan tyhmäksi ja minun ymmärrystäni moititaan, mutta tämä on monimutkainen asia.
Tässä on näitä mitä olen sanonut ->
on parempi että käyttää enemmän kuin yksi socket yhdessä threadissa.
on parempi että ei laita kaikkia socketteja yhteen threadiin.
olen kysynyt koodin kulkuun apuja kun minulla on rakenteilla pelipalvelu, palvelu sisältää ->
0) main ohjaus thread
1) kovalevy threadin
2) useita TCP Socket threadeja joissa useita socketteja ja stringbuffereita.
3) toiminta muuttuja luokka jota luetaan kaikissa threadeissa, threadit toimivat tämän mukaan.
Olen aika uusi säännölliseen foorumi käyttöön, olen pahoillani suomenkieleni takia, olen kirjoitellut todella vähän elämäni aikana, mutta, minä koen että minulle tarjotaan vastaukseksi sellaisia lauseita jotka eivät ihan vielä ole vastauksia koko ongelmaani, ja myönnän yhä että minulla on vaikeuksia rakentaa kysymyksiä näin vaikeasta aiheesta.
Tuo asiakas luokka jonka metabolix on maininnut todellakin puuttuu tuosta minun kasauksestani, tämän kaltaisia lauseita minä taidan odottaa, ja sitten hieman siintä mitä tuonkaltainen asiakas luokka yleensä sisältää, kun kyseessä on palvelin ohjelma.
( Edit. ehti tulla yksi viesti väliin )
Kyllä olen käyttänyt OBJECT ominaisuutta ja myöskin Stringbuffereita palvelin "<KÄSKYJEN>" siirtoon, streameissä, minulla on myös varsin hieno oma skanneri luokka, joka lukee ja vertaa huomattavan nopeammin mitä Javan oma, useita kymmeniä tuhansia käskyjä sekuntti, palvelimen 1.6Ghz ATOMissa.
this.vars.ois [ fslot ] = new ObjectInputStream ( this.vars.socket [ fslot ].getInputStream ( ) );
this.vars.oos [ fslot ] = new ObjectOutputStream ( this.vars.socket [ fslot ].getOutputStream ( ) );
public boolean TCP_SendString ( String sendString , int slot )
{
Thread.yield ( );
try
{
this.vars.oos [ slot ].writeObject ( sendString );
return true;
}
catch ( IOException e )
{
return false;
}
}
public String TCP_RecvString ( int slot )
{
Thread.yield ( );
try
{
return ( String ) this.vars.ois [ slot ].readObject ( );
}
catch ( IOException e )
{
return ""; //$NON-NLS-1$
}
catch ( ClassNotFoundException e )
{
return ""; //$NON-NLS-1$
}
}Oletin haluavasi lähetellä tekstiä, numeroarvoja ja muun tyypisiä tietoja sekaisin asiakkaalta palvelimelle ja toisinpäin.
Heh, nyt sanoit aika hyvän, minä ajattelin rakentaa STRING muotoon kaikki, minulla on tämä oma skanneri luokka rakennettuna ja taidan olla vähän sokea sen takia, mutta ajattelin käyttää sitä toimessa.
Yhdelle riville yksi käsky ja käskyt luetaan rivi kerrallaansa siirretystä stringistä.
Stringbuffer <- "<ONLINE><kpzpt>"
Stringbuffer <- "<SHAKKISIIRTO><d2d4>"
Stringbuffer <- "<IPILOTIT1917><KONE1POS=(1000,1000)><KONE2POS=
tuosta kun pudottaa ainakin välilyönnit ja sulut, niin käskyt ja luvut jäävät jäljelle, loppu peleihin sitten typistän kaikki käskyt kahteen taikka enintään kolmeen kirjaimeen, floatteja en taida käyttää, myös siirtymä lukuja voisi harkita tarkkojen arvojen sijaan.
Eli mitä oikeastaan tarkoitit tekstien käsittelyllä?
Ja minkälaisia neuvoja haluat?
Käskyjen käsittelyssä otan tuon sinun neuvosi harkintaan, aika isolla sävyllä vielä, on varmaankin mukavampaa sitten tarkistaa mitä OBJECT sisältää ( String vai int vai float ), kuin vain käsitellä koko ajan stringejä, mutta, tämäkin koko koodi osa on minulle täysin uusi, kiitos linkistä.
Mutta minulla on tämä koodin kulkukin jo hahmottunut hieman paremmin kun tässä sählännyt foorumin kanssa.
olen kysynyt koodin kulkuun apuja kun minulla on rakenteilla pelipalvelu, palvelu sisältää ->
0) main ohjaus thread
1) kovalevy threadin
2) useita TCP Socket threadeja joissa useita socketteja ja stringbuffereita.
3) toiminta muuttuja luokka jota luetaan kaikissa threadeissa, threadit toimivat tämän mukaan.
Tuota olen rakentamassa ja minulla olisi tarkoitus jotenkin esi ajatella tuossa koodin kulkua ja mahdollisesti lisätä puuttuvia koodi luokkia.
( Edit. tuohon OBJECT käsittelyyn vielä, minulla kuitenkin on tarkoitus että palvelin ei sisällä itse tietoja peleistä, jotenka kenties sittenkin jätän tuon pelkän STRING siirron, palvelin sisältää tietoa peleistä vain kun peliä tallennetaan kovalevylle taikka ladataan sieltä, hmmh, kyllä tämä STRING taitaa olla sittenkin helpompaa )
Taas olen olettamassa jotain, eli kovalevy säie tallentaa ja lukee käyttäjien tietoja tiedostoista. Ja taidan puutua vääriin asioihin.
Olen sen verran tietokantojen kanssa leikkinyt (tehnyt työkseen järjestelmiä, jotka käyttävät tietokantoja), että itse käyttäisin tässäkin tietokantaa ja sitä JPA:ta ja Hibernate:a käyttäen. Eli taas tallennettaessa tietoja annettaisiin olio, joka tallennetaan. Ja haettaessa saataisiin vastaukseksi olio tai olioita, riipuen mitä haetaan. Tietokantana tässä voisi käyttää Apache Derby:ä, tai sen voi myös sisällyttää palvelimeen siten että se käynnistyy kun palvelinkin käynnistyy.
Tämä voi kyllä olla iso pala uutta, mutta sillä hoituu moni hankala asia.
http://hibernate.org/
http://docs.jboss.org/hibernate/core/3.6/
http://db.apache.org/derby/
Ja hyvää uutta vuotta!
Kovalevy thread!
kyllä vain, kovalevy thread lataa ja tallentaa pelaajan tietoja sekä keskeneräisiä pelejä ja vielä peli "filmejä", eli jo pelattuja pelejä.
Eli, mitä mieltä olisit seuraavasta, joka minulla on kasattuna,
Pelaaja nimessä sallittuja kirjaimia A-Z a-z 0-9
Minä rakennan kansioita AAAA - ZZZZ taikka - 9999, ja näihin tallennan pelaaja nimen mukaan,
esim. kpzpt menisi uppercasena kansioon /home/jtapio/DataKansio/KPZP/pelaaja-info_KPZPT.txt
taikka sitten tuo toinen kansio vaihtoehto /home/jtapio/DataKansio/K/P/Z/P/pelaaja-info_KPZPT.txt
Seuraavalla koodilla savean .txt fileenä ja ihan vastaavana "strLoadStr=readFromDisk ();" luen takaisin.
Lukeminen/tallennus on blockkaavaa levytoimi threadissa joita on siis vain yksi palvelimessa, ja minun pää muuttuja luokasta luetaan aina toiminta ohjeet kuinka teksti ja mitä tekstiä ohjataan ?
private void writeToDisk ( String strFileName , String strSaveStr )
{
try
{
BufferedWriter out = new BufferedWriter ( new FileWriter ( this.directory + strFileName ) );
out.write ( strSaveStr );
out.close ( );
}
catch ( IOException e )
{
e.printStackTrace ( );
}
}Minulle kaikki todella suosittelevat databasea, mutta, koen hieman että tämäkin voisi olla riittävää ?
Sinä vaikutat asialliselta ja olet työpätevä ohjelmoinnin suhteen, mitäs tuumaat, tämä taitaa olla se köyhän miehen database numero 1 ?
Minulle riittäisi kun muuttaisin muutamaa muuttujaa, "Global" päämuuttuja luokasta ja kaikki nämä threadit toimisivat heti oikein, aika houkuttelevaa hylätä database ?
Selaan noita ensi viikolla, noita linkkejä, vaikuttavat aika tuhdilta.
Hyvää uutta vuotta kaikille !!
Olen monesti ennenkin todennut, että käyttämällä tietokantaa saa valmiiksi tehtynä todella ison palan työtä, jonka muuten joutuisi tekemään itse.
Ja tietokantoja ja niiden taustalla toimivia teknologioita on vieläpä kehitetty ja viilattu jopa useita vuosikymmeniä. On siis jokseenkin mahdotonta että yksittäinen koodari tekisi kohtuullisessa ajassa oman paremmin toimivan tiedontallennussysteemin.
Itse olen myös tehnyt järjestelmiä jossa käytetään tietokantoja ja sellaisia, jossa tallennetaan tiedot muulla tavoin. Käytännössä ainoat tilanteet, joissa ei ole kaivannut tietokantaa on ollut muutaman ohjelman asetuksen tallentaminen asetustiedostoon tms.
Toki tietokannoissa on jonkinmoinen kynnys opetella, mutta se myös palkitsee jatksosa ruhtinaallisesti.
Periaatteessa voisi toimia, mutta haut muilla tiedoilla kuin nimellä ovat tuhoontuomittuja. Ja kaikkalla pitää viitata pelaajaan sen nimellä. Sekä nimessä olevat merkit pitää rajoittaa merkkeihin mitkä ovat sallittuja tiedoston nimessä. Olen huomannut että ID-numerolla on monessa mielessä paremi viitata asioihin kuin tekstillä. Joskus on välilyönnit tai erikoismerkit tuottaneet hankalia tilanteita.
Suosittelisin tietokantoja senkin vuoksi että erilaisten tilastojen hakeminen ja esittäminen on niillä helpompaa. Esimerkiksi moni voisi haluta nähdä listan "TOP 10 pelaajat", jossa näytettäisiin esimerkiksi pelaajat, joilla olisi eniten voittoja suhteutettuna pelattuihin peleihin.
En tajua tuota että tallentamiseen olisi valjastettu säie. Jos haluat antaa yhen säikeen tallentaa tiedostoan kerrallaan, voit asettaa kirjoitusmetodille syncronized määreen, jolloin muut säikeet jääväät odottelemaan kun yksi tallentaa. On myös muitakin tapoja hallita säikeitä.
http://download.oracle.com/javase/tutorial/
http://download.oracle.com/javase/tutorial/
Ainakin sen parannuksen ehdotan, että kirjoita ja lue serialisoinnin avulla pelaajan tiedot olioina. Paitsi tämä hankaloittaa asioita silloin, kun lisäät tai poistat pelaajaluokasta attribuutteja. Tällöin joudut luultavasti konvertoimaan tiedostot lukemalla vanhaa luokkaa käyttämällä ja kirjoittaa uutta käyttämällä.
Äh, en tainnut päätyä mihinkään järkevään tulokseen. Nyt tuli pohdittua vain yhtä kohtaa, mutta jatkan myöhemmin. Yöt.
kpzpt kirjoitti:
Kuten jo sanoinkin kenellekkään ei pidä tulla epämiellyttävää oloa kun käyttää foorumia, tämä on ihan EU laki, _Pete_
Ahaa. Mistä tämä lakipykälän olemassa olon voi tarkistaa?
Btw (= muuten), ihan turhaan mietit cpu/ram kulutusta. Jo se että käyttää
Javaa on tuhoon tuomittu tuossa suhteessa. Itsessään virtuaalikone vie
monta kymmentä megaa muistia. Jos oikeasti haluat noista murehtia tee ohjelmasi
C:llä.
Mutta on se hyvä että voi jokaisessa asiassa mennä ns. perse edellä puuhun.
_Pete_
Olet valinnut sen että kirjoitat neuvoja keskustelu foorumilla, minkä takia et voi luovuttaa näitä neuvoja ilman loukkaavaa ja alentavaa sävyä, oletko sinä pettynyt siihen että ihmiset ovat niin hirveän huonoja ? Minä koen että olet hieman häirikkö, myöskin pyytäisin jälleen älä kirjaa vastauksia minun viesteihini, tämä on ihan sen takia että voin käyttää foorumeita ilman huonoa oloa taikka "ennakko aavistuksia" mitenkä keskustelu ketjuni loppuvat, johonkin loukkaavaan lauseeseen sinun taholta jonka jälkeen kaikki ymmärtävät kuinka oikeassa sinä olet kirjoittajan suhteen, uskon että kehityt miehenä kun noudatat neuvojani ?
Minä haluan jutella mukavia :)
kpzpt kirjoitti:
_Pete_
Olet valinnut sen että kirjoitat neuvoja keskustelu foorumilla, minkä takia et voi luovuttaa näitä neuvoja ilman loukkaavaa ja alentavaa sävyä, oletko sinä pettynyt siihen että ihmiset ovat niin hirveän huonoja ? Minä koen että olet hieman häirikkö, myöskin pyytäisin jälleen älä kirjaa vastauksia minun viesteihini, tämä on ihan sen takia että voin käyttää foorumeita ilman huonoa oloa taikka "ennakko aavistuksia" mitenkä keskustelu ketjuni loppuvat, johonkin loukkaavaan lauseeseen sinun taholta jonka jälkeen kaikki ymmärtävät kuinka oikeassa sinä olet kirjoittajan suhteen, uskon että kehityt miehenä kun noudatat neuvojani ?
Minä haluan jutella mukavia :)
Kiitos kommenteista. Unohdit kuitenkin pistää linkin tuohon lakipykälään mistä olin kiinnostunut. Kävikö nyt sillä tapaa että valehtelit ja moista pykälää ei ole olemassakaan? No se kylläkin sopii hyvin linjaan muiden juttujesi kanssa joten en ole kovinkaan yllättynyt tästä käänteestä.
Jos haluat jutella mukavia, suosittelen että menet tänne
Mutta tässä ohjelmointihommassa, ei auta hihittelyt vaan on kyse siitä mikä loogisesti toimii tai ei toimi. Sinun versiot on tähän mennessä ollut noita jälkmmmäisiä. Jos kuitenkin haluat jotain oppia, että ne eivät enää olisi jälkimmäisiä, pitää sinun asenteen suuresti muuttua.
Heh!
Vieläkin hieman kun sävy muuttuu, niin hyvä.
Tuohon EU lakiin, niin, en ole varma onko jotain jo voimassa, mutta, EU parlamentissa todella käydään keskustelua Foorumi käytöksistä, lähinnä keskustelun aiheena on eri ikäiset ihmiset ja eri kulttuuri taustoista tulevat, mutta, on ainakin ehdotettu siten että foorumin ylläpitäjillä olisi velvoitteita siihen, että ketään ei joudu kokemaan loukkaavaa sävyä jatkuvasti joko ryhmän taikka yksilön taholta, sinä ainakin ajoittain rikot tätä EU periaatetta, josta en tiedä joko on lain muodossa, vähintään on yleistä ymmärrystä siihen että ihmiset olisivat kohteliasta foorumeissa eikä loukkaavaa sävyä turhaan esiintyisi, ihmiset ovat eri ikäisiä ja eri taustoista tulevia kun käyttävät foorumeita jotenka konflikteja syntyy välistä, mutta jos joku jatkuvasti ylläpitää loukkaavaa sävyä, niin empä tiedä mitä miettiä.
----
Minulla on kuitenkin touhut nyt taas hieman edennä, kiitos tuolla yllä kun joku mainitsi nämä "serversocketchannel" nonblocking serversocketit.
Eli, minulla oli alunperin tarkoitus rakentaa tämä ensimmäinen palvelin ohjelma UDP paketeilla, mutta, siinä sitten jos tulee tilanne että jollakin on hieman hitaampi siirto, vaikka tavallinen modeemi jossain pitäjästä, niin tämähän taitaa silloin hidastaa myös muita, kun UDP portit luetaan viesti kerrallaansa.
Minulla on nyt sitten katsauksessa nonblocking socketit, ja ajattelin sitten käyttää testi palvelimessa jota nyt rakentelen, niin näitä serversocketchanneleita taikka tavallisia blockkaavia TCP paketteja, nämä sitten ajattelin jakaa vielä määräämättä, kait erillisiin threadeihin joko yksi taikka useampi socket yhteen.
Samalla testaan eri AWT komponentteja TextArea ja TextField ja List, taitavat nämä AWT komponentit olla astetta helpompaa mitä socketit.
Eli, kysymys voisi olla sitten vielä kerran kuinka olisi parasta rakentaa koodin kulku peli palveluun, socketeista STRINGEJÄ.
1) Kaikki socketit erillisiin threadeihin vaiko yhteen threadiin useita socketteja.
2) Laitanko yhden muuttuja luokan jota käytettäisiin "globaalisti", näin, että kaikki threadit toimisivat tämän muuttuja luokan muuttujien arvojen mukaan, eli ei olisikaan mitään ohjaavaa main koodi looppia vain muuttuja taulukko jonka mukaan palvelin elää.
3) Kuinka olisi hyvä rakentaa ne viestit jotka menevät palvelimen läpi asiakkaalta asiakkaalle, ja sitten taas nämä jotka ohjaavat pelaajan kulkua palvelimessa, en haluaisi lukea kaikkia viestejä joita palvelimeen tulee.
4) Jos käytän tälläistä globaalia muuttuja luokkaa joka ohjaa kaikkia threadeja, niin mitä kaikkea muuttujaa siellä olisi hyvä esiintyä.
5) Jos käytän tälläistä globaalia muuttuja luokkaa joka ohjaa kaikkia threadeja, niin mitä tuumaatte että josko käyttäisin vain STATIC muuttujia.
----
Kiitosta mahdollisesta avusta, olen vielä kerran pahoillani suomenkieleni takia, ja myös tämän että en osaa Java ohjelmointi kokemattomuuteni takia suoraan kysyä kokonaisia "valmiita" kysymyksiä vaan vähän haahuilen aiheessa, en ole ihan oikea ohjelmoija !
----
Mua alkaa just nyt loukkaamaan tämä hyvien neuvojen aliarvostus. Älä kysy jos ei neuvot kelpaa. Siitä tulee minulle epämiellyttävä olo. Ja minua myös loukkaa se että samalla aliarvioit juuri niiden henkilöiden taitoja, jotka sinua yrittävät ohjeistaa.
JA jos jostain asiasta on ollut keskustelua, se ei ole laki. Se ei ole mitään.
Maailmassa käydään kuitenkin suht paljon keskusteluja.
kpzpt kirjoitti:
1) Kaikki socketit erillisiin threadeihin vaiko yhteen threadiin useita socketteja.
Lue tämä keskustelu, siinä on käsitelty juuri samanlaista ongelmaa perusteellisesti ja kerrottu kaikki olennainen tästä socket-kysymyksestä.
kpzpt kirjoitti:
2) Laitanko yhden muuttuja luokan
Älä laita. Lue tämä keskustelu, jossa on jo puhuttu luokkien järkevästä käytöstä.
groovyb kirjoitti:
Mua alkaa just nyt loukkaamaan tämä hyvien neuvojen aliarvostus
Joo. Ehkä olisi viisainta, ettei kukaan vastaisi näihin aiheisiin, kun ei siitä näytä olevan mitään hyötyä.
öh!
Minun vikani on se että en tunne Javaa tarpeeksi jotta osaisin rakentaa niistä aiheista kattavia kysymyksiä jotka minulle vaikeita ovat, kysymykseni ovat kovin alkeellisia ja pinnallisia.
Minä myös hieman olen odottanut että useampi henkilö vastaisi, en tarkkaan tunne keskustelu palstanne toimi tapoja, mutta nyt on 3-5 henkilöä vastaillut, olen esittänyt samaa kysymystä jotta myös muita vastaajia tarttuisi onkeen ajan kanssa, jotta saisin kattavamman kuvan, ja mielelläni en kuulisi mitä tehdä vaan miksi tehdä ja tämä hauska kohta jota ilmeisesti ette ole ymmärtäneet, en tunne Java ohjelmointi kieltä niin hyvin että pystyisin itse sanomaan milloinka kaikki hyvät neuvot on jo annettu ?
Minä kuitenkin vähän koen että minun luottoni tähän keskustelu palstaan on heikentynyt kovin, 3-5 vastaa, pääsääntöisenä ajan kanssa loukaten ja vähätellen ja siihen sävyyn että heidän jälkeensä ei tarvitse enää vastailla, pyrkien katkaisemaan ketjun.
Mitä jos nämä 3-5 vastailijaa käsittäisi että en tarvitse heiltä enää neuvoja jos he kaikkensa ovat jo vastaukseensa antaneet, ja luovuttaisivat näin muille mahdollisuuden kertoa näkökantojaansa, tuollainen yleinen alentaminen jossa kaikkien täytyy ymmärtää kuinka huono olen on turhaa, jos jatkuu niin minä poistun tältä keskustelu palstalta.
----
Mutta, olette oikeassa olen vastaanottanut monta hyvää neuvoa, ja minulla on hienosti onnistunut nämä ensimmäiset palvelin testit, kotikoneeni ja palvelimeni välille, huomenna on tarkoitus rakentaa tämä "global" muuttuja luokka, laitan sinne muutaman syncronized metodin joukkoon helpottamaan thread hallintaa, lisänä ajattelin laittaa kaikki socketit [] jonoon tuonne "global" muuttujien joukkoon ja kun sockettia tarvitsee lukea/kirjoittaa niin käynnistetään erillinen thread joka kerran lukee/kirjoittaa ja sammuu sitten.
Tämä koko palvelin ohjelma taitaa sittenkin olla yksinkertaisempaa ja helpompaa mitä vielä eilen mietinkään, ja valmistua aika nopeasti.
Kiitosta siis silti vaikka vähän turhaa vikinää tässä ketjussa ollut runsaastikkin.
----
Minusta vastausten laatu vs. niiden määrä on tarpeellisempi. Minulla ei ole mitään mahdollisuuksia osallistua tämän langan alkuperäiseen kysymykseen, koska minulla ei ole kokemusta tällaisesta. Sinulle vastanneet 3-5 henkilöä omaavat kokemusta tällaisista ongelmista. Lukemalla vastaukset huomaat niiden olevan aivan erinomaisia.
kpzpt kirjoitti:
Minä myös hieman olen odottanut että useampi henkilö vastaisi – – Nyt on 3-5 henkilöä vastaillut, olen esittänyt samaa kysymystä jotta myös muita vastaajia tarttuisi onkeen ajan kanssa, jotta saisin kattavamman kuvan – –
Eivät ne tosiasiat siitä miksikään muutu, vaikka sata ihmistä kävisi sanomassa ne. Kolmekin on jo aivan riittämiin. Useimpiin ohjelmointiongelmiin riittää aivan hyvin yhden tai kahden asiantuntevan henkilön vastaus, ja yleensä useampi vastaa vain, jos on jotain uutta sanottavaa tai jos näyttää, ettei kysyjä jostain syystä ymmärrä vastausta. Nyt olet saanut jo monta aivan samanlaista vastausta, mistä voi päätellä, että asiaan ei ole tämän enempää näkökulmia.
Sitä paitsi on aivan turhaa, harhaanjohtavaa ja ärsyttävää esittää uudestaan samaa kysymystä: muut joutuvat silloin miettimään, oletko ehkä laiska tai tyhmä, kun et kelpuuta annettuja vastauksia. Juuri siitä luultavasti johtuvat saamasi "ilkeät" viestit. Jos olet ymmärtänyt vastaukset mutta haluat vielä pyytää lisää näkökulmia, voit ilmaista asian suomen kielellä näin: "Kiitos vastauksista, onko jollakulla vielä muita näkökulmia aiheeseen?"
kpzpt kirjoitti:
en tunne Java ohjelmointi kieltä niin hyvin että pystyisin itse sanomaan milloinka kaikki hyvät neuvot on jo annettu
Silloin sinun kannattaisi vain uskoa, kun Javaa paremmin tuntevat sanovat, että asia on näin eikä muuta sanottavaa ole. (Jos vastauksemme olisivat vääriä, joku olisi melko varmasti jo tullut haukkumaan meitä ja sanomaan, miten asiat oikeasti ovat.)
kpzpt kirjoitti:
mielelläni en kuulisi mitä tehdä vaan miksi tehdä
Jotta ohjelmastasi tulisi mahdollisimman varmasti toimiva mahdollisimman pienellä vaivalla. Mikä muukaan syy voisi olla? (Tämäkin on sanottu sinulle jo monessa viestissä monella eri tavalla.)
kpzpt kirjoitti:
Mitä jos nämä 3-5 vastailijaa – – luovuttaisivat näin muille mahdollisuuden kertoa näkökantojaansa
Mikään ei estä ihan jokaista kertomasta näkökantaansa. Internetissä nimittäin jokainen voi kirjoittaa samaan aikaan, ei tarvitse erikseen saada puheenvuoroa.
kpzpt kirjoitti:
tuollainen yleinen alentaminen jossa kaikkien täytyy ymmärtää kuinka huono olen
En usko, että kenenkään tarkoitus on saada muita omaksumaan tietynlaista käsitystä sinusta, vaan tarkoitus on muuttaa sinun omaa käytöstäsi foorumilla järkevämmäksi (kuten tämän vastauksen alussa sanoin).
kpzpt kirjoitti:
kun sockettia tarvitsee lukea/kirjoittaa niin käynnistetään erillinen thread joka kerran lukee/kirjoittaa ja sammuu sitten
Threadin käynnistäminen on hidasta, joten niitä ei kannata availla ja sulkea jatkuvasti yksittäisten lukuoperaatioiden takia. Jos välttämättä haluat käyttää säikeitä tuohon tapaan, käytä Javan valmista thread pool -systeemiä, jossa säikeet luodaan valmiiksi ja ne vain odottelevat töitä.
Tuollaisesta järjestelystä ei kuitenkaan ole mitään hyötyä. Säikeiden idea tässä olisi, että yksi säie voi lukea jatkuvasti yhtä sockettia ja ilmoittaa sitten pääohjelmalle, kun dataa tulee. Jos taas lukemista hallitaan pääohjelman puolelta, on kannattavampaa tarkistaa suoraan samassa säikeessä siellä, onko dataa tullut. Tarkistus (kun kyseessä on non-blocking socket) vie murto-osan siitä ajasta, jonka säikeen käynnistäminen veisi.
kpzpt kirjoitti:
Minä myös hieman olen odottanut että useampi henkilö vastaisi, en tarkkaan tunne keskustelu palstanne toimi tapoja, mutta nyt on 3-5 henkilöä vastaillut, olen esittänyt samaa kysymystä jotta myös muita vastaajia tarttuisi onkeen ajan kanssa, jotta saisin kattavamman kuvan
Tuskin ketään kiinnostaa vastata jos
1) Vastaus on jo ketjussa
2) Kysyjä ei arvosta vastauksia eikä halua niitä (eli jos joku on eri mieltä toteutustavasta, niin vetoaa ylläpitoon vastaajan hiljentämiseksi)
Ei ohjelmointiin liittyvät neuvot ole mikään huutoäänestys, jossa olisi iso määrä erilaisia mielipiteitä, ja vaikka olisikin niin paras ratkaisu ei välttämättä olisi se, joka saisi eniten "ääniä".
ok!
Opin paljon webbi foorumeista tässä ketjun aikana, oikeastaan aika myöhään joskus 2005 vasta aloittelin käyttämään foorumeita, ja olenkin kirjoittana nettiin loppujen lopuksi todella vähän, ja ne mitä olen kirjannut kysymyksinä ovat olleet todella pinnallisia.
----
Sain myös varmuutta Java sockets ohjelmointiin ja threadien käyttöön, ja mitä tähän turhaan turinaan mitä näissä minun parissa viime ketjussa on ollut, niin, syytän itseäni siintä että en ole osannut ohjelmointi kokemattomuuttani rakentaa kysymyksiä, enkä täysin ole osannut ymmärtää annettuja vastauksia, minä taisin jäädä odottamaan sitä kattavaa "miksi tehdä näin" vastausta jonka olisi ymmärtänyt.
----
Rakentelen tämän loppu viikon aikana sitten tätä serveri ohjelmaa, ilmoittelen varmaankin viikonloppuun mennessä mitenkä edistyn, opiskelin tuossa sivussa jo myös AWT komponenttien käyttöjä, ja mahdollisesti niitäkin voisin jo lisätä noihin pariin demoon mitä on jo kasattuna.
Aiheesta sinällään saattaisi irrota enempikin rakentavaa keskustelua ja mielipiteitä suuntaan jos toiseen jos:
A) keskustelun aloittaja ymmärtäisi annetut vastaukset ja osaisi esittää niiden pohjalta järkeviä jatkokysymyksiä
B) keskustelun aloittaja pystyisi ymmärtämään sen tosiasian, että kiriittiseen sävyyn kirjoitettu vastaus ei ole tarkoitettu henkilökohtaiseksi loukkaukseksi, vaan kertomaan että mennään väärään suuntaan.
C) jos joku jaksaisi muistaa alkuperäisen kysymyksen sen jälkeen kun on lukenut keskustelun, jonka sisällöstä 90 prosenttia on aiheeseen liittymätöntä (lähinnä aloittajan toiveita siitä mihin suuntaan ja miten HÄN haluaa keskustelua käytävän?!?)
D) Jos hyviä neuvoja ei ohitettaisi suoraan tyyliin "minusta on parempi mennä perse edellä petäjään". Vain siksi että äänet päässä kertovat näin olevan parempi. (Vastaukseen voi tehdä jatkokysymyksiä jos vastauksen paremmuus askarruttaa ja eritoten mikä siinä askarruttaa)
Ja sanon nyt tähän loppuun sen, että vaikka tämä vastaus on kirjoitettu kriittiseen sävyyn, ei se ole tarkoitettu kenellekkään henkilökohtaisena loukkauksena.
Kyllä!
Olet oikeassa, myönnän, mutta tämä pitkä netti keskustelu on kovin erillaista mitä pitkät ihmisten väliset keskustelut joissa on helppo poiketa aiheesta ja sitten palata takaisin, minä en ole ihan vielä valmis kysymään näin monimutkaista asiaa, mitä on kokonaisen pelipalvelun (+30 peliä) koodin kulun selkeyttäminen.
Rakennan neuvojenne mukaan nyt tällä viikolla ensimmäisen palvelin ohjelman ja tulen sitten viimeistään ensi viikolla takaisin, toivon että keskustelu kulkee sitten paremmin kun minullakin on kokemusta enemmän, niin foorumien käytöstä pitkissä syvissä aiheissa ja myöskin Java ohjelmieni rakenteluista.
----
Aihe on jo aika vanha, joten et voi enää vastata siihen.