client/server

Platform? Teknologi?
- Flere detaljer tak!

client/server på en unix(linux) server, med 10 teminaler

Serveren lytter vel på en TCP/IP port og processer de requests
der kommer ind, når de komemr ind.

Serveren kan ikke starte klienten (nærmest per definition).
Klienten skal startes af en bruger eller andet.

Et meget upræcist svar, men det er svært at være præcis
med de meget få oplysninger vi har.

hmmm.... serveren kan ikke lytte på to ting "samtidigt", hvad med at forke server, hver gang en klient logger på. Så skal I bare styre de forskellige serverprocessers funktioner med semaforer, hvis de altså skal ændre i det samme... piece of cake! hvis nu kickstarter klienter med én nøgle (key) til mailbox, serveren som står og lytter til den, kan så opsnappe msg, sende en ny (privat mailbox) nøgle afsted tilbage til klient (evt dens eget pid eller noget i den retning) samtidig med at den forker og creater den nye mailbox. Hvis i bruger pid som key, så husk at det skal være parent der tager kontakt til klienten, ellers snakker alle over mailbox 0 :p

fork() er en fin metode under unix.. jeg ville nok foretrække at holde det simpel og skrive en server der bruger blocking sockets og select() til checke dem.. Så kører serveren som en enkelt proces.. er der virkelig ingen herinde der kender et grundlæggende kald som select()? *g*

kender det, gider dog ikke bruge det :p

slashdotdoek: metoden har dog sine klare fordele. Du skal tænke på at hvis du har 30 samtidige klienter og forker(), har du 30 kørende processor.. det skaber en del overhead i OS'et.. hvis det skal være ih så fancy vil jeg hellere foreslå en asynkron server implementeret med POSIX threads.. Hver thread skal dog varetage mere end en forbindelse.. det er, specielt på win32 platformen, en udbredt misforståelse at en god server er en der spawner en thread for hver client.. I et system med en enkelt processor er 3-4 threads det optimale.. flere tager performance pga grund af timeslicing og alt det management det kræver i kernen. Desuden er et single thread program lige så effektivt i det man selv implementere sin multitasking uden det overhead OS'et bruger.. os er dømt til at gøre jobbet dårligere på grund af at det skal tage højde for memory protection, file locks og alt mulig andet skidt som er underforstået i din kode.. så med mindre der er tale om et flerprocessor system kan jeg ikke se at man har det store at vinde ved at smide om sig med threads og processor.. specielt på win32 threads et helvede på grund af race conditions og mutexes.. men det står selvfølgelig enhver frit for at bruge deres foretrukne metode.. og ja.. det er mere avanceret at kode et singlethreaded program der skal håndterer f.eks. 300 samtidige klienter.. man skal selv synkronisere hele skidtet istedet for bare at lade OS'et gøre det med forks eller threads :-)