[C#/TCP/IP] Thread per connection noodzakelijk?

[Sabbath]

Ik ben na jaren alleen maar scripten maar weer eens met programmeren begonnen en wel in de vorm van het schrijven van een messenger programma in C#. Na veel proberen en lezen heb ik het nu voor elkaar om een client te maken die tekst naar een server verstuurt maar met het oog op de toekomst maak ik me zorgen om de manier waarop ik dit gedaan heb.

Ik maak nu voor elke binnenkomende verbinding een thread aan, dat gaat natuurlijk prima wanneer er weinig clients zijn, maar volgens mij zal dit een probleem worden wanneer er meerdere clients gaan connecten. Ik heb me rot gezocht op internet, maar elk voorbeeld wat ik tegenkom doet het op deze manier, ik kan me echter niet voorstellen dat een groot netwerk als MSN / YM! etc. voor elke connectie een nieuwe thread maakt want volgens mij zou de server dan veel te zwaar worden.

Mijn vraag is dan ook: Is er een manier waarop ik niet voor elke connectie een thread nodig heb, of een andere oplossing voor dit probleem of zie ik problemen die er niet zijn en moet ik gewoon lekker door gaan op deze manier?

[Borizz]

Een groot netwerk bestaat uit meerdere servers, en die servers zullen voor elke connectie toch een thread moeten gebruiken om deze in stand te kunnen houden en de berichten bij de juiste gebruiker te bezorgen.

[.oisyn]

Het kan prima met één thread. Ik ken de .Net API niet zo goed, maar met winsock kun je gewoon op meerdere sockets 'luisteren' tot er een event of een timeout optreedt. Dus open de .Net framework documentatie en begin met lezen over Sockets

.edit: hopla, na 1 minuut zoeken ben ik al bij de static Socket.Select functie gekomen.

[ Voor 15% gewijzigd door .oisyn op 13-08-2006 22:02 ]

[Sabbath]

Thanks, sorry, ben nog niet zo ervaren in de help file van .Net Ik wist niet zo goed waar ik moest zoeken. Nu moet ik er wel een heel stuk uit komen!

[DroogKloot]

Een thread per connectie is idioot alleen al om de reden dat je niet weet hoeveel connecties er gemaakt zullen worden, dat kunnen er 10 zijn of 10000. Wat je typisch in dit soort situaties doet is een threadpool vullen met workers, en een handjevol (meestal maar 1) boss-threads die naar events luisteren en de workers delegeren, zodat je 1) geen threads on-the-fly hoeft te spawnen of te destroyen (wat duur is) tenzij alle workers bezet zijn en 2) een veel schaalbaarder systeem hebt.

[Sabbath]

Idd DrookKloot, dat dacht ik ook al.. Ik zal me ook eens gaan inlezen wat threadpools betreft, thx