Keskustelu: Nettisivujen teko: Java: UDP sotalautapeli palvelu

Hei!

Olen ostanut alkuun vuodeksi Ranskalaisen palvelimen, palvelimeen on asennettuna U804 käyttöjärjestelmäksi, palvelimessa on graafinen etätyöpöytä ja se toimii nyt ihan hyvin käytössäni.

Olen nyt sitten myös asettanut Apache2 ja PHP5 tuen palvelimeeni, lisänä olen asettanut vielä Apache2 moduulin cband, jolla olen jakamassa 2 megabyteä http siirtoihin ja lisänä jätän 5 megabyteä UDP siirtoihin, yhdelle käyttäjälle annan jotain 32 kilobyteä - 64 kilobyteä http kaistaa, UDP kaistaa sitten niin paljon kuin vain tarvitsee ja jää http:stä ylitse.

Nyt olen rakentamassa siis peli palveluani -> http://temp4322.dy.fi

Tuonne on tarkoitus asettaa alkuun seuraavat ->
Shakki,Tammi, Reversi, Mylly, LaivanUpotus, NeljänSuora, RastiNolla ja Yatsy.

Lisänä sitten noitten jälkeen alan julkaisemaan näitä sotalautapelejäni, joita varten olen toiminnan aloittana.

Tämä on minun eka peli palveluni eikä minulla ole mitään ATK alan koulutusta, olen vain lautapeli harrastelija ja haluan tuottamilleni peleille sivuston, olen 40 vuotias.

Mitä tunnettuja hyväksi havaittuja UDP paketti siirto tapoja on Sun Java kera olemassa.

Olen tässä tällä hetkellä rakentamassa ihan "DataGramSocket" palvelinta, ei mitään erikoista, vain lähettelen ja vastaanottelen näitä DataGramSocketin UDP paketteja, joita sitten käsittelen AsiakasOhjelmassani ja palvelimessani, eri peleissä eri tavalla.

Aloitan ensi viikolla palvelin ohjelman koodauksen, mitä olisi hyvä tietää ennakkoon ??

Onko pelkkä DataGramSocket riittävä palvelemaan useita ihmisiä kerrallaansa, ajattelin laittaa palvelimeen ja asiakasohjelmaan 5 porttia joita sitten luen erillisistä Java Threadeista.

Lähinnä tuo DataGramSocketin mahdollinen rajoitteisuus ihmetyttää tilanteessa jossa olisi useita asiakkaita saman aikaisesti lähettämässä pakettia, esim että palvelin olisi juuri lukemassa kun vaikka kaksi seuraavaa pakettia jo saapuu, selviääkö DataGramSocket jatkuvasti tuollaisista tilanteista ja onko tämän kaltaisia "ongelma" kohtia enemmänkin DataGramSocketin kera ??

Edit.
Yritin tuosta Oracle sivuilta katsella Java APIa, kuinka nämä seuraavat käskyt ovatko ne byteä vaiko kiloa ??
Ilmeisesti näitä kahta sitten käytetään hieno säätämään näitä DataGramSockettien paketti ruuhka kohtia ??
setReceiveBufferSize(int size)
setSendBufferSize(int size)

Edit2.
Ovatko kaikki UDP portit yhteen suuntaan vaiko kahteen saman aikaisissa multi Thread lähettelyissä ??

Siinä kysymykseni joilla varmaankin pääsen hyvään alkuun.

//.....

Kiitos..

setReceiveBufferSize(int size)
setSendBufferSize(int size)

Näissä size on tavuissa.

Onko muuten hyvä syy käyttää UDP:tä? Säästäähän sillä kaistaa, mutta TCP voisi olla helpompi käyttää. TCP:llä saa jokaiselle käyttäjälle oman tietovirran, ja se tarkistaa pakettien katoamiset ja virheet paketeissa automaattisesti. TCP:llä ei tarvitsisi ylimääräisiä tarkistuksia, vastaanotetun tiedon pitäisi olla aina samaa kun toinen on lähettänyt.

Jos kuitenkin UDP:llä haluat tehdä, on sinun itse eriteltävä yhteydet jollain ID:llä jonka lähetät pakettien mukana. Lisäksi sinun on otettava huomioon, että kaikki UDP paketeista eivät välttämättä tule perille, vaan katoavat jonnekin reitin varrella. Lisäksi on vielä otettava huomioon, että UDP protokolla ei tee mitän virhetarkistuksia. Data jonka vastaanotat ei välttämättä ole täysin samaa jota on lähetetty.

Itse käyttäisin TCP:tä...

UDP!

Olen päätynyt rakentamaan pelipalveluni mahdollisimman tehokkaaksi.

UDP käyttämällä en joudu tekemään useita Threadeja taikka yhtä jokaiselle asiakkaalle, kuten TCP serverin kanssa ymmärrykseni mukaan on.

Kun käytän UDP paketteja, voin kuunnella näitä paria valikoimaani UDP porttia yhdellä threadilla kutakin, ja sitten yksi pää thread joka käsittelee saapuneitten UDP pakettien pinoa.

Minulla on ainoastaan yksi hyper threadattu 1.6Ghz Atom käytössäni.

Aion laittaa pienen ID:n tapaisen suoja tunnisteen joka vaihtuu satunnaiseksi joka kerta kun paketti lähtee ja palaa ja myöskin lisänä asiakas tunniste, mutta UDP pakettikin sisältää tiedon IP:stä josta se on lähetettynä.

Olet oikeassa tuon UDP paketin suhteen kun kerroit että se ei varmista millään tavalla kun lähtee ja saapuuko koskaan, mutta olen testannut linjoja jotka minulla on ja hukka paketit ovat tähän asti 0% uskon että sama on suurimmalla osalla käyttäjiä, ja nämä jotka käyttävät huonompia linjoja voivat sitten aktivoitua sillä tavalla kun hukka paketteja esiintyy että palvelin varmistaa viestit ja lähettää vaikka tupla määrän kerrallaansa, kenties triplat, myös TCP kanssa esiintyy ylimääräistä siirtelyä jos on huonot linjat jotka hukkaavat paketteja, voikos taasen TCP tarkistuksia ja varmenteita säädellä mitenkäänsä ongelman sattuessa, kun taas UDP tarkistukset tehdään itse, uskoisin myös yhä että kaupunki seuduilla on 0% UDP hukka paketit.

Koen yhä että UDP on parempi minun käyttööni ??

Vielä tuo yksi kysymys onko UDP portti kahteen suuntaan jos siirtoa tapahtuu samanaikaisena ??
Minulla on Send ja Recv tällä hetkellä suunnitteilla samanaikaisena yhteensä 5 portille ??

//.....

Kiitos..

UDP:llä ja TCP:llä ei ole nopeuseroa tuollaisissa vuoropohjaisissa peleissä. Kummallakin yhteystyypillä yksi thread riittää, koska socketit voi käsitellä silmukassa.

TCP!

Heh, uusi tilanne minulle, TCP joka olisi silmukassa, olen käynä hieman lävitse vain näitä Oracle online tutoriaaleja koskein TCP, ja siellä ainakin muistaakseni oli tuossa TCP tavassa, niin, esimerkkinä vain koodi pätkää jossa on ihan omat threadit jokaiselle asiakkaalle serveri ohjelmassa, minä en netti ohjelmointi kokemattomuuttani täysin ymmärrä mitä tarkoitat, tuossa UDP kera minulla olisi vain yksi socket käytössä jokaista porttia, ( 5 minun palvelimessani ), kohden, joutuukos TCP kera laittamaan jokaiselle asiakkaalle oman socketin kuitenkin vaikka välttäisi oman threadin jokaiselle, entä onko näillä asiakas socketeilla sitten taas jokaisella oma send ja recv bufferi, palvelimessani on rajoitetut RAM resurssit ??

Hienoa että kuitenkin ilmoitit tuon TCP piirteen, luulin aiemmin että jokaiselle asiakkaalle täytyy asettaa oma thread ja sehän olisi ollut minun CPU resursseilleni aivan liikaa, voitko sinä tai joku muu hieman tarkentaa tätä tarjottua TCP tapaa, myös jos jollekkin muistuu jokin linkki asiaan, niin sekin olisi mukavaa.

//.....

Kiitos..