[C++] Server met Clients efficient?

[Verwijderd]

Ik ben bezig om een server te bouwen met behulp van winsock 1.
Het idee is om ongeveer tot 500 clients er op te laten in loggen (jaja grootste plannen, waarschijnelijk worden het 2 clients te gelijk) en om elke client een eigen thread te geven met daar in een socket die recv() van de client op een poort voor alle clients.
Ik weet alleen niet zeker dat of dit wel de efficientste manier is om dit aan te pakken.

Ik heb even twee afbeeldingen gemaakt waarin ik ongeveer beschrijf wat ik doe:
Als eerste een soort van code structuur diagram:
(er is dus een array met threads)

Dit diagram beschrijft ongeveer welke threads er zijn..


Ik heb de code geupload hier

Er is dus 1 poort, 1 main thread en n threads voor de clients die dan tegelijkertijd recv en stopt als er wordt gesend, is dit dus een goede aanpak?

[Verwijderd]

Ja, zit goed in elkaar. Alleen zou ik het listen process niet in de main thread doen als je ook een layout (winform) om je server heen hebt.

Maar verder, elke client krijgt ze eigen thread dus dat zit goed. Als er geen server <-> client actifiteit is doet je thread ook niets. Dus als er 500 clients zijn geconnect is het niet zo dat er 500 threads lopen te runnen maar ik ga er vanuit dat de meeste wel slapen

Ik ga er van uit dat je ook dingen als 'keep alive' enzo in de thread van de client gaat doen. Maar dat kan natuurlijk niet veel kwaat!

Maar nogmaals een goede opzet alleen de 'accept' loop zou ik nog in een appart thread'je gooien met een mindere priority. Omdat mijn mening is dat connected client meer recht hebben... als je eenmaal geconnect bent wil je dat blijven.
Als je gaat connecten en in het schrijnende geval dat het is een keer mislukt, probeer je het nog is en gaat het goed, maar daar zullen de meningen wel over verschillen

[Verwijderd]

Het punt van de accept loop in een aparte thread zetten is wel ok (ik werk btw in een console applicatie).

Ik vroeg me alleen af hoe je het beste kunt kijken of er activiteit op die socket zit, moet je dat doen met behulp van events (WSAEventSelect, Select of WSAAsyncSelect)?

Ik heb ook een lijst met soorten server opbouw gezien, alleen ik kon niet echt vinden welke ik nou eigenlijk gebruik?

Blocking sockets
Polling
Select
WSAAsyncSelect non-blocking
WSAEventSelect non-blocking
Overlapped I/O: blocking
Overlapped I/O: polling
Overlapped I/O: completion routines
Overlapped I/O: completion ports

ik zelf dacht dat het deze is: WSAEventSelect non-blocking. (die overlapped I/O zijn vooral voor overdreven veel connecties handig (1000+)

[Verwijderd]

Verwijderd schreef op 19 november 2003 @ 10:53:
ik zelf dacht dat het deze is: WSAEventSelect non-blocking. (die overlapped I/O zijn vooral voor overdreven veel connecties handig (1000+)

Zit wat in... maar ik vind het zelf altijd handig om gewoon gebruik te maken van een loopie die eigelijks gewoon hetvolgende doet:

server:

code:

<server> Client, ben je daar nog?
<client> Jawel... jij ook nog dus!
<server> Ja ik ook nog!

client:

code:

// als er langer dan een bepaalde tijd niets is ontvangen
<client> Server... ben jij daar eigelijks nog wel?
<server> owja, sorry ik was je vergeten!
<client> Owkee! Dan blijf ik nog even hangen.

Dit is een makelijke maar zeer efficiente metode!

[Verwijderd]

haha, droog .

Dus voor dat loopje kan ik het beste ook een thread aanvragen lijkt mij (aan de server kant)?

Even een lijstje van threads bijhouden
• Main thread
• Accept thread
• Check for connection thread
• Client threads [1...n]

[Verwijderd]

Verwijderd schreef op 19 november 2003 @ 11:06:
haha, droog .

Dus voor dat loopje kan ik het beste ook een thread aanvragen lijkt mij (aan de server kant)?

Even een lijstje van threads bijhouden
• Main thread
• Accept thread
• Check for connection thread
• Client threads [1...n]

Ja dat kan makkelijk! In je Ik-Houd-Je-Levend-Thread laat je het Theadje toch gewoon even slapen. Je hoeft dat bijvoorbeeld maar elke 10sec te controleren...

En zo heb je een leuk opzetje dacht ik zo! Waarom trouwens een console app, en niet een Services als je toch niet echt een layoutje nodig denkt te hebben. Of zit Cristal er nu gewoon weer echt helemaal naast

Btw. vergeen niet je Array te locken als je er een client uitgaat halen bij disconnect

[Verwijderd]

offtopic:
He dat is een best goed plan van die Service, alleen hoe bouw je zo iets.
Want hij gaat inderdaad op de background draaien, en wordt dan aangesproken vanuit een remote location (mbv zijn sockets natuurlijk).
Zit er verschil in met bouwen als je er een service van wilt maken? Of bedoel je dat je het gewoon kan instellen als draaiend op de achtergrond?

[Verwijderd]

Verwijderd schreef op 19 november 2003 @ 11:20:

offtopic:
He dat is een best goed plan van die Service, alleen hoe bouw je zo iets.
Want hij gaat inderdaad op de background draaien, en wordt dan aangesproken vanuit een remote location (mbv zijn sockets natuurlijk).
Zit er verschil in met bouwen als je er een service van wilt maken? Of bedoel je dat je het gewoon kan instellen als draaiend op de achtergrond?

Tja, het is eigelijks gewoon hetzelfde als een console app. Alleen je kan geen Console.Write gebruiken

Je hebt eigelijks gewoon een Main method die ge'call'ed word als de service word gestart.
Je hebt dan nog de events die je in je services code moet handelen, uit me hoofd: ServiceStart, ServicePause, ServiceStop... iig iets in die trant.

Op MSND is er hele voorbeeld code en wordt het uitgebreid besproken. Maar als je het niet kunt vinden kun je hier ook nog even schreewen!


Owja en nog iets... ik lees zo nog even boven in je start-post dat je gebruikt maakt van WinSock, dat is iets wat mij nog niet echt was opgevallen... maar waarom WinSock? Ik heb zelf nooit echt met WinSock gewerkt.. altijd gewoon met Sockets (ik denk dat het aardig op hetzelfde neerkomt) maar WinSock werd mij altijd afgeraden
Maar ik weet niet of je C++.NET gebruikt of nog gewoon de vertrouwde? Want, in C++.NET kun je uit de voeten met System.Net.Sockets

Maar het kan nu ook zo zijn dat ik allemaal slaapende honden heb wakker gemaakt, mocht dit het geval zijn dan heb ik niets gezecht

[Verwijderd]

Ik werk met visual C++ 6.0.
Waarschijnelijk zal ik uiteindelijk geen cout richting het scherm doen. (misschien wel richting een log file, maar dat is geen probleem.

[Verwijderd]

Verwijderd schreef op 19 november 2003 @ 11:34:
Ik werk met visual C++ 6.0.
Waarschijnelijk zal ik uiteindelijk geen cout richting het scherm doen. (misschien wel richting een log file, maar dat is geen probleem.

Nee, iets loggen naar een file kan cker nog! Ik zat even te google'en voor je en vond even zo snel deze: http://www.codeproject.com/useritems/ManC_WinService.asp

Die leek op het eerste gezicht nog wel intressant, dus succes er mee!

[Verwijderd]

offtopic:
ok tnx, ik heb hier in de msdn ook veel gevonden over win32 services examples, dus ik kan zeker een heel stuk vooruit

[Verwijderd]

Als je interesse hebt en geen zin hebt om een socket frameworkje te bouwen heb ik nog wel een bijna-af frameworkje liggen wat je kan downloaden:

- Event sockets (WSAEventSelect)
- Service
- 1 thread per client, met thread pool

Ik gebruik dit al jaren voor diverse services en dus ook voor diverse netwerk services... Als je het hebben wil, mail/msn me dan even.


PS: Houd er rekening mee dat een thread minimaal 1mb kost in de VM adres ruimte van je proces. Afhankelijk van de windows versie die je gebruikt en de mate van fragmentatie van je adresruimte kan het zijn dat het maken van threads 'opeens' zonder duidelijke reden gaat mislukken. Als je service echt heavy-duty moet worden wil je een enkele thread meerdere verbindingen laten afhandelen en gaan werken met iets geavanceerds als completion ports enzo. Een tijd geleden heb ik een logger service geschreven (een soort syslog, maar dan ook met NT performance counters enzo) en daar ging ik in eerste instantie ook uit van een thread per client. Aangezien 't hier om alleen maar korte messages ging was dat traag en systeembelastend, dus dat heb ik omgeklust naar een enkele thread die met overlapped I/O naar een set named pipes luistert. Dat is echt bloedsnel...

[ Voor 54% gewijzigd door Verwijderd op 19-11-2003 12:50 ]

[Olaf van der Spek]

Waarom WinSock 1 en niet 2?
Wat voor server gaat het precies worden?
Een single-threaded server is niet alleen sneller, maar is waarschijlijk ook makkelijker te schrijven, omdat je niet aan locking hoeft te denken.
Heb je genoeg aan een thread per client? Je zit namelijk met recv en send, die beide onafhankelijk kunnen blocken.

Op http://62.216.18.38/XBT_Tracker.tgz heb ik nog een single-threaded server staan (select model).

[ Voor 18% gewijzigd door Olaf van der Spek op 19-11-2003 13:13 ]

[MSalters]

Een thread per connectie is vaak te veel, een thread voor alle connecties samen vaak te weinig, dus je eindigt in zo'n achitectuur met een tussenvorm, als je de hoogste performance wil. Met completion ports / overlapped IO heb je inderaad een andere architectuur, die ecfficienter kan zijn.

I/O redirection is vrij makkelijk met iostream, alle streams hebben een rdbuf. Met std::cout.rdbuf kun je zelfs cout redirecten. Op die manier kun je ook vanuit een service cout gebruiken; je opent zelf gewoon het console via de Win32 API en je zet er je eigen ostreambuf op.

[Verwijderd]

@Qlone: Ik heb je even gemaild
Ik hoop dat ik er veel van kan leren.
@OlafvdSpek: mmm opzich moet het wel kunnen, maar omdat alle tutorials die ik tegen kwam over winsock 1 gingen...
@MSalters: ow das dus weer een heel andere aan pak. Ik zal er een naar kijken, want ik ben nog geen voorbeelden tegen gekomen van overlapped servers.

[ Voor 66% gewijzigd door Verwijderd op 19-11-2003 13:20 ]

[madwizard]

Misschien handig voor het overzicht: Hfdst 5 van m'n winsock tutorial legt alle I/O models van winsock in het kort uit.

[Verwijderd]

Die tutorial heb ik nou juist gebruikt om een beetje te orienteren op Wsock programmeren

[Olaf van der Spek]

Verwijderd schreef op 19 november 2003 @ 13:17:
@OlafvdSpek: mmm opzich moet het wel kunnen, maar omdat alle tutorials die ik tegen kwam over winsock 1 gingen...

Volgens mij is die interface hetzelfde als WinSock 2. Als je een beetje oplet, is dezelfde code trouwens ook onder Linux en co te compileren.

Het select-modem en completion-model lijkens volgens mij best wel veel op elkaar trouwens.

[ Voor 12% gewijzigd door Olaf van der Spek op 19-11-2003 18:01 ]

[Verwijderd]

OlafvdSpek schreef op 19 november 2003 @ 17:58:
[...]

Volgens mij is die interface hetzelfde als WinSock 2. Als je een beetje oplet, is dezelfde code trouwens ook onder Linux en co te compileren.

Als je gebruik maakt van WINsock specifieke zaken zoals overlapped I/O, WSAEventSelect en weet ik wat nog meer gaat het natuurlijk onder linux niet werken. Ik heb ervaring met netwerkprogrammeren op beide platforms, en in de loop der tijd een heel duidelijke voorkeur opgebouwd voor de windows aanpak. Natuurlijk werkt de 'ouderwetse' BSD socket API uitstekend en kun je er uiteindelijk hetzelfde mee, sommige dingen programmeren onder windows' socket API soms net iets logischer of makkelijker...

PS: Staedtler, ik heb je mailtje ontvangen. Ik heb in al mijn opruimwoede mijn framework 'opgeruimd', maar heb nog wel een uitgewerkte service waar het in verwerkt zit. Ik heb het daar uitgeknipt en ter download neergezet...

Je kunt het 'framework' (of wat er nog van over is) downloaden op http://www.qixis.com/~emiel/ServerFW.zip

[ Voor 9% gewijzigd door Verwijderd op 19-11-2003 20:12 ]

[Olaf van der Spek]

Verwijderd schreef op 19 november 2003 @ 19:29:
Als je gebruik maakt van WINsock specifieke zaken zoals overlapped I/O, WSAEventSelect en weet ik wat nog meer gaat het natuurlijk onder linux niet werken. Ik heb ervaring met netwerkprogrammeren op beide platforms, en in de loop der tijd een heel duidelijke voorkeur opgebouwd voor de windows aanpak. Natuurlijk werkt de 'ouderwetse' BSD socket API uitstekend en kun je er uiteindelijk hetzelfde mee, sommige dingen programmeren onder windows' socket API soms net iets logischer of makkelijker...

Kun je misschien aangeven welke dingen dat zijn?

[Verwijderd]

Ik ben vandaag weer even bezig geweest, en heb even een surrogaat klasse diagram gemaakt. (de invulling komt later wel).


De HostSocket klasse regelt het opstarten van de host die gebind
Mijn idee is dat ik bij elke client-connectie een thread opstart voor elke socket, alleen laat ik die inslapen als er niets gebeurd.
Een andere thread controleerd mbv WSAEventSelect() of er iets gebeurd en zo ja start hij de juiste client socket-thread op (bv. bij FD_READ wordt recv() opgestart voor de socket waar het gebeurd). En als hij weer een tijdje niets doet zal hij weer worden ingeslapen. Natuurlijk als er een heletijd niets gebeurd wordt de connectie vernietigd.
De ClientState klasse zou dit bij moeten houden.

Wat ik hiermee hoop de bereiken is: dat er niet super veel threads 'runnen', want als ze niet iets hoeven te doen staan ze op standby.

Sowieso heb ik mijn code even herbouwt naar aanleiding van OlafvdSpek's opmerking over dat ik niet de nieuwste versie gebruikte van winsock. (Schijnt beter te zijn voor WSASelectEvent() functie.
Ook heb ik wat zitten proberen met threads, maar omdat ze niet schijnen te werken in classen zoals ik dat zag in voorbeelden, heb ik van iemand een CThread klasse gekregen die mbv overerving wel threads kan gebruiken.

De Command klasse wordt een klasse die de input gaat analyzeren

Is dit een al wat betere aanpak?

edit: ik heb net een nieuwere versie van de MSDN geinstalleerd, en daar zie ik dat er behalve accept ook WSAAccept (etc voor alle normale functies als send en recv) is, welke raden jullie aan om te gebruiken? Want als ik in de beschrijving kijk, zie ik niet veel dat anders is.

[ Voor 10% gewijzigd door Verwijderd op 20-11-2003 16:59 . Reden: ff een extra vraag gesteld ]

[Olaf van der Spek]

Maar wat gaat je server nu precies serven?

[Verwijderd]

OlafvdSpek schreef op 19 november 2003 @ 21:47:
[...]

Kun je misschien aangeven welke dingen dat zijn?

Als klein voorbeeld... WSAEventSelect en familieleden. Als je een thread hebt onder unix, roep je select() aan om te kijken naar socket activiteit. Maar wat nou als die thread ook moet luisteren naar een 'sluit af' signaal? Dan kan je een filedescriptor misbruiken of een vlag zetten en select() een timeout meegeven en dus laten pollen... Mogelijk.

Onder windows kan je WaitForMultipleEvents() gebruiken en daaraan zowel je socket event handle als je 'stop' event handle meegeven en zo op een heel nette manier zonder polling en misbruik van FD's je thread op meer dan alleen socket events laten reageren. Het resultaat is 't zelfde maar dit model komt bij mij wat netter en vooral duidelijker over...

Windows heeft heel veel soorten handles die signaled kunnen worden en dus als 'event' gebruikt... (thread handles, I/O, sockets).

[Verwijderd]

edit: ik heb net een nieuwere versie van de MSDN geinstalleerd, en daar zie ik dat er behalve accept ook WSAAccept (etc voor alle normale functies als send en recv) is, welke raden jullie aan om te gebruiken? Want als ik in de beschrijving kijk, zie ik niet veel dat anders is.

Als ze volgens de documentatie verder hetzelfde werken is er niet echt 1 beter dan de andere. De WSA* functies zijn vaak wat verwindowst, waar de niet-WSA functies zich aan de normale BSD API houden...

PS: Als je dan toch met threads gaat werken, je kan meerdere threads alvast 'accept' laten aanroepen. De TCP stack kan dan sneller verbindingen aannemen omdat er al meteen een thread klaar staat.

[ Voor 17% gewijzigd door Verwijderd op 20-11-2003 23:48 ]

[.oisyn]

win32's synchronization functionaliteit werkt idd heerlijk. Voeg daar IO Completion Ports aan toe en je hebt meteen een half thread pooling systeem dat al voor je geïmplementeerd is

WaitForMultipleObjects werkt toch een stuk intuïtiever dan select, vooral ook omdat die laatste 3 verschillende lijsten heeft voor read, write en error. En natuurlijk het feit dat je onder win32 alle andere handles waarop je kunt wachten ook mee kunt nemen.

Wat er overigens imho wel mist in windows is een multi-read single-write mutex. Dus een soort mutex waar ofwel een oneindig aantal read locks op kunnen zitten, ofwel slechts 1 write lock. Geen idee of linux dat wel kent overigens

[Soultaker]

offtopic:
De POSIX thread library bevat primitieven voor mutual exclusion, conditions en read/write locks.

[Olaf van der Spek]

Verwijderd schreef op 20 november 2003 @ 23:34:
Windows heeft heel veel soorten handles die signaled kunnen worden en dus als 'event' gebruikt... (thread handles, I/O, sockets).

Ik neem aan dat je file I/O bedoelt?
Linux kan in select ook gewoon op file I/O wachten. Als je select en geen multi-threading gebruikt, hoef je ook niet te wachten op threads.

[Verwijderd]

OlafvdSpek schreef op 23 november 2003 @ 16:29:
[...]

Ik neem aan dat je file I/O bedoelt?
Linux kan in select ook gewoon op file I/O wachten. Als je select en geen multi-threading gebruikt, hoef je ook niet te wachten op threads.

Onder windows zijn threads zo handig in het gebruik dat het bijna zonde is om geen gebruik te maken van multithreading . Onder unix is threading er later min of meer bij bedacht en blijft de gangbare aanpak toch een beetje zoveel mogelijk single threaded werken of gebruik maken van worker processes (met het geniale fork()) en wat pipes of sockets voor de communicatie tussen deze processen.

Select kan wachten op een file descriptor (file, socket, pipe, dat soort spul). Wil je wachten op iets anders dan een filedescriptor (timer, bericht van een andere thread) dan laat select je redelijk in de steek. Je kan dan andere manieren gebruiken om de aandacht van je proces te trekken (SIGALRM, SIGIO) maar dat vind ik zelf minder mooi dan de windows aanpak, waar je met WaitForMultipleEvent kan wachten op (max 64) 'signalable handles'. Alle file handles (gemaakt met CreateFile(), dus dingen als files, devices, named pipes) vallen hier onder, maar ook Events (een windows iets), Thread handles (handle is 'signalled' als thread afsluit... onder unix gebruik je daarvoor als ik me goed herrinner een van de 'wait()' calls), en dan vergeet ik er vast nog wel een paar...

Ook een leuke in windows (al heb ik het nooit gebruikt) is dat winsock messages kan sturen naar de GUI van een applicatie (via WSAAsyncSelect). Zo kan een GUI app non-blocking werken en toch handig socket dingen doen zonder polling of extra threads...

offtopic:
Dit is wel een beetje offtopic aan het lopen. Ik ben best te vinden voor een discussie over de voors en tegens van winsock vs BSD sockets, maar mischien handig om dat in een ander topic te doen.

[ Voor 8% gewijzigd door Verwijderd op 24-11-2003 00:43 ]

[Verwijderd]

Ik ben nu al goed een week er mee bezig geweest, maar waar ik steeds weer tegen loop is het gebruik van WSAEventSelect() en WSAWaitForMultipleEvents().
Hoe moet ik die eigenlijk gebruiken?
Moet ik gewoon een loopje schrijven als volgt :

A

code:

socket1 heeft event_1 (read)
socket2 heeft event_2 (accept/connect)
socket3 heeft event_3 (read)
wacht infinite for 1 of meer van de events
als die is afgehandeld, herhaal het hele geval.

--of--
B

code:

socket1 heeft event_1 (read)
wacht honderd milliseconden op de event en ga anders verder
socket2 heeft event_2 (accept/connect)
wacht honderd milliseconden op de event en ga anders verder
socket3 heeft event_3 (read)
wacht honderd milliseconden op de event en ga anders verder
herhaal het hele geval.

Maar dit lijkt verrekte veel op polling (ik heb voorbeeld B even snel wat code in elkaar gezet, van hoe ik denk dat het zou moeten).
B

C:

SOCKET hostSocket; // = socket die werkt op poort 4567
SOCKET sock_1; //hier wil ik wachten op accept/dat de client connect
SOCKET sock_2; //hier wil ik wachten tot de client naar de server
SOCKET sock_3; //hier wil ik wachten tot de client send naar de server
 
event_1 = WSACreateEvent();   
event_2 = WSACreateEvent();
event_3 = WSACreateEvent();
 
while (1)
{
 if (WSAEventSelect (sock_1, event_1, FD_ACCEPT) == SOCKET_ERROR)
 {
  printf ("error");
  break;
 }
 
 if(WSAWaitForMultipleEvents(1,event_1,FALSE,100,FALSE))
 {
  //de connectende client aan een socket koppelen (en die wordt dan ook op read gezet)
 }
 
 if (WSAEventSelect (sock_2, event_2, FD_READ) == SOCKET_ERROR)
 {
  printf ("error");
  break;
 }
 
 if (WSAWaitForMultipleEvents(1,event_2,FALSE,100,FALSE)==WSA_WAIT_EVENT_0)
 {
  //recv
 }
 
 if (WSAEventSelect (sock_3, event_3, FD_READ) == SOCKET_ERROR)
 {
  printf ("error");
  break;
 }
 
 if (WSAWaitForMultipleEvents(1,event_3,FALSE,100,FALSE)==WSA_WAIT_EVENT_0)
 {
  //recv
 }
 
}

Versie a ook maar even uit gewerkt
A

C:

SOCKET hostSocket; // = socket die werkt op poort 4567
SOCKET sock[0]; //hier wil ik wachten op accept/dat de client connect
SOCKET sock[1]; //hier wil ik wachten tot de client naar de server
SOCKET sock[2] ;//hier wil ik wachten tot de client send naar de server
 
event[0] = WSACreateEvent();   
event[1] = WSACreateEvent();
event[2] = WSACreateEvent();
 
while (1)
{
 if (WSAEventSelect (sock[0], event[0], FD_ACCEPT) == SOCKET_ERROR)
 {
  printf ("error");
  break;
 }
 
 if (WSAEventSelect (sock[1], event[1], FD_READ) == SOCKET_ERROR)
 {
  printf ("error");
  break;
 }
  
 if (WSAEventSelect (sock[2], event[2], FD_READ) == SOCKET_ERROR)
 {
  printf ("error");
  break;
 }
 
 if (WSAWaitForMultipleEvents(3,event,FALSE,INFINITE,FALSE)==WSA_WAIT_EVENT_0)
 {
  //Doe je shit, alleen hoe kijk je dan welke is ge triggered
 }
 
}

Nu lijkt mij methode A veel mooier sneller en beter, alleen kan dit wel op die manier, want wsawaitformultipleevents() werkt toch alleen maar als alle event getriggered zijn?

en nog een klein vraagje: als ik wil dat de event wordt getriggerd als er een client connect mbv accept moet ik dan FD_ACCEPT of FD_CONNECT gebruiken (of gewoon beide)?

[Alarmnummer]

Als je trouwens wat meer over allerlei architecturen over client server applicaties wilt lezen, dan kan ik je dit boek zeker aanraden:

Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects

Echt een vette aanrader. Anders blijf je iedere keer zelf het wiel maar opnieuw uitvinden en krijg je heel langzaam pas een matig beeld.