---

Hej.

Jeg skal lave en server, som kan håndterer flere klienter af gang.
Og, det skal være til et spil, så det er hovedsageligt kommandoer som bliver
sendt frem og tilbage.

Jeg er lidt på bar bund, med hvordan jeg skal strukturerer det.

Nogle der har et bud, eller et eksempel?

--
Jonas

---

Jonas Swiatek <sxt@get2net.dk> skrev i en
nyhedsmeddelelse:9a4ben$1pdi$1@news.cybercity.dk...
> Hej.
>
> Jeg skal lave en server, som kan håndterer flere klienter af gang.
> Og, det skal være til et spil, så det er hovedsageligt kommandoer som
bliver
> sendt frem og tilbage.
>
> Jeg er lidt på bar bund, med hvordan jeg skal strukturerer det.
>
> Nogle der har et bud, eller et eksempel?
>
> --
> Jonas
>
>

Hvis du er på bar bund, bør du nok starte ca. her:
http://java.sun.com/docs/books/tutorial/networking/index.html

Jan Uhre

---

Well.

Jeg kender godt det basale, som Socket, og ServerSocket.

Det er mere selve serveren.
Hvordan bør det se ud. Jeg løber heletiden ind i, at jeg ikke kan "finde
på", hvor jeg kan håndterer alle klienterne, og få en besked fra en klient,
sendt til en anden.
Den slags ting.

--
Jonas

"Jan Uhre" <uhreNOSP@Memail.dk> skrev i en meddelelse
news:9a4fkf$215t$1@news.cybercity.dk...
>
> Jonas Swiatek <sxt@get2net.dk> skrev i en
> nyhedsmeddelelse:9a4ben$1pdi$1@news.cybercity.dk...
> > Hej.
> >
> > Jeg skal lave en server, som kan håndterer flere klienter af gang.
> > Og, det skal være til et spil, så det er hovedsageligt kommandoer som
> bliver
> > sendt frem og tilbage.
> >
> > Jeg er lidt på bar bund, med hvordan jeg skal strukturerer det.
> >
> > Nogle der har et bud, eller et eksempel?
> >
> > --
> > Jonas
> >
> >
>
> Hvis du er på bar bund, bør du nok starte ca. her:
> http://java.sun.com/docs/books/tutorial/networking/index.html
>
> Jan Uhre
>
>

---

Jonas Swiatek <sxt@get2net.dk> skrev i en
nyhedsmeddelelse:9a4gfp$22qj$1@news.cybercity.dk...
> Well.
>
> Jeg kender godt det basale, som Socket, og ServerSocket.
>
> Det er mere selve serveren.
> Hvordan bør det se ud. Jeg løber heletiden ind i, at jeg ikke kan "finde
> på", hvor jeg kan håndterer alle klienterne, og få en besked fra en
klient,
> sendt til en anden.
> Den slags ting.
>

Jeg er bestemt ikke ekspert på det felt. Men den måde jeg hidtil har
implementeret multiple klienters adgang til en server, har været ved at lade
den primære server-proces's eneste opgave være, at lytte efter klienter og
vedligeholde et array/vector med ClientHandler-tråde, hvor alt arbejdet med
at servicere en klient foregår.

Det medfører, at når serveren modtager en client-connection, laver den en ny
tråd med et ClientHandler objekt (eller benytter en eksisterende tråd for at
spare oprettelse af tråde). ClientHandler objektet får som parameter
klientens connection, og alt arbejde herefter foregår *kun* mellem den ene
klient og den pågældende ClientHandler.

Om det er den optimale måde at gøre det på, får vi sikkert snart at vide i
eventuelle svar på mit indlæg (jeg vil meget gerne have input), men det er i
hvert fald en metode, der har gjort arbejdet meget simpelt for mig.

Med venlig hilsen
Jan Uhre

---

> Jeg er bestemt ikke ekspert på det felt. Men den måde jeg hidtil har
> implementeret multiple klienters adgang til en server, har været ved at
lade
> den primære server-proces's eneste opgave være, at lytte efter klienter og
> vedligeholde et array/vector med ClientHandler-tråde, hvor alt arbejdet
med
> at servicere en klient foregår.
>

Det er en rigtig dårlig idé at have en tråd for hver connection. Det bruger
alt for meget maskinkraft. En Windows server er yderligere ikke istand til
at håndtere de mange tråde og hvis du er uheldig vil din serverapplikation
gå ned ved for stor belastning.

-Jacob
www.kiloo.dk

---

Jacob Møller <jacob@jvector.dk> skrev i en
nyhedsmeddelelse:9a5hhj$126b$1@news.cybercity.dk...
>
> > Jeg er bestemt ikke ekspert på det felt. Men den måde jeg hidtil har
> > implementeret multiple klienters adgang til en server, har været ved at
> lade
> > den primære server-proces's eneste opgave være, at lytte efter klienter
og
> > vedligeholde et array/vector med ClientHandler-tråde, hvor alt arbejdet
> med
> > at servicere en klient foregår.
> >
>
> Det er en rigtig dårlig idé at have en tråd for hver connection. Det
bruger
> alt for meget maskinkraft. En Windows server er yderligere ikke istand til
> at håndtere de mange tråde og hvis du er uheldig vil din serverapplikation
> gå ned ved for stor belastning.
>
> -Jacob
> www.kiloo.dk
>
>

Jeg betvivler ikke dit ord, da jeg som sagt ikke er ekspert, men det er da
ret normalt, at håndtere C/S kommunikation ved at lade hver klient blive
håndteret af sin egen tråd på serveren. Er det ikke?

Eller vil man typisk kun have et lille antal "arbejder" tråde, og så må
øvrige connections vente til det bliver deres tur?

Hvor mange tråde må der køre på en server, før det bliver for belastende
(løst spørgsmål, det ved jeg, men et kalkuleret gennemsnit)?

Jeg kan godt se, at med den lille smule information, der udveksles fra en
klient connecter til serveren, leverer sine data og får svar i denne type
applikation - næppe kræver at alle klienter kan få en tråd, når de vil. Men
hvad med større ting... filservere f.eks.? Her kan hver klient jo være
logget på i lang tid, og den kan jo ikke bare slippe forbindelsen før den er
færdig, med mindre det er en server, der husker states på alle connections.

Jan Uhre

---

> Jeg betvivler ikke dit ord, da jeg som sagt ikke er ekspert, men det er da
> ret normalt, at håndtere C/S kommunikation ved at lade hver klient blive
> håndteret af sin egen tråd på serveren. Er det ikke?
>
> Eller vil man typisk kun have et lille antal "arbejder" tråde, og så må
> øvrige connections vente til det bliver deres tur?

> Hvor mange tråde må der køre på en server, før det bliver for belastende
> (løst spørgsmål, det ved jeg, men et kalkuleret gennemsnit)?

Personligt vil jeg til enhver tid foretrække at lave en klient-connection
liste. Teoretisk set er det en rigtig pæn løsning at opsplitte
client-forbindelserne i seperate processor, men i praksis fungerer det ikke.
Windows er istand til at vedligeholde 2000-4000 tråde, hvorefter hele
systemet bliver meget ustabilt. Jeg er ikke klar over hvordan det forholder
sig for de andre operativsystemer - men hvis der er nogen, der har et ledigt
øjeblik kunne det være interssant at se hvor meget de kan håndtere.

> Jeg kan godt se, at med den lille smule information, der udveksles fra en
> klient connecter til serveren, leverer sine data og får svar i denne type
> applikation - næppe kræver at alle klienter kan få en tråd, når de vil.
Men
> hvad med større ting... filservere f.eks.? Her kan hver klient jo være
> logget på i lang tid, og den kan jo ikke bare slippe forbindelsen før den
er
> færdig, med mindre det er en server, der husker states på alle
connections.

Jeg er ikke præcist klar over hvordan filservere fungerer, men eventuelt
kunne man lade hver tråd sørge for x antal connections. På den måde fordeler
man belastningen for den enkelte tråd.

-Jacob
www.kiloo.dk

---

> Jeg er ikke præcist klar over hvordan filservere fungerer, men eventuelt
> kunne man lade hver tråd sørge for x antal connections. På den måde fordeler
> man belastningen for den enkelte tråd.
>
> -Jacob
> www.kiloo.dk

Ja, eller en anden oplagt indfaldsvinkel:

Adskille forbindelser/klienter fra tråde.

Man kunne have en pool af tråde, der er klar til at servicere requests.
Et sådant request kunne så omfatte den aktuelle socket og hvad der
ellers skal bruge.

Hvis serveren selv skal kunne distribuere opdateringer i klient-states,
skal systemet selv så også have mulighed for at gå til en socket.

-dennis

---

Jonas Swiatek <sxt@get2net.dk> skrev i en
nyhedsmeddelelse:9a4gfp$22qj$1@news.cybercity.dk...
> Well.
>
> Jeg kender godt det basale, som Socket, og ServerSocket.
>
> Det er mere selve serveren.
> Hvordan bør det se ud. Jeg løber heletiden ind i, at jeg ikke kan "finde
> på", hvor jeg kan håndterer alle klienterne, og få en besked fra en
klient,
> sendt til en anden.
> Den slags ting.
>

Hmmm... jeg så lige, at du også talte om, at en klient skulle sende beskeder
til en anden klient. I så fald er mit ovenstående svar nok heller ikke
særlig relevant.

Hvis du skal håndtere, at klienter skal kommunikere indbyrdes, er det vel en
mulighed, at hver klient vedligeholder socket connections, som kan add'es
fra serveren til alle nuværende tilmeldte klienter, hver gang en spiller
joiner spillet. I så fald bliver serveren jo egentlig kun brugt mens
spillere joiner, hvorefter al kommunikation er klient-til-klient.

Det vil klart også belaste serveren meget mindre, og sådan er der vist også
adskillige online-spil servere, der opererer (Blizzards battle.net for at
nævne en af de få, jeg kender).

Med venlig hilsen
Jan Uhre

---

Det er noget i den stil jeg er ude efter.

Men, spillet skal ofte snakke med en database. Og det er kun nogle klienter
der skal snakke med nogle andre. ect.
Det skal være sådan her:
Der er flere "områder", eller "stedder" i spillet.

Man skal kun kunne sende kommandoer (hent info, angrib, ect.). Hvis man er i
samme "område", som den man sender en kommando efter.
Der skal ikke være for mange tråde.
Kunne man lave (jeg har aldrig brugt vector før, så jeg er ikke sikker på at
det virker på denne måde):

Vector clients = new Vector();
Og når ServerSocket.accept(); aktiverer, kunne man så:
clients.add(socket);
Så ligger alle connetionsne i en vector.

Så kunne en tråd holde øje med, om de enkelte connections har sendt data, og
så tokenize det, og sende det igennem en Switch-sætning, for at finde ud af
hvad der er sendt.
Og derefter sendte det til den rigtige klient. Eller noget i den stil... Det
er her omkring jeg mister overblikket.

--
Jonas

"Jan Uhre" <uhreNOSP@Memail.dk> skrev i en meddelelse
news:9a4hjl$250l$1@news.cybercity.dk...
>
> Jonas Swiatek <sxt@get2net.dk> skrev i en
> nyhedsmeddelelse:9a4gfp$22qj$1@news.cybercity.dk...
> > Well.
> >
> > Jeg kender godt det basale, som Socket, og ServerSocket.
> >
> > Det er mere selve serveren.
> > Hvordan bør det se ud. Jeg løber heletiden ind i, at jeg ikke kan "finde
> > på", hvor jeg kan håndterer alle klienterne, og få en besked fra en
> klient,
> > sendt til en anden.
> > Den slags ting.
> >
>
> Hmmm... jeg så lige, at du også talte om, at en klient skulle sende
beskeder
> til en anden klient. I så fald er mit ovenstående svar nok heller ikke
> særlig relevant.
>
> Hvis du skal håndtere, at klienter skal kommunikere indbyrdes, er det vel
en
> mulighed, at hver klient vedligeholder socket connections, som kan add'es
> fra serveren til alle nuværende tilmeldte klienter, hver gang en spiller
> joiner spillet. I så fald bliver serveren jo egentlig kun brugt mens
> spillere joiner, hvorefter al kommunikation er klient-til-klient.
>
> Det vil klart også belaste serveren meget mindre, og sådan er der vist
også
> adskillige online-spil servere, der opererer (Blizzards battle.net for at
> nævne en af de få, jeg kender).
>
> Med venlig hilsen
> Jan Uhre
>
>

---

Jonas Swiatek <sxt@get2net.dk> skrev i en
nyhedsmeddelelse:9a4q7b$2o47$1@news.cybercity.dk...
> Det er noget i den stil jeg er ude efter.

Du må stadig huske, at der er i hvert fald 2 metoder, til at håndtere den
slags:
1) Al central status information ligger på serveren, og alle klienterne
kommunikerer kun til serveren, som sørger for distribuering af status til
øvrige klienter.
2) Serveren benyttes til at dele information om forbundne klienter ud,
indtil spillet starter, og al videre kommunikation foregår klienterne
imellem.

Den første lyder (for mig) tung og usikker (ryger serveren, ryger alt). Så
jeg antager den anden løsning i det følgende.

> Men, spillet skal ofte snakke med en database. Og det er kun nogle
klienter
> der skal snakke med nogle andre. ect.
> Det skal være sådan her:
> Der er flere "områder", eller "stedder" i spillet.
>
> Man skal kun kunne sende kommandoer (hent info, angrib, ect.). Hvis man er
i
> samme "område", som den man sender en kommando efter.

Ja, men det er jo underordnet. Her snakker du om kommandoer spillerne
imellem. Alle klienter skal jo konstant opdateres med de andre spilleres
positioner med mere (igen kun ved løsning 2).


> Der skal ikke være for mange tråde.

Der bør vel reelt være mindst tre pr. klient. En til at udføre klientens
eget arbejde, en til at håndtere indkomne requests, og en til at håndtere
udgående requests. Hvis der kun er 1 tråd til at afvente indkomne requests,
betyder det selvfølgelig at klienterne må vente i kø for at aflevere
information til andre, men net-kommunikationen bør jo alligevel holdes på et
absolut minimum, så det burde kunne lade sig gøre.


> Kunne man lave (jeg har aldrig brugt vector før, så jeg er ikke sikker på
at
> det virker på denne måde):
>
> Vector clients = new Vector();
> Og når ServerSocket.accept(); aktiverer, kunne man så:
> clients.add(socket);
> Så ligger alle connetionsne i en vector.

Det var det, jeg tænkte på i hvert fald (det er som sagt ikke nødvendigvis
den bedste løsning). Jeg er ikke ekspert i emnet, men jeg arbejder da på det



> Så kunne en tråd holde øje med, om de enkelte connections har sendt data,
og
> så tokenize det, og sende det igennem en Switch-sætning, for at finde ud
af
> hvad der er sendt.
> Og derefter sendte det til den rigtige klient. Eller noget i den stil...
Det
> er her omkring jeg mister overblikket.

Ja, men her er det så, at jeg mener, at *alle* klienter skal opdateres med
information jævnligt.

Hver klient skal gøre følgende:
- udsende med passende intervaller information om - enten samtlige
positioner og retninger på alt han har (nok en dårlig løsning - meget
kommunikation), eller bare om udstedte ordrer. Intervallerne kan blot være,
hver gang spilleren udsteder en ordre.

- lytte efter indkomne ordrer. Når denne information om hvad en anden
spiller har foretaget sig ankommer, opdaterer klienten sin egen database
over spillet ved beregninger ud fra de modtagne udstedte ordrer fra de
øvrige klienter.

Det er - efter min mening - den mest effektive måde at gøre det på... men
også den besværligste. Den letteste løsning vil nok være, den jeg nævnte i
starten som nr. 1).

Der skal klienterne nemlig kun koncentrere sig om at:
- sende information til serveren om egne bevægelser, og
- hente information om hele spillet fra serveren.

Denne løsning lyder for mig meget lettere at implementere, men vil også
kræve meget mere netværkskommunikation - måske *for* meget??

Med venlig hilsen
Jan Uhre

---

Der er et par teknologier fra IBM alphaworks
(http://www.alphaworks.ibm.com), der måske vil være nyttige. Se specifikt på
Shared Data Objects (meget relevant) og TSpaces (lidt mindre relevant)

Niels Harremoës

---

Jeg er et eller andet sted mest vild med løsning nummer 1.
Den er mere sikker, og det er et vigtigt asbekt i mit sammenhæng. At alt kan
tjekkes serverside(om nødvendigt).
Applikations-serveren vil komme til at køre på en meget stor server.

Min hovedpine med at lade klienter snakke indbyrdes med hinanden, er at
klienten bliver en Applet. Og mig bekendt, må en Applet kun kommunikerer med
den server, som den kommer fra?

Spillet vil indeholde en masse rettigheder. Som ikke må kunne brydes. Og de
SKAL tjekkes serverside. Det dur jo ik at "spillerne", tilslutter til
serveren igennem Telnet og så kan en masse ting, fordi serveren bare lystre
alt hvad man siger til den.

Kunne man lave noget med, at der ligger en ServerSocket, og venter på
klienter i main-metoden.
Når der er en connection sker der:
Vector clients = new Vector();
clients.add(new Client(socket));

Client er et objekt jeg så har lavet, med en thread som håndterer
indkommende events.
Men, hvor meget CPU/RAM tager en Thread?

Client objekter kunne så ha' 2 metoder: getIncomingCommand(); og
setOutgoingCommand();
En thread i main-programmet, kan så konstant tjekke om der er en
IncomingCommand, og sende den vidre til en switch som så tager sig af den,
og laver en outgoingCommand, til de klienter som skal ha' den.

Er dette en løsning, eller er der et eller andet helt vildt smart man kan?

--
Jonas

"Jan Uhre" <uhreNOSP@Memail.dk> skrev i en meddelelse
news:9a4t0d$2sqm$1@news.cybercity.dk...
>
> Jonas Swiatek <sxt@get2net.dk> skrev i en
> nyhedsmeddelelse:9a4q7b$2o47$1@news.cybercity.dk...
> > Det er noget i den stil jeg er ude efter.
>
> Du må stadig huske, at der er i hvert fald 2 metoder, til at håndtere den
> slags:
> 1) Al central status information ligger på serveren, og alle klienterne
> kommunikerer kun til serveren, som sørger for distribuering af status til
> øvrige klienter.
> 2) Serveren benyttes til at dele information om forbundne klienter ud,
> indtil spillet starter, og al videre kommunikation foregår klienterne
> imellem.
>
> Den første lyder (for mig) tung og usikker (ryger serveren, ryger alt). Så
> jeg antager den anden løsning i det følgende.
>
> > Men, spillet skal ofte snakke med en database. Og det er kun nogle
> klienter
> > der skal snakke med nogle andre. ect.
> > Det skal være sådan her:
> > Der er flere "områder", eller "stedder" i spillet.
> >
> > Man skal kun kunne sende kommandoer (hent info, angrib, ect.). Hvis man
er
> i
> > samme "område", som den man sender en kommando efter.
>
> Ja, men det er jo underordnet. Her snakker du om kommandoer spillerne
> imellem. Alle klienter skal jo konstant opdateres med de andre spilleres
> positioner med mere (igen kun ved løsning 2).
>
>
> > Der skal ikke være for mange tråde.
>
> Der bør vel reelt være mindst tre pr. klient. En til at udføre klientens
> eget arbejde, en til at håndtere indkomne requests, og en til at håndtere
> udgående requests. Hvis der kun er 1 tråd til at afvente indkomne
requests,
> betyder det selvfølgelig at klienterne må vente i kø for at aflevere
> information til andre, men net-kommunikationen bør jo alligevel holdes på
et
> absolut minimum, så det burde kunne lade sig gøre.
>
>
> > Kunne man lave (jeg har aldrig brugt vector før, så jeg er ikke sikker
på
> at
> > det virker på denne måde):
> >
> > Vector clients = new Vector();
> > Og når ServerSocket.accept(); aktiverer, kunne man så:
> > clients.add(socket);
> > Så ligger alle connetionsne i en vector.
>
> Det var det, jeg tænkte på i hvert fald (det er som sagt ikke nødvendigvis
> den bedste løsning). Jeg er ikke ekspert i emnet, men jeg arbejder da på
det
>
>
>
> > Så kunne en tråd holde øje med, om de enkelte connections har sendt
data,
> og
> > så tokenize det, og sende det igennem en Switch-sætning, for at finde ud
> af
> > hvad der er sendt.
> > Og derefter sendte det til den rigtige klient. Eller noget i den stil...
> Det
> > er her omkring jeg mister overblikket.
>
> Ja, men her er det så, at jeg mener, at *alle* klienter skal opdateres med
> information jævnligt.
>
> Hver klient skal gøre følgende:
> - udsende med passende intervaller information om - enten samtlige
> positioner og retninger på alt han har (nok en dårlig løsning - meget
> kommunikation), eller bare om udstedte ordrer. Intervallerne kan blot
være,
> hver gang spilleren udsteder en ordre.
>
> - lytte efter indkomne ordrer. Når denne information om hvad en anden
> spiller har foretaget sig ankommer, opdaterer klienten sin egen database
> over spillet ved beregninger ud fra de modtagne udstedte ordrer fra de
> øvrige klienter.
>
> Det er - efter min mening - den mest effektive måde at gøre det på... men
> også den besværligste. Den letteste løsning vil nok være, den jeg nævnte i
> starten som nr. 1).
>
> Der skal klienterne nemlig kun koncentrere sig om at:
> - sende information til serveren om egne bevægelser, og
> - hente information om hele spillet fra serveren.
>
> Denne løsning lyder for mig meget lettere at implementere, men vil også
> kræve meget mere netværkskommunikation - måske *for* meget??
>
> Med venlig hilsen
> Jan Uhre
>
>

---

> Client er et objekt jeg så har lavet, med en thread som håndterer
> indkommende events.
> Men, hvor meget CPU/RAM tager en Thread?

Jeg ville lave det på cirka den måde.

For at sikre dig, at serveren ikke bliver overbelastet kunne du lave en
simpel "maximum connections" begrænsening.

Du kunne også bare serialisere klienterne ud på disk og stoppe tråden,
efterhånden som de bliver gamle. Dette kunne også begrænses, som max 200
tråde i gang og max 10.000 på disk.

Der er mange muligheder.

-dennis

---

Hej,

Nu har jeg set en række indlæg på dit spørgsmål, og vil da også gerne give
en kommentar med på vejen (Når du endeligt er et "rigtigt" spørgsmål).

Jeg har spekuleret lidt i forskellige scenarier, og kan ikke komme med noget
entydigt bud, når jeg ikke kender omfanget af data, der skal kommunikeres og
graden af samtidighed systemet skal understøtte (for en eller flere
brugere).

Du skal nok spekulere på om det skal være connection-oriented (tcp/socket)
eller connection-less (udp/datagram), da det kan give store forskelle mht
til workload.

Du kan evt. også vælge en hybridløsning, hvor man etablere en socket mellem
klient og server, men også signalerer med datagrammer.

Serveren kan holde mange connections i en enkelt connection-pool, hvor store
datamængder transmitteres eller kompleks request-respons kan behandles (som
f.eks. flerfaset commit etc), evt. med et acceptabelt overhead.

Derudover kan klienten sende simple kommandoer via udp, som en server kan
behandle væsentligt hurtigere (ved f.eks. at flytte kommandoen til en
central processing pool). For at sikre pålideligheden i udp kan man evt. ved
hvert request tilføje et sekvens nummer, og så retransmittere kommandoen et
par gange med lidt fall-back. Serveren skal så kun acceptere en ny kommando
fra en klient, hvis den har højere sekvens nummer (og man kan også
gennemskue tabte pakker, som evt kan retransmitteres vhja tcp).

Det giver lidt mere arbejde, men bliver bedre performancemæssigt.

Du skal iøvrigt passe på med at bruge Vector klassen. Det er en af de værste
collections vi har i java. Tag et kig på de nye collection libraries, og
vælg klasser derfra.

Vector og Hashtable lider begge under, at de --altid-- er synkrone udgaver
(og derved optager lang tid ved hver operation). Derudover tilbyder de
elementerne via en Enumeration, som desværre er indeterministisk over for
ændringer i collectionen undervejs (Hvad sker der, hvis man sletter et
element samtidig med at man enumererer, og særligt det man måske har fat i i
øjeblikket.

De nye collections er altid usynkrone, men man kan få synkrone udgaver ved
at bruge metoder fra "java.util.Collections" klassen (ikke at forveksle med
konceptet collection).
Derudover anvender de iteratorer, som tilbyder muligheden for remove()
undervejs, og kaster en ConcurrentModificationException hvis collection
ændres imellemtiden).

Der findes i det nye collections biblioteket to andre klasser, der fungerer
lige som Vector og Hashtable i adfærd, de hedder ArrayList og HashMap.

Håber de giver dig lidt at tænke på.

/Niels Bech Nielsen

"Jonas Swiatek" <sxt@get2net.dk> skrev i en meddelelse
news:9a4ben$1pdi$1@news.cybercity.dk...
> Hej.
>
> Jeg skal lave en server, som kan håndterer flere klienter af gang.
> Og, det skal være til et spil, så det er hovedsageligt kommandoer som
bliver
> sendt frem og tilbage.
>
> Jeg er lidt på bar bund, med hvordan jeg skal strukturerer det.
>
> Nogle der har et bud, eller et eksempel?
>
> --
> Jonas
>
>

---

Niels Bech Nielsen wrote:

> Hej,
>
> Derudover anvender de iteratorer, som tilbyder muligheden for remove()
> undervejs, og kaster en ConcurrentModificationException hvis collection
> ændres imellemtiden).

Er der nogen der ved hvad denne ekstra funktionailtet koster i performance?

-dennis

---

Iteratorerne her er ikke lavet for at øge performance, men for at sikre
deterministisk adfærd.
Collectionerne der anvender dem er i modsætning til tidligere collectioner
boostet med hensyn til performance, så der er en bedre perfomance med disse.

Hvis du gerne vil undgå den, virker Enumeration stadig, lige så vel som du
kan anvende dine egne former for iterationer.

Men nu er performance en svær ting at have med at gøre, fordi den kun er
nødvendig at optimere hvor det giver problemer. Hvis du kigger i java src,
vil du opdage, at iteratoren kontra Enumerationen ikke giver den store
forskel, idet vi kan markere ændringer i collectionen undervejs ved hjælp af
et boolsk flag, og den sammenligning er ikke kostbar.



"Dennis Thrysøe" <qabi@qabi.dk> skrev i en meddelelse
news:3ACB0D4E.7090308@qabi.dk...
>
> Niels Bech Nielsen wrote:
>
> > Hej,
> >
> > Derudover anvender de iteratorer, som tilbyder muligheden for remove()
> > undervejs, og kaster en ConcurrentModificationException hvis collection
> > ændres imellemtiden).
>
> Er der nogen der ved hvad denne ekstra funktionailtet koster i
performance?
>
> -dennis
>

---

Niels Bech Nielsen wrote:

> Iteratorerne her er ikke lavet for at øge performance, men for at sikre
> deterministisk adfærd.
> Collectionerne der anvender dem er i modsætning til tidligere collectioner
> boostet med hensyn til performance, så der er en bedre perfomance med disse.

Jeg er heller ikke så nervøse for det, men bare interesseret i at vide
hvordan tingene står. Mit skrift til de nye Collection skulle I givet
fald være motiveret af bedre performance i et kraftigt multitrådet
miljø. Så er det jo ærgeligt at bruge Iteratorer ofte, hvis de er kostbare.


> Hvis du gerne vil undgå den, virker Enumeration stadig, lige så vel som du
> kan anvende dine egne former for iterationer.

Joe, men det var jo ikke helt idden ;)


> Men nu er performance en svær ting at have med at gøre, fordi den kun er
> nødvendig at optimere hvor det giver problemer. Hvis du kigger i java src,
> vil du opdage, at iteratoren kontra Enumerationen ikke giver den store
> forskel, idet vi kan markere ændringer i collectionen undervejs ved hjælp af
> et boolsk flag, og den sammenligning er ikke kostbar.

Okay - det besvarer sådan set mit spørgsmål. Tak.

-dennis

---

Undskyld det lidt dybe topic efterhånden, men...

De oprindelige 2 (ca.) collections, der fulgte med java (Vector og
Hashtable) er 100% synkrone i alle metoder. Alene denne egenskab skal man
vurdere om er anvendeligt. Jeg har omskrevet meget kode til ikke synkrone
datastrukturer for at øge performace betydeligt. (Monitorlocks _tager_ tid).
Generelt set indeholder J2 følgende standardimplementeringer med følgende
kommentarer (Fra "Java performace tuning - Jack Shirazi", O'Reilly)

Interface Class Synchronized
Set HashSet No Fastest Set, slower than HashMap, but
impl. Set
TreeSet No Slower than HashSet (provides
ordered iteration)
Map HashMap No Fastest Map
Hashtable Yes Slower than HashMap
TreeMap No Slower than Hashtable, (provides
ordered iteration)
List ArrayList No Fastest List
Vector Yes Slower than ArrayList
Stack Yes Same speed as Vector (but uses
LIFO)
LinkedList No Slower than other lists, (depending
on data structure)


Derudover er definitionen af Collections i Set/Map/List interfaces bedre i
forbindelse med optimering af data. Husk på, at optimering først kan ske ved
hjælp af deterministik modellering (dvs. kend dit data grundlag, og analyser
det).

Hvis du vil lave multi-trådet applikationer burde du være glad for
Iteratoren, da den er bevidst om strukturelle ændringer under iteration,
hvilket Enumerationen ikke er. Jeg har fanget rigtigt mange race-conditions
i Enumerationer.

Men generelt betragtet. Den hurtigste collection at anvende er et
java-array. Afhængig af opgaven kan bearbejdning af arrays løfte performance
betydeligt.

Mht. at skrive Enumerationer og Iteratorer selv, kan det faktisk give en
stor fordel, igen afhængig af den enkelte situation.

Så et skift fra Vector/Hashtable til f.eks. ArrayList/HashMap skulle være
bundet i:
Implementering af synkron/asynkron adfærd
Iøvrigt flere metoder til mængdeoperationer (addAll/removeAll/retainAll)
Mulighed for bedre selvdefinering af collectioner, som matcher eksisterende
framework.
Concurrent-safe iteratorer.

Endeligt det største performance problem fra Collectioner er typisk en class
cast. Men den skal kun optimeres, hvor den er en reel tidsrøver.

"Dennis Thrysøe" <qabi@qabi.dk> skrev i en meddelelse
news:3ACC0DAA.3000808@qabi.dk...
>
>
> Niels Bech Nielsen wrote:
>
> > Iteratorerne her er ikke lavet for at øge performance, men for at sikre
> > deterministisk adfærd.
> > Collectionerne der anvender dem er i modsætning til tidligere
collectioner
> > boostet med hensyn til performance, så der er en bedre perfomance med
disse.
>
> Jeg er heller ikke så nervøse for det, men bare interesseret i at vide
> hvordan tingene står. Mit skrift til de nye Collection skulle I givet
> fald være motiveret af bedre performance i et kraftigt multitrådet
> miljø. Så er det jo ærgeligt at bruge Iteratorer ofte, hvis de er
kostbare.
>
>
> > Hvis du gerne vil undgå den, virker Enumeration stadig, lige så vel som
du
> > kan anvende dine egne former for iterationer.
>
> Joe, men det var jo ikke helt idden ;)
>
>
> > Men nu er performance en svær ting at have med at gøre, fordi den kun er
> > nødvendig at optimere hvor det giver problemer. Hvis du kigger i java
src,
> > vil du opdage, at iteratoren kontra Enumerationen ikke giver den store
> > forskel, idet vi kan markere ændringer i collectionen undervejs ved
hjælp af
> > et boolsk flag, og den sammenligning er ikke kostbar.
>
> Okay - det besvarer sådan set mit spørgsmål. Tak.
>
> -dennis
>
>

---

Serveren kommer nok maks op på en 1-300 connections, lige det første stykke
tid.

Og de ting d transmiteres er f.eks: 1,move,3
Eller: 1,talk,2,du stener!
Alt dette bliver slipttet op i en StringTokenizer.

Der skal for 80% af kommandoernes vedkommende, måske tjekkes noget i en
database.

Hvordan virker collections?
Jeg kan hverken finde add, remove eller andre metoder, som minder om
Vectoren?

--
Jonas

"Niels Bech Nielsen" <nbn@logical.nospam.dk> skrev i en meddelelse
news:mjdha9.2df.ln@java.logical.dk...
> Hej,
>
> Nu har jeg set en række indlæg på dit spørgsmål, og vil da også gerne give
> en kommentar med på vejen (Når du endeligt er et "rigtigt" spørgsmål).
>
> Jeg har spekuleret lidt i forskellige scenarier, og kan ikke komme med
noget
> entydigt bud, når jeg ikke kender omfanget af data, der skal kommunikeres
og
> graden af samtidighed systemet skal understøtte (for en eller flere
> brugere).
>
> Du skal nok spekulere på om det skal være connection-oriented (tcp/socket)
> eller connection-less (udp/datagram), da det kan give store forskelle mht
> til workload.
>
> Du kan evt. også vælge en hybridløsning, hvor man etablere en socket
mellem
> klient og server, men også signalerer med datagrammer.
>
> Serveren kan holde mange connections i en enkelt connection-pool, hvor
store
> datamængder transmitteres eller kompleks request-respons kan behandles
(som
> f.eks. flerfaset commit etc), evt. med et acceptabelt overhead.
>
> Derudover kan klienten sende simple kommandoer via udp, som en server kan
> behandle væsentligt hurtigere (ved f.eks. at flytte kommandoen til en
> central processing pool). For at sikre pålideligheden i udp kan man evt.
ved
> hvert request tilføje et sekvens nummer, og så retransmittere kommandoen
et
> par gange med lidt fall-back. Serveren skal så kun acceptere en ny
kommando
> fra en klient, hvis den har højere sekvens nummer (og man kan også
> gennemskue tabte pakker, som evt kan retransmitteres vhja tcp).
>
> Det giver lidt mere arbejde, men bliver bedre performancemæssigt.
>
> Du skal iøvrigt passe på med at bruge Vector klassen. Det er en af de
værste
> collections vi har i java. Tag et kig på de nye collection libraries, og
> vælg klasser derfra.
>
> Vector og Hashtable lider begge under, at de --altid-- er synkrone udgaver
> (og derved optager lang tid ved hver operation). Derudover tilbyder de
> elementerne via en Enumeration, som desværre er indeterministisk over for
> ændringer i collectionen undervejs (Hvad sker der, hvis man sletter et
> element samtidig med at man enumererer, og særligt det man måske har fat i
i
> øjeblikket.
>
> De nye collections er altid usynkrone, men man kan få synkrone udgaver ved
> at bruge metoder fra "java.util.Collections" klassen (ikke at forveksle
med
> konceptet collection).
> Derudover anvender de iteratorer, som tilbyder muligheden for remove()
> undervejs, og kaster en ConcurrentModificationException hvis collection
> ændres imellemtiden).
>
> Der findes i det nye collections biblioteket to andre klasser, der
fungerer
> lige som Vector og Hashtable i adfærd, de hedder ArrayList og HashMap.
>
> Håber de giver dig lidt at tænke på.
>
> /Niels Bech Nielsen
>
> "Jonas Swiatek" <sxt@get2net.dk> skrev i en meddelelse
> news:9a4ben$1pdi$1@news.cybercity.dk...
> > Hej.
> >
> > Jeg skal lave en server, som kan håndterer flere klienter af gang.
> > Og, det skal være til et spil, så det er hovedsageligt kommandoer som
> bliver
> > sendt frem og tilbage.
> >
> > Jeg er lidt på bar bund, med hvordan jeg skal strukturerer det.
> >
> > Nogle der har et bud, eller et eksempel?
> >
> > --
> > Jonas
> >
> >
>
>

---

Jamen, det var dog en overskuelig opgave så. Bare husk at DB roundtrips er
lidt iiriterende, og så meget du kan cache som muligt er en fordel.

Mht. collections.

Collection er et overordnet interface for alle collectioner. Generelt set er
der tre typer:
Set - Hvor elementer er unikke (matematisk mængde)
Map - Hvor et element parres med en nøgle (key-value)
List - Hvor elementer specificeres i en rækkefølge.

Lists og Sets har add metoder, mens Map typisk har put metoder.
Den klasse, der ligner Vector mest (samme type implementering) er ArrayList.
Kig i den, og følg evt. metoderne baglæns via AbstractList til
AbstractCollection. Klassen implementerer både Collection og List interfacet
(plus Cloneable og Serializable).

Klassen Collections (bemærk s'et i enden) er en støtte klase til de
forskellig Collection klasser. Den indeholder lidt søgning og sortering,
samtidig med at den definerer nogle constante typer, som EMPTY_LIST,
EMPTY_SET, og EMPTY_MAP som kan spare en at oprette tomme collectioner.

Jeg kan iøvrigt anbefale, at man lige løber følgende igennem:
http://www.javasoft.com/docs/books/tutorial/collections/index.html

En udemærket lille tutorial om dette.

/Niels

--
/Niels Bech Nielsen -- Logical
SCJ2P - ** Sun Certified Java 2 Programmer **

"Jonas Swiatek" <sxt@get2net.dk> skrev i en meddelelse
news:9aq86o$dtr$1@news.cybercity.dk...
> Serveren kommer nok maks op på en 1-300 connections, lige det første
stykke
> tid.
>
> Og de ting d transmiteres er f.eks: 1,move,3
> Eller: 1,talk,2,du stener!
> Alt dette bliver slipttet op i en StringTokenizer.
>
> Der skal for 80% af kommandoernes vedkommende, måske tjekkes noget i en
> database.
>
> Hvordan virker collections?
> Jeg kan hverken finde add, remove eller andre metoder, som minder om
> Vectoren?
>
> --
> Jonas
>
> "Niels Bech Nielsen" <nbn@logical.nospam.dk> skrev i en meddelelse
> news:mjdha9.2df.ln@java.logical.dk...
> > Hej,
> >
> > Nu har jeg set en række indlæg på dit spørgsmål, og vil da også gerne
give
> > en kommentar med på vejen (Når du endeligt er et "rigtigt" spørgsmål).
> >
> > Jeg har spekuleret lidt i forskellige scenarier, og kan ikke komme med
> noget
> > entydigt bud, når jeg ikke kender omfanget af data, der skal
kommunikeres
> og
> > graden af samtidighed systemet skal understøtte (for en eller flere
> > brugere).
> >
> > Du skal nok spekulere på om det skal være connection-oriented
(tcp/socket)
> > eller connection-less (udp/datagram), da det kan give store forskelle
mht
> > til workload.
> >
> > Du kan evt. også vælge en hybridløsning, hvor man etablere en socket
> mellem
> > klient og server, men også signalerer med datagrammer.
> >
> > Serveren kan holde mange connections i en enkelt connection-pool, hvor
> store
> > datamængder transmitteres eller kompleks request-respons kan behandles
> (som
> > f.eks. flerfaset commit etc), evt. med et acceptabelt overhead.
> >
> > Derudover kan klienten sende simple kommandoer via udp, som en server
kan
> > behandle væsentligt hurtigere (ved f.eks. at flytte kommandoen til en
> > central processing pool). For at sikre pålideligheden i udp kan man evt.
> ved
> > hvert request tilføje et sekvens nummer, og så retransmittere kommandoen
> et
> > par gange med lidt fall-back. Serveren skal så kun acceptere en ny
> kommando
> > fra en klient, hvis den har højere sekvens nummer (og man kan også
> > gennemskue tabte pakker, som evt kan retransmitteres vhja tcp).
> >
> > Det giver lidt mere arbejde, men bliver bedre performancemæssigt.
> >
> > Du skal iøvrigt passe på med at bruge Vector klassen. Det er en af de
> værste
> > collections vi har i java. Tag et kig på de nye collection libraries, og
> > vælg klasser derfra.
> >
> > Vector og Hashtable lider begge under, at de --altid-- er synkrone
udgaver
> > (og derved optager lang tid ved hver operation). Derudover tilbyder de
> > elementerne via en Enumeration, som desværre er indeterministisk over
for
> > ændringer i collectionen undervejs (Hvad sker der, hvis man sletter et
> > element samtidig med at man enumererer, og særligt det man måske har fat
i
> i
> > øjeblikket.
> >
> > De nye collections er altid usynkrone, men man kan få synkrone udgaver
ved
> > at bruge metoder fra "java.util.Collections" klassen (ikke at forveksle
> med
> > konceptet collection).
> > Derudover anvender de iteratorer, som tilbyder muligheden for remove()
> > undervejs, og kaster en ConcurrentModificationException hvis collection
> > ændres imellemtiden).
> >
> > Der findes i det nye collections biblioteket to andre klasser, der
> fungerer
> > lige som Vector og Hashtable i adfærd, de hedder ArrayList og HashMap.
> >
> > Håber de giver dig lidt at tænke på.
> >
> > /Niels Bech Nielsen
> >
> > "Jonas Swiatek" <sxt@get2net.dk> skrev i en meddelelse
> > news:9a4ben$1pdi$1@news.cybercity.dk...
> > > Hej.
> > >
> > > Jeg skal lave en server, som kan håndterer flere klienter af gang.
> > > Og, det skal være til et spil, så det er hovedsageligt kommandoer som
> > bliver
> > > sendt frem og tilbage.
> > >
> > > Jeg er lidt på bar bund, med hvordan jeg skal strukturerer det.
> > >
> > > Nogle der har et bud, eller et eksempel?
> > >
> > > --
> > > Jonas
> > >
> > >
> >
> >
>
>

---

Thanx dude ;)

Kan man ikke lave et eller andet smart med en databaseforbindelse, så der er
én connection. Og denne connection er global. ALLE objekter, uanset
placering i programmet, kan bruge dette objekt?

Eller skal bare lave en connection, og så inkluderer den i alle nye
objekters contructor?

--
Jonas

"Niels Bech Nielsen" <nbn@logical.nospam.dk> skrev i en meddelelse
news:0ckra9.48q.ln@java.logical.dk...
> Jamen, det var dog en overskuelig opgave så. Bare husk at DB roundtrips er
> lidt iiriterende, og så meget du kan cache som muligt er en fordel.
>
> Mht. collections.
>
> Collection er et overordnet interface for alle collectioner. Generelt set
er
> der tre typer:
> Set - Hvor elementer er unikke (matematisk mængde)
> Map - Hvor et element parres med en nøgle (key-value)
> List - Hvor elementer specificeres i en rækkefølge.
>
> Lists og Sets har add metoder, mens Map typisk har put metoder.
> Den klasse, der ligner Vector mest (samme type implementering) er
ArrayList.
> Kig i den, og følg evt. metoderne baglæns via AbstractList til
> AbstractCollection. Klassen implementerer både Collection og List
interfacet
> (plus Cloneable og Serializable).
>
> Klassen Collections (bemærk s'et i enden) er en støtte klase til de
> forskellig Collection klasser. Den indeholder lidt søgning og sortering,
> samtidig med at den definerer nogle constante typer, som EMPTY_LIST,
> EMPTY_SET, og EMPTY_MAP som kan spare en at oprette tomme collectioner.
>
> Jeg kan iøvrigt anbefale, at man lige løber følgende igennem:
> http://www.javasoft.com/docs/books/tutorial/collections/index.html
>
> En udemærket lille tutorial om dette.
>
> /Niels
>
> --
> /Niels Bech Nielsen -- Logical
> SCJ2P - ** Sun Certified Java 2 Programmer **
>
> "Jonas Swiatek" <sxt@get2net.dk> skrev i en meddelelse
> news:9aq86o$dtr$1@news.cybercity.dk...
> > Serveren kommer nok maks op på en 1-300 connections, lige det første
> stykke
> > tid.
> >
> > Og de ting d transmiteres er f.eks: 1,move,3
> > Eller: 1,talk,2,du stener!
> > Alt dette bliver slipttet op i en StringTokenizer.
> >
> > Der skal for 80% af kommandoernes vedkommende, måske tjekkes noget i en
> > database.
> >
> > Hvordan virker collections?
> > Jeg kan hverken finde add, remove eller andre metoder, som minder om
> > Vectoren?
> >
> > --
> > Jonas
> >
> > "Niels Bech Nielsen" <nbn@logical.nospam.dk> skrev i en meddelelse
> > news:mjdha9.2df.ln@java.logical.dk...
> > > Hej,
> > >
> > > Nu har jeg set en række indlæg på dit spørgsmål, og vil da også gerne
> give
> > > en kommentar med på vejen (Når du endeligt er et "rigtigt" spørgsmål).
> > >
> > > Jeg har spekuleret lidt i forskellige scenarier, og kan ikke komme med
> > noget
> > > entydigt bud, når jeg ikke kender omfanget af data, der skal
> kommunikeres
> > og
> > > graden af samtidighed systemet skal understøtte (for en eller flere
> > > brugere).
> > >
> > > Du skal nok spekulere på om det skal være connection-oriented
> (tcp/socket)
> > > eller connection-less (udp/datagram), da det kan give store forskelle
> mht
> > > til workload.
> > >
> > > Du kan evt. også vælge en hybridløsning, hvor man etablere en socket
> > mellem
> > > klient og server, men også signalerer med datagrammer.
> > >
> > > Serveren kan holde mange connections i en enkelt connection-pool, hvor
> > store
> > > datamængder transmitteres eller kompleks request-respons kan behandles
> > (som
> > > f.eks. flerfaset commit etc), evt. med et acceptabelt overhead.
> > >
> > > Derudover kan klienten sende simple kommandoer via udp, som en server
> kan
> > > behandle væsentligt hurtigere (ved f.eks. at flytte kommandoen til en
> > > central processing pool). For at sikre pålideligheden i udp kan man
evt.
> > ved
> > > hvert request tilføje et sekvens nummer, og så retransmittere
kommandoen
> > et
> > > par gange med lidt fall-back. Serveren skal så kun acceptere en ny
> > kommando
> > > fra en klient, hvis den har højere sekvens nummer (og man kan også
> > > gennemskue tabte pakker, som evt kan retransmitteres vhja tcp).
> > >
> > > Det giver lidt mere arbejde, men bliver bedre performancemæssigt.
> > >
> > > Du skal iøvrigt passe på med at bruge Vector klassen. Det er en af de
> > værste
> > > collections vi har i java. Tag et kig på de nye collection libraries,
og
> > > vælg klasser derfra.
> > >
> > > Vector og Hashtable lider begge under, at de --altid-- er synkrone
> udgaver
> > > (og derved optager lang tid ved hver operation). Derudover tilbyder de
> > > elementerne via en Enumeration, som desværre er indeterministisk over
> for
> > > ændringer i collectionen undervejs (Hvad sker der, hvis man sletter et
> > > element samtidig med at man enumererer, og særligt det man måske har
fat
> i
> > i
> > > øjeblikket.
> > >
> > > De nye collections er altid usynkrone, men man kan få synkrone udgaver
> ved
> > > at bruge metoder fra "java.util.Collections" klassen (ikke at
forveksle
> > med
> > > konceptet collection).
> > > Derudover anvender de iteratorer, som tilbyder muligheden for remove()
> > > undervejs, og kaster en ConcurrentModificationException hvis
collection
> > > ændres imellemtiden).
> > >
> > > Der findes i det nye collections biblioteket to andre klasser, der
> > fungerer
> > > lige som Vector og Hashtable i adfærd, de hedder ArrayList og HashMap.
> > >
> > > Håber de giver dig lidt at tænke på.
> > >
> > > /Niels Bech Nielsen
> > >
> > > "Jonas Swiatek" <sxt@get2net.dk> skrev i en meddelelse
> > > news:9a4ben$1pdi$1@news.cybercity.dk...
> > > > Hej.
> > > >
> > > > Jeg skal lave en server, som kan håndterer flere klienter af gang.
> > > > Og, det skal være til et spil, så det er hovedsageligt kommandoer
som
> > > bliver
> > > > sendt frem og tilbage.
> > > >
> > > > Jeg er lidt på bar bund, med hvordan jeg skal strukturerer det.
> > > >
> > > > Nogle der har et bud, eller et eksempel?
> > > >
> > > > --
> > > > Jonas
> > > >
> > > >
> > >
> > >
> >
> >
>
>

---

> Kan man ikke lave et eller andet smart med en databaseforbindelse, så der
er
> én connection. Og denne connection er global. ALLE objekter, uanset
> placering i programmet, kan bruge dette objekt?
>
> Eller skal bare lave en connection, og så inkluderer den i alle nye
> objekters contructor?

Trods den uskønne opbygning kunne man vel i princippet gøre følgende:

static public StandardConnection
{
static ConnectionHolder ch=new ConnectionHolder();
StandardConnection()
{
try{
ch.socket = new Socket("url",23);
ch.dis = new DataInputStream(ch.socket.getInputStream());
ch.dos = new DataOutputStream(ch.socket.getOutputStream());
}catch(Exception e){}
}

static public Socket getSocket()
{
return ch.socket;
}

static public DataInputStream getInputStream()
{
return ch.dis;
}

static public DataOutputStream getOutputStream()
{
return ch.dos;
}
}

public void ConnectionHolder
{
Socket socket=null;
DataInputStream dis=null;
DataOutputStream dos=null;
}

Sådan noget lignende det her burde vel virke, eller det er ihvertfald
muligt, har ikke testet koden. Men jeg vil sige at det nok ikke er en god
ide at lave sådan nogle krumspring her, med ting der er så vitale som
connections.

Med klasserne kan du lave en StandardConnection.getSocket(); uanset hvor du
er for at få Socket referencen. Og det samme med Input/Output streams.

Mvh
Kristoffer Sørensen
www.kiloo.dk

---

Jeg tror han skulle bruge en DB-connection istedet for en socket-connection,
men princippet er vel det samme

Et design-pattern, som hedder Singleton viser hvorledes man i en applikation
deler præcis en instans, som følger:

/** Only one instance ever of this class available. */
public final class Singleton {
private static Singleton self = new Singleton();

private Singleton() { ... }

public static Singleton getInstance() {
return self;
}
}

Nu kan man kun få en reference gennem den statiske metode
Singleton.getInstance() fordi klassen er final, og konstruktøren lukket. For
real world eksempel så gælder: java.lang.Runtime.getRuntime(), som et
eksempel på en Singleton-klasse.

Husk dog på, at hvis du kun har en connection, vil den automatisk blive en
flaskehals, så connection-pooling kan være en fordel.

--
/Niels Bech Nielsen -- Logical
SCJ2P - ** Sun Certified Java 2 Programmer **

"Kristoffer Sørensen" <kristoffer@kiloo.dk> skrev i en meddelelse
news:9as0ar$foo$1@news.inet.tele.dk...
> > Kan man ikke lave et eller andet smart med en databaseforbindelse, så
der
> er
> > én connection. Og denne connection er global. ALLE objekter, uanset
> > placering i programmet, kan bruge dette objekt?
> >
> > Eller skal bare lave en connection, og så inkluderer den i alle nye
> > objekters contructor?
>
> Trods den uskønne opbygning kunne man vel i princippet gøre følgende:
>
> static public StandardConnection
> {
> static ConnectionHolder ch=new ConnectionHolder();
> StandardConnection()
> {
> try{
> ch.socket = new Socket("url",23);
> ch.dis = new DataInputStream(ch.socket.getInputStream());
> ch.dos = new DataOutputStream(ch.socket.getOutputStream());
> }catch(Exception e){}
> }
>
> static public Socket getSocket()
> {
> return ch.socket;
> }
>
> static public DataInputStream getInputStream()
> {
> return ch.dis;
> }
>
> static public DataOutputStream getOutputStream()
> {
> return ch.dos;
> }
> }
>
> public void ConnectionHolder
> {
> Socket socket=null;
> DataInputStream dis=null;
> DataOutputStream dos=null;
> }
>
> Sådan noget lignende det her burde vel virke, eller det er ihvertfald
> muligt, har ikke testet koden. Men jeg vil sige at det nok ikke er en god
> ide at lave sådan nogle krumspring her, med ting der er så vitale som
> connections.
>
> Med klasserne kan du lave en StandardConnection.getSocket(); uanset hvor
du
> er for at få Socket referencen. Og det samme med Input/Output streams.
>
> Mvh
> Kristoffer Sørensen
> www.kiloo.dk
>
>

---

Generelt er det en dårlig ide uanset hvad. Det er ikke rart kode, imho. at
have for mange static klasser og slet ikke når det kommer til server/socket
connections.

Mvh
Kristoffer Sørensen
www.kiloo.dk




"Niels Bech Nielsen" <nbn@logical.nospam.dk> wrote in message
news:56bsa9.17e.ln@java.logical.dk...
> Jeg tror han skulle bruge en DB-connection istedet for en
socket-connection,
> men princippet er vel det samme
>
> Et design-pattern, som hedder Singleton viser hvorledes man i en
applikation
> deler præcis en instans, som følger:
>
> /** Only one instance ever of this class available. */
> public final class Singleton {
> private static Singleton self = new Singleton();
>
> private Singleton() { ... }
>
> public static Singleton getInstance() {
> return self;
> }
> }
>
> Nu kan man kun få en reference gennem den statiske metode
> Singleton.getInstance() fordi klassen er final, og konstruktøren lukket.
For
> real world eksempel så gælder: java.lang.Runtime.getRuntime(), som et
> eksempel på en Singleton-klasse.
>
> Husk dog på, at hvis du kun har en connection, vil den automatisk blive en
> flaskehals, så connection-pooling kan være en fordel.
>
> --
> /Niels Bech Nielsen -- Logical
> SCJ2P - ** Sun Certified Java 2 Programmer **
>
> "Kristoffer Sørensen" <kristoffer@kiloo.dk> skrev i en meddelelse
> news:9as0ar$foo$1@news.inet.tele.dk...
> > > Kan man ikke lave et eller andet smart med en databaseforbindelse, så
> der
> > er
> > > én connection. Og denne connection er global. ALLE objekter, uanset
> > > placering i programmet, kan bruge dette objekt?
> > >
> > > Eller skal bare lave en connection, og så inkluderer den i alle nye
> > > objekters contructor?
> >
> > Trods den uskønne opbygning kunne man vel i princippet gøre følgende:
> >
> > static public StandardConnection
> > {
> > static ConnectionHolder ch=new ConnectionHolder();
> > StandardConnection()
> > {
> > try{
> > ch.socket = new Socket("url",23);
> > ch.dis = new DataInputStream(ch.socket.getInputStream());
> > ch.dos = new DataOutputStream(ch.socket.getOutputStream());
> > }catch(Exception e){}
> > }
> >
> > static public Socket getSocket()
> > {
> > return ch.socket;
> > }
> >
> > static public DataInputStream getInputStream()
> > {
> > return ch.dis;
> > }
> >
> > static public DataOutputStream getOutputStream()
> > {
> > return ch.dos;
> > }
> > }
> >
> > public void ConnectionHolder
> > {
> > Socket socket=null;
> > DataInputStream dis=null;
> > DataOutputStream dos=null;
> > }
> >
> > Sådan noget lignende det her burde vel virke, eller det er ihvertfald
> > muligt, har ikke testet koden. Men jeg vil sige at det nok ikke er en
god
> > ide at lave sådan nogle krumspring her, med ting der er så vitale som
> > connections.
> >
> > Med klasserne kan du lave en StandardConnection.getSocket(); uanset hvor
> du
> > er for at få Socket referencen. Og det samme med Input/Output streams.
> >
> > Mvh
> > Kristoffer Sørensen
> > www.kiloo.dk
> >
> >
>
>

---

"Jonas Swiatek" <sxt@get2net.dk> skrev i en meddelelse
news:3ad17f16$0$5727$4d4eb98e@news.dk.uu.net...
> Kan man ikke lave et eller andet smart med en databaseforbindelse, så der
er
> én connection. Og denne connection er global. ALLE objekter, uanset
> placering i programmet, kan bruge dette objekt?
[...]
Før du begynder at rode med at lave din egen database connection pooling, så
brug 5 minutter på at se, hvad du kan finde på fx. jars eller sourceforge -
se fx.
se lige på koden fra sourceforge - fx. Protomatter
(http://sourceforge.net/projects/protomatter/)
eller PoolMan.

MvH Niels Harremoës

---

Hej,

jeg fandt dette på nettet:

http://www.daimi.au.dk/~chvid/SJGame/

Det er et komplet framework til det du søger...

mvh. Esben

P.S: linket var nede da jeg lige prøvede, men det virkede da sidste uge,
så måske er det snart oppe igen....

Jonas Swiatek wrote:

> Hej.
>
> Jeg skal lave en server, som kan håndterer flere klienter af gang.
> Og, det skal være til et spil, så det er hovedsageligt kommandoer som bliver
> sendt frem og tilbage.
>
> Jeg er lidt på bar bund, med hvordan jeg skal strukturerer det.
>
> Nogle der har et bud, eller et eksempel?
>
> --
> Jonas