Det tror jeg ikke vil være tilstrækkeligt... Jeg mener at en proces kan max have 1024 tråde (i hvert fald på min maskine). Og jeg vil gerne kunne have flere online.
1) En tråd med accept af logins 2) En tråd med behandling af data fra login-sockets 3) En tråd til client-connects 4) En tråd til behandling af authentication fra clients 5) En tråd til behandling af hvad der kommer ud af klienternes sockets 6) En tråd til at sende nye beskeder ud til alle klienter
7) Et main program (på under 20 linier)
Idéen kommer af at jeg vil ikke have at noget, der tager lang tid, blokerer for noget, der tager kort tid. Så jeg vil have det sådan at de requests/events, der behandles inden for hver tråd, tager lige lang tid t behandle (sådan cirka...)
Jeg har fået kodet noget, der virker, men jeg har ingen måde at kunne teste eller forudse hvordan det virker med MANGE logins.
hvis en proces max kan have 1024 tråde, så starter du da bare flere processer op og laver noget ipc mellem dem (er det ikke sådan apache gør, altså starter flere processer op ?)
Når du siger noget ipc så er det vel interproces kommunikation... og den eneste måde, jeg kan se at sådan noget kan laves effektivt, er ved delt hukommelse. Og delt hukommelse er ikke ligefrem nem at arbejde med mht. at lave datastrukturer med dynamisk allokering.
Arghhh... bliver dårlig når jeg skal læse VC kode... Jeg holder mig til UNIX socket programmering (det kan faktisk fås til at virke under winsock med mindre tilrettelser) men tak for linket :)
THE POWER OF UNIX !!! Ja jo.... jeg ville nok lave din server på en UNIX platform og en winsock baseret client...
Sockets skulle jo gerne være standardiseret :-)
Jeg har hørt den dér med at MS påstår at tråde i en proces skulle give ekstra ydelse i håndteringen, men dette kan ikke rigtig ses i praksis når man sammenligner... men igen -er det et spørgsmål om religion.
Dog mener jeg kun at UNIX er en religion -og Win32 mere et hype / forretnings -logik
Vi kan sikkert blive enige om at Windows tit er i erhverslivets øjne en nemmere og billigere løsning...
Det med tråde har jeg læst hos MhygroZopht® at det i bund og grund skulle gøre at de hurtige ikke skulle vente på de langsomme, og det kan da være ret vigtigt ved feks. webservere, der skal sende lange filer til klienter med langsom forbindelse. Men generelt burde en chatline (også en kommando) tage meget kort tid at behandle så der vil jo ikke være hurtigere og langsommere klienter her... Især hvis man sætter en begrænsning på f.eks. 256 tegn pr. linie.
Jeg har implementeret min underlige combo med 7 tråde og en helvedes masse låse *GG* Jeg lavede 25 klienter (browserbaserede DHTML+Java) og satte dem til at sende en pæn lang linie hvert sekund. Kunne desvære ikke lave flere klienter fordi min (Windaz) maskine ikke kan klare mere uden at maskinen bliver sinke... Anyway, belastningen af serveren (RedHat Linux 7.2) var den samme som når den kører idle.
lav en kommandolinie klient, der laver x antal tråde, som indeholder samme logik som browser appletten. Du behøver jo ikke se outputtet (lade bits'ene skylle ud i det virtuelle lokum :-), men bare lade alle tråde spytte "Hello World !!" hen til serveren... ? For at gøre det sjovere, så kan du jo også starte flere jvm's med kommandoline klienten op og så få stresstestet din server.
Uha, havde helt glemt dette her spørgsmål.... anyway, fik lavet en kommandolinie-klient som soreno foreslog og det så ud til at virke tilforladeligt - kunne logge 2000 på som hver skrev noget hver 3-5 sekunder og kunne stadig chatte via min browserbaserede klient med lag < 5 sekunder
Det er nu heller ikke for at bruge den, men for at se hvordan sådan noget laves.. bugs gør ikke noget, det kan jo rettes - det er det sjove :)
Håber du er blød om hjertet idag *G* (eller i morn :P)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.