Pelipalvelun käyttäjätiedot !
Olen aika vaillinaisilla Java kyvyillä rakentamassa sotalautapelisivustoa.
Olen varmaankin enemmänkin sotalautapelisuunnittelija, kuin mitä ohjelmoija taikka edes Java harrastelija.
Tässä on kuitenkin valmistuva shakkini ( hiirirulla zoomaa ) -> http://temp4322.dy.fi/PeliAppletti.html
Itse sivusto -> http://temp4322.dy.fi
Tarkoitus tuohon Applettiini, johonka myös kaikki muut pelini liitetään, niin, asettaa alkuruutuun salasana kysely, samalla sivulla tulisi voida myös rekisteröityä !
Koska olen nyt sitten tälläinen harrastava lautapelisuunnittelija enkä ohjelmoija, niin, kysyisin hieman mitä lähestymis tapoja tulisi asettaa omiin taitoihin, kun tahtoisi että Appletti tarkistaa salasanan ja käyttäjätunnuksen ja myöskin ottaa vastaan uusia käyttäjiä, myöskin niin tulisi olla että selain muistaisi jos on jo kirjannut itsensä aikaisemmin.
Josko jollakin olisi ideaa taikka taitoa, kuinka olisi parasta lähestyä salasana ja käyttäjätunnus, tarkistuksia ja tallenteluita, en mieluusti tahtoisi myöhemmin enää parantaa taikka korjailla asiakkaitten sisään kirjoitteluitten koodia ?
Kannattaa selvittää itselleen ensimmäisenä, mitä eroa on nettisivulla/nettipalvelulla ja Java Appletilla. Applet, Flash ja Javascript ovat tavallaan rinnakkaisia tekniikoita eli niitä suoritetaan käyttäjän selaimessa palvelimen sijaan.
Jos teet Appletin, joka kykenee itsenäisesti tarkastamaan kirjautumisen, julkaiset käytönnössä salasanat ja tunnukset kaikelle kansalle. Eli pelkällä Appletilla homma ei ole mahdollinen. Jos haluaa, että kirjautuminen tapahtuu Appletin kautta, pitää tehdä palvelimelle kirjautumispalvelu, jonne applet lähettää tunnuksen & salasanan ja saa paluupostina kirjautumistiedot. Samoin jos haluat appletissa tallentaa jotain varmasti pysyvästi, se pitää lähettää palvelimelle.
Tämä sillä varauksella, etten ole yhtään applettia ikinä tehnyt ja muutenkin aika pintapuolisesti tekniikkaan tutustunut.
Rekisteröityminen sivustoon !
Minulla on oma palvelin Ranskassa, ja appletti ladataan palvelimesta ja palvelimeen appletti sitten ottaa myös yhteyden.
Palvelin ohjelmistoja ei ole kokemus listassa vielä lain, nyt sellainen pitäisi kuitenkin rakentaa, minulla on ideana seuraavanlainen ->
Palvelin ohjelma ->
rekisteröityminen :
asiakasohjelma lähettää palvelimeen asikkaan nimen, salasanan ja sähköpostin.
palvelin ohjelma lähettää varmistus sähköpostin asiakkaan sähköpostiin joka sisältää avaimen, kun avain aktivoidaan, on asiakastili käytössä.
palvelin ohjelma varmistaa että samasta ipstä ei voi rekisteröidä kuin 10 uutta asiakasta joka päivä, ja ilmoittaa aina jos useita rekisteröityy samasta ipstä.
palvelin ohjelma tallentaa asiakkaan tiedot mysql databaseen.
asiakkaan tiedot siis ovat ->
pelaajan nimi.
pelaajan salasana.
pelaajan sähköposti.
pelaajan oikeustaso palvelimessa.
pelaajan tilin vanhenemis päivämäärä, = 6kk edellisestä käytöstä.
----
Ei aikaisempaa kokemusta mysql käytöstä, mysql käyttö tulisi sitten tuohon minun palvelin ohjelman threadiini, voisiko joku hieman auttaa alkuun.
Myöskin minun tulisi tallentaa pelaajien keskeneräisiä ja jo pelattuja pelejä palvelimeeni, kuinka olisi mysql databasea oikein käyttää tällöin ?
Minulla on ihan ok palvelin ja haluan rakentaa varmuudeksi, ihan koko resursseja käyttävän pelipalvelun.
----
Vielä varmuudeksi kysyisin, että josko sittenkin käyttäisin teksti tiedostoja enkä databasea, mitä tuumaatte onko ihan mahdoton ajatus käyttää sittenkin teksti tiedostoja ja niihin pelaaja stringit ja save stringit.
Minulla on käytössä U804 palvelimessa, en oikeastaan tiedä kuinka monta tiedostoa voi tallentaa yhteen kansioon U804 kanssa, taikka kuinka monta kansiota voi olla yhdessä juuri kansiossa.
Minua kovasti houkuttaisi tämä teksti tiedostojen käyttä databasen sijaan, onkos tämä sellainen aloittelijan virhe nytten ?
kpzpt kirjoitti:
Vielä varmuudeksi kysyisin, että josko sittenkin käyttäisin teksti tiedostoja enkä databasea, mitä tuumaatte onko ihan mahdoton ajatus käyttää sittenkin teksti tiedostoja ja niihin pelaaja stringit ja save stringit.
Kysymyshän on lähinnä omasta mukavuudestasi. Eli jos haluat käyttää aikaasi siihen, että teet jotain minkä muut on jo tehneet paremmin ja sitten huonosta toteutuksestasi aiheutuvien ongelmien selittelyyn, niin kaikin mokomin.
kpzpt kirjoitti:
Minulla on käytössä U804 palvelimessa, en oikeastaan tiedä kuinka monta tiedostoa voi tallentaa yhteen kansioon U804 kanssa
En ihan ymmärrä miten tuo sukellusvene (U804) liittyy aiheeseen, mutta kansioon mahtuvien tiedostojen määrä riippuu käytössä olevasta levytilasta ja tiedostojärjestelmästä. Rajoittavin on FAT32, jossa tiedostoja voi olla vain 65535 per hakemisto, mutta kukaan täysijärkinenhän ei moista käytä palvelimella.
Grez kirjoitti:
kpzpt kirjoitti:
Vielä varmuudeksi kysyisin, että josko sittenkin käyttäisin teksti tiedostoja enkä databasea, mitä tuumaatte onko ihan mahdoton ajatus käyttää sittenkin teksti tiedostoja ja niihin pelaaja stringit ja save stringit.
Kysymyshän on lähinnä omasta mukavuudestasi. Eli jos haluat käyttää aikaasi siihen, että teet jotain minkä muut on jo tehneet paremmin ja sitten huonosta toteutuksestasi aiheutuvien ongelmien selittelyyn, niin kaikin mokomin.
kpzpt kirjoitti:
Minulla on käytössä U804 palvelimessa, en oikeastaan tiedä kuinka monta tiedostoa voi tallentaa yhteen kansioon U804 kanssa
En ihan ymmärrä miten tuo sukellusvene (U804) liittyy aiheeseen, mutta kansioon mahtuvien tiedostojen määrä riippuu käytössä olevasta levytilasta ja tiedostojärjestelmästä. Rajoittavin on FAT32, jossa tiedostoja voi olla vain 65535 per hakemisto, mutta kukaan täysijärkinenhän ei moista käytä palvelimella.
Teksti tiedostot palvelimessa !
1) Kuinka tuo plain teksti tiedostojen käyttö mahdollisesti heikentäisi palveluni laatua taikka toimivuutta ? Mitä ongelma tilanteita voi syntyä ?
2) Kuinka tuo ext3 kanssa, sitä olisi tarkoitus käyttää, vai mikä olisi vielä parempi, entä tuollaiset pakkaavat file formaatit, mitä tälläistä olisi tarjolla Ubuntu 8.04 kera ?
kpzpt kirjoitti:
1) Kuinka tuo plain teksti tiedostojen käyttö mahdollisesti heikentäisi palveluni laatua taikka toimivuutta ? Mitä ongelma tilanteita voi syntyä ?
Lähinnä miettisin että paljonko enemmän työtä se koodaajalle aiheuttaa tietokantaan verrattuna. Mutta jos sinulla aikaa piisaa, niin palvelun laatua heikentää mahdolliset tietojen sekoamiset ja katoamiset, kun useampia tietoja päivitetään samaan aikaan. Toki jos riittävästi jaksaa nysvätä näitä, niin lopputuloksena voi lukituksilla sun muilla ainakin vähentää riskejä.
Mutta edelleen kun tietokanta tarjoaa valmiit tietorakenteet, kyselytoiminnallisuudet, lajittelut, turvalliset päivitykset yms. valmiina, niin tuntuu idioottimaiselta lähteä itse niitä tekemään. Vähän kuin ostaisit tietokoneen erillisinä komponentteina (vastuksia, transistoreja, kondensaattoreita, mikropiirejä, yms) ja suunnittelisit ja rakentaisit itse oman tietokoneen verrattuna siihen että ostat tietokoneen kaupasta. Jos tarkoituksena on vaan rakentaa tietokone, niin mikäs siinä, jonkun C64:n tasoisen tietokoneen rakentaminen on nykyään perus amatöörin tehtävissä. Mutta jos olennaisempaa on saada toimiva työkalu, jolla saa varsinaisen homman tehtyä, niin kannatta ennemmin ostaa kaupasta valmiit osat.
kpzpt kirjoitti:
2) Kuinka tuo ext3 kanssa, sitä olisi tarkoitus käyttää
The maximum number of inodes (and hence the maximum number of files and directories) is set when the file system is created. If V is the volume size in bytes, then the default number of inodes is given by V/2^13 (or the number of blocks, whichever is less), and the minimum by V/2^23. The default was deemed sufficient for most applications. The max number of subdirectories in one directory is fixed to 32000.
Tietokanta vaiko teksti tiedosto !
1) Minä mietin että palvelin ohjelma ei voi tallentaa yhden pelaajan tietoja, kuin yhden kerrallaansa, ja aina verifyt ennen seuraavaa kirjoitus lupaa pelaajalle.
2) Jos käytän teksti tiedostoja, niin, lajittelen kaikki pelaaja tiedostot pelaajan nimen 2 tai 3 ensimmäisen kirjaimen mukaan oikeisiin hakemistoihin.
3) Mietin josko asettaisi, yhden kansio puun, jossa olisi pelaajain tiedot, ja lisänä toisen kansio puun, jossa olisi tallenteet.
4) Lisänä mietin josko asennan enintään 10 kirjoitus ja samanverran luku threadeja tiedosto toimintoja varten, näitä kaikkia kontrolloidaan yhdestä pää threadista joka sisältää koodin kirjoitus ja luku lupiin ja siihen mikä threadeista olisi käytettävissä milloinkin, näin päällekkäisyyttä ei olisi.
Mutta en ole ihan varma kuinka Java osaa käsitellä eri Threadeista tapahtuvaa file tallennusta, myöskin kovalevynä on iSCSI joka on hieman erillainen ratkaisuna ?
Kuitenkin minulla olisi helpompi käsitellä näitä tietoja jos ne olisivat teksti muodossa, ja koen että tieto olisi paremmin tallessa ja varmuuskopioitavissakin ( .zip.gz ).
Kun minä mietin tätä teksti tapaa, niin, koen että koodi määrä on aika alhainen ja kait helppokin kirjoittaa ?
----
Jos haluat pitää pelaajatiedot yksinkertaisesti tiedostoissa ja helposti varmuuskopioitavissa, niin yksi vaihtoehto voisi olla käyttää XBase DBF-tiedostoja.
Itse käytän xHarbouria näiden käpistelyyn, mutta nopealla google haulla löytyi useampia toteutuksia Javan kanssa puuhasteluun.
kpzpt kirjoitti:
Kuitenkin minulla olisi helpompi käsitellä näitä tietoja jos ne olisivat teksti muodossa, ja koen että tieto olisi paremmin tallessa ja varmuuskopioitavissakin ( .zip.gz ).
Mielestäni tietokannassa olevaa tietoa on paljon helpompi käpistellä (käytännössä kaikille tietokantamoottoreille löytyy sekä tekstipohjainen että graafinen hallintakäyttöliittymä).
Ja yhtä laillahan sen tietokannan saa helposti varmuuskopioitua. Esim mysql tapauksessa mysqldumpilla vaikka .gz -pakatuksi.
kpzpt kirjoitti:
Kun minä mietin tätä teksti tapaa, niin, koen että koodi määrä on aika alhainen ja kait helppokin kirjoittaa ?
No on se kuitenkin suurempi ja vaikeampi kuin jos käyttäisit tietokantaa.
Mutta en mä oikein enää ymmärrä mitä enää haluat tietää. Olen jo kertonut sinulle pariin kertaan kertonut vastaukset kysymykseesi "tietokanta vai tekstitiedostot" ja sivuutat vaan vastauksen omaan kysymykseesi ja jauhat siitä, miten toteuttaisit sen tekstitiedostoihin tallentamisen.
Voin sanoa että ainakaan minua ei voisi vähempää kiinnostaa miten ne tekstitiedostot tallennat, sillä et voi kehittää niin "hienoa" tapaa, että muuttaisin kantaani. Toisaalta en myöskään ala neuvomaan miten niihin tekstitiedostoihin "kannattaa" tallentaa - jos joku haluaisi ajaa autolla päin puuta en neuvoisi siinäkään.
Tietokanta!
Ok, minä tässä sitten katselen sitten tietokanta opiskeluita, nyt joulupyhä viikonloppuna :)
Voisinko saada jotakin vinkkejä, siihen, mikä tietokanta olisi parhain pelipalvelun asiakastietojen ja yksittäisten pelirupeamien tallennuksiin ?
Myös jos jotakin perustietoa tietokanta ohjelmoinnista, mitä en osaa vielä kysyä, kuten esim. kuinka tiedonhaku tapahtuu tietokannasta, kuinka datasta etsitään tietoa, mitenkä kovalevyä rasittavaa tiedonhaku on ?
kpzpt kirjoitti:
Voisinko saada jotakin vinkkejä, siihen, mikä tietokanta olisi parhain pelipalvelun asiakastietojen ja yksittäisten pelirupeamien tallennuksiin ?
Mikä tahansa tietokanta varmaan toimii hyvin. Itse laittaisin varmaan PostgreSQL:n, MySQL:n tai jos toimitaan Windows ympäristöissä MS SQL Serverin.
MySQL on aika suosittu ja edullisissa weppihotelleissa tarjolla ja sen vuoksi siitä löytyy myös runsaasti oppaita. Se on myös melko kevyt. Se voisi olla ihan OK valinta, vaikkei olekkaan oma suosikkikanta.
kpzpt kirjoitti:
Myös jos jotakin perustietoa tietokanta ohjelmoinnista, mitä en osaa vielä kysyä, kuten esim. kuinka tiedonhaku tapahtuu tietokannasta, kuinka datasta etsitään tietoa
Ehkä kannattaisi lukaista läpi vaikka putkasta löytyvä opas: https://www.ohjelmointiputka.net/oppaat/opas.
Myös Mureakuhan Wikin aiheesta voisi lukaista läpi:
http://wiki.mureakuha.com/wiki/Etusivu#Tietokannat
kpzpt kirjoitti:
mitenkä kovalevyä rasittavaa tiedonhaku on ?
Käytännössä kaikki tietokantamoottorit pyrkivät pitämään useimmin käytetyt tiedot muistissa. Tämä tietenkin lähinnä että haku olisi mahdollisimman nopeaa. Kiintolevyn rasittumisesta sinänsä en olisi huolissani, mutta tokihan tuo siihenkin auttaa.
Aihe on jo aika vanha, joten et voi enää vastata siihen.