Hej igen.
OK det lyder altså som om dine tanker kan realiseres med en enkelt server, det er jo heldigvis en del lettere at lave end et multiserver setup (som jeg faktisk sidder og arbejdet med pt.)
Altså 4-5000 spillere er muligt med en enkelt server når det er et langsomt spil. Altså jeg forestiller mig et spil der ikke har nogen form for realtids-krav. Som dit eget eksempel hjerterfri, der betyder forsinkelse (enten over netværket eller p.g.a. serverens HW) jo ikke at man ikke kan spille, men bare at der er lidt ekstra ventetid. Men du kan godt glemme sådan noget med et spil hvor alle spillere skal modtage 10 beskeder i sekundet om hvad de andre spillere laver osv., men det lyder ikke som om det er noget du har planer om.
Med de nye informationer vil jeg helt klart anbefale at du holder dig til C#/Windows, da det er noget du kender godt i forvejen. Den kortere udviklingstid (og færre frustrationer p.g.a. kendt programmeringssprog) er mere værd end at du evt. kunne have lavet en server der kørte hurtigere i C++. Man skal også huske på at en stor del af arbejdet når du enten henter eller gemmer data i databasen via din server sker på netværket og i DBMS´et, og det ville jo ikke gå hurtigere ved at serveren var kodet i C++.
TCP protokollen er let at arbejde med da den er reliable, og du får besked hvis en klient går ned... Det er så på bekostning af at den er ret langsom ift. UDP, men hvis du ikke har de store tidskrav kan TCP spare dig for meget besvær. Og selvom du så skal have en connection (port) til hver client har du jo stadig langt over 10.000 at vælge imellem.
Held og lykke med projektet i hvert fald, du kan bare sige til hvis du støder på nogle problemer eller lign.
Jeg kan lige nævne at du skal være opmærksom på at TCP er stream-oriented og hvis du altså sender en fin lille besked (f.eks. en custom class med nogle properties) kan du ikke være sikker på at modtageren får den som en besked. Når modtageren får en "besked" kan det både være en lille del af det du har sendt, eller flere beskeder du havde sendt der er blevet samlet - det kan give nogle udfordringer... En anden ting er at hvis du vælger at serialize et objekt (med .NET's indbyggede serializing) og sende det så du hos modtageren kan deserialize så skal du regne med at kæmpe overhead, det kan godt være pakken bliver 5-10 gange så stor. Så det er altså ikke altid en god løsning, men kommer igen an på kravene til systemet.
Translation
