Tjipp,
Jag håller på med ett serverprogram(SP) som ska prata TCP/IP med upp till flera hundra enheter så simultant som möjligt. Just nu låter jag SP hämta in alla kommandon som ska skickas ut till respektive enhet, och kör igång en egen tråd som ansluter till enheten och skickar kommandot. När tråden är klar rapporterar den till SP som flaggar status för kommandot i databasen.
Funkar hyfsat nu, men programmet går väldigt tungt vid ca 20 trådar. Enligt vad jag googlat så ska man använda non-blocking sockets, främst för anslutningsbiten, för att kunna få upp prestandan och prata med tusentals enheter. Är det någon som har något exempel på hur detta funkar?
/Rickard

Alternativet till blocking är ju att du pollar (och så finns ju mellanläget att du har en viss timeout).

Det var för länge sen jag höll på med socket-programmering, men ser inte exakt hur det skulle kunna vara bättre om det inte är så att du kan få en hel lista med anslutningar på en gång. Visa gärna en länk till någon av källorna som ger det som tips.

Det framgår inte riktigt vad det är för typ av applikation eller övriga förutsättningar heller; ibland kan man sätta upp flera servrar som samarbetar; det finns olika typer av broadcasting-möjligheter osv.

Utöver det skulle man kunna tänka sig en UDP-lösning ifall problemet tillåter det.

Håller med Niklas, UDP skulle vara en väldigt enkel lösning på problemet; multicast/eller ev. broadcast.

Men, men, jag håller med: du vill nog mest sannolikt köra non-blocking. Exempel är lite svårt att ge mer än som pseudokod då vi inte har en aning om vilket språk du tänkt dig ;)

Tjipp,
Kul att jag fick två på kroken :) Då ska jag utveckla det hela lite.
UDP är uteslutet, enheterna pratar bara TCP. Kommunikationen går över gprs och det är väl, antar jag, det som gör att det hela går lite långsamt.
Nu har jag ingen länk till nån sida om non-blocking sockets, jag har varit inne på en mängd sidor men inte sparat nån länk. Men tydligen så kör en process i non-blocking-läge vidare direkt när den försökt koppla upp mot enheten, och när uppkopplingen lyckas(eller misslyckas) så får man en callback.
Rubbet är skrivet i VB.Net 2. Så det jag är ute efter är väl egentligen hur alla asynkrona callbacks hänger ihop när man kör non-blocking.

http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=80 verkar vara rätt vettig kod (efter snabb sökning på google)

Non-blocking är helt enkelt så att istället för att t.ex. en läsning ifrån nätverket blockerar exekveringen av tråden tills det finns någonting att läsa så fortsätter bara tråden. Det finns inga callbacks (eftersom att callbacks exekveras i egna trådar, vilket förstör lite av idén med non-blocking..) utan man måste hela tiden ligga på och fråga.

Å andra sidan, eftersom att callbacks finns så kan det vara en idé att använda dem, å andra sidan ger dock callbacks fler contextswitches.. I ditt fall tror jag dock inte att det lär vara något större problem, snarare hjälpa. Titta på msdn http://msdn2.microsoft.com/en-us/library/system.net.sockets.socket(VS.71).aspx, speciellt Begin*-metoderna

Tänkte ni kunde få en liten uppdatering. Efter att ha testkört programmet nu med uppåt 50 samtidiga trådar/anslutningar så verkar det snurra på rätt snabbt faktiskt. Kör med "vanliga" tcp-socketens connect-metod.

Vet inte hur din lösning ser ut nu, men under min tid på högskolan så hade vi ett uppdrag att förändra arkitekturen i en programvara, vi valde att bygga om en dc++ hub som var singeltrådad har för mig den hette Verlihub skriven i C++.

Vi var inne på att skapa en tråd per klient, men fick veta av en av våra lärare som doktorerat i nätverksprogrammering (finns säkert ett finare ord). Och det var att man aldrig skall skapa upp trådar dynamiskt efter klienter utan efter arbete.

Säg att vi har en tråd eller flera som håller klienterna och kollar om det finns något på socketen. Om det finns något på socketen skickar vi klienten till en arbetstråd som antingen skapas upp eller hämtas från någon cache. tråden utför arbetet och så vidare.