[C#] Hulp nodig bij netwerkprogrammeren

[Verwijderd]

Hi allemaal,
Ik ben bezig aan een online game - een reboot van een oude game die ik een aantal jaar geleden in VB6 heb geschreven. Ik ben het aan het herschrijven in C# om de compatibiliteit, performance en stabiliteit te verbeteren en de spelercapaciteit te vergroten. Het is een persistent world management game met een centrale server waar spelers op inloggen. Het tempo van de updates is laag (het is een traag spel), maar de hoeveelheid te verzenden variabelen is vrij groot.

Ik heb net wat C# tutorials gevolgd en een begin gemaakt. De serverapplicatie heeft nu de gewenste datastructuur, kan deze weergeven, opslaan en laden. Het volgende punt waar ik aan wil werken, is communicatie met een client.

Nu blijkt socketprogrammeren in C# en tikkie geavanceerder dan in VB. Terwijl de basics van C# op youtube helemaal tot in den treure uiteengezet worden, lukt het me niet een leerzame video te vinden waarin echt de basistheorie van sockets uitgelegd wordt. Er vliegen een hoop statements voor bij waar ik geen bal van snap.

Vandaar mijn vraag: Wie heeft er een bron hiervoor aan te raden, of wie kan me verwijzen naar een eenvoudiger (meer readymade) object dat ik als leek kan gebruiken, of wie wil er misschien zelfs samenwerken?
En verder: Sockets is de beste optie, toch? Of zijn er alternatieven? Ik kom af en toe tegen dat de tutorial gaat over socketprogrammeren voor een lokaal netwerk, maar er wordt niet bij gezegd of dat verschilt voor internet. Verschilt dat voor internet?

Mijn dank is groot

[diondokter]

C# sockets zijn erg flexibel, en erg overwhelming. Aangezien je updates langzaam zijn kun je ook Tcp gebruiken. .Net heeft hiervoor tcplisteners. Misschien is dit interessant voor je: http://tech.pro/tutorial/...imple-threaded-tcp-server

Hoop dat je er wat aan hebt.

Als je hulp nodig hebt, mail me dan: *snip* e-mail adres *snip* (Suck it NSA!)

[ Voor 17% gewijzigd door RobIII op 13-01-2014 20:16 ]

[RobIII]

diondokter schreef op maandag 13 januari 2014 @ 19:05:
Als je hulp nodig hebt, mail me dan: *snip* e-mail adres *snip* (Suck it NSA!)

Ik weet niet wat de NSA er mee van doen heeft ( ) maar als je de communicatie "achter de schermen" trekt door te gaan mailen leert niemand behalve TS iets van dit topic. Zou een mooi forum worden als alle topics eindigen met een e-mail adres en geen oplossing he? Zie ook "mail me" is ongewenst.

[Hydra]

Verwijderd schreef op maandag 13 januari 2014 @ 18:56:
Vandaar mijn vraag: Wie heeft er een bron hiervoor aan te raden, of wie kan me verwijzen naar een eenvoudiger (meer readymade) object dat ik als leek kan gebruiken, of wie wil er misschien zelfs samenwerken?
En verder: Sockets is de beste optie, toch? Of zijn er alternatieven? Ik kom af en toe tegen dat de tutorial gaat over socketprogrammeren voor een lokaal netwerk, maar er wordt niet bij gezegd of dat verschilt voor internet. Verschilt dat voor internet?

Je legt niet uit waarop je precies vastloopt. Je snapt er geen bal van is over het algemeen een kwestie van doorleren tot je het wel snapt Ik begrijp dat je video's bekeken hebt: m.i. zijn video's slecht lesmateriaal als het gaat om echt dingen leren; je kunt niet even een stukje teruglezen als je iets niet begrijpt of even een paar pagina's terugbladeren.

Socket programmeren in C# is relatief eenvoudig: aan de server kant maak je een socket aan om op te luisteren naar inkomende connecties, dat wordt hier uitgelegd:
MSDN: Synchronous Server Socket Example

Simpelweg: socket maken, binden op een adres (0.0.0.0:<poortnummer> over het algemeen), luisteren 'aanzetten' en dan in een while loop inkomende connecties 'accepten'.

De client kant is simpeler:
MSDN: Synchronous Client Socket Example

Die connect gewoon met een endpoint, <serverip>:<poortnummer>. Van de sockets kun je de streams openen en via die streams kun je data versturen, op de zelfde manier waarop je een file schrijft / leest.

Sockets is een prima relatief simpele optie. Je kunt in jouw geval ook met webservices e.d. werken (het is toch iets dat geupdated wordt met een lage frequentie) maar ik zou eerst zorgen dat je basis sockets onder de knie krijgt. Of je het lokaal doet of via internet maakt niet uit, het is gewoon TCP/IP. Alleen moet je er rekening mee houden dat als je een keer een server opzet je aan die kant de poorten ook open zet.

[Xepos]

Maar is het niet beter om een push methode te gebruiken zodat alle gebruikers de meest recente data hebben ten alle tijden?

[Woy]

Verwijderd schreef op maandag 13 januari 2014 @ 18:56:
En verder: Sockets is de beste optie, toch? Of zijn er alternatieven?

Het is compleet afhankelijk van wat je wil, je zou bijvoobeeld ook kunnen kijken om een WebAPI te implementeren, of gebruik maken van WCF/Webservices.

Er zijn zeker gevallen waar je zelf via sockets wil gaan programmeren ( Al is het alleen maar leuk om je in te verdiepen ), maar normaal zou ik eerst naar andere oplossingen kijken.

Ik kom af en toe tegen dat de tutorial gaat over socketprogrammeren voor een lokaal netwerk, maar er wordt niet bij gezegd of dat verschilt voor internet. Verschilt dat voor internet?

Ja en Nee. Zowel op een lokaal netwerk als op het internet is het gewoon TCP/IP en dat werkt hetzelfde op een lokaal netwerk als op het internet. Echter zul je voor het internet wel rekening moeten houden met het feit dat de meeste mensen achter een router zitten die NAT doet. Dat betekend dat je niet zomaar vanuit je server een verbinding op kunt zetten naar je client. Ook zul je er rekening mee moeten houden dat de snelheid/latency van verbindingen via internet erg kunnen variëren.

[Caelorum]

Xepos schreef op dinsdag 14 januari 2014 @ 08:56:
Maar is het niet beter om een push methode te gebruiken zodat alle gebruikers de meest recente data hebben ten alle tijden?

En dat kan niet met sockets?

[Xepos]

Caelorum schreef op dinsdag 14 januari 2014 @ 09:03:
[...]

En dat kan niet met sockets?

Eerlijk gezegd weet ik dat niet, maar ik het als hint aan.
Weet niet precies hoe een socket precies word opgezet mijn kennis daarover is minimaal.

Wil het ook wel precies weten

[farlane]

Het is niet veel anders als met de VB6 WinSock control. Listen, Accept, Send en Receive. Gaan met die banaan.

[Hydra]

Xepos schreef op dinsdag 14 januari 2014 @ 09:05:
Eerlijk gezegd weet ik dat niet, maar ik het als hint aan.

Misschien moet je dan niet dat soort dingen gaan roepen als je nieteens de basis van sockets weet?

Sockets zijn gewoon streams, je leest er gewoon de data uit die er aan de andere kant ingeduwd wordt. Als je synchrone sockets gebruikt blokkeert een lees-actie tot er data is om van de socket te lezen.

[Phyxion]

Je kan ook eens kijken naar message queues, deze kunnen veel werk al voor je doen.

[Xepos]

Hydra schreef op dinsdag 14 januari 2014 @ 09:10:
[...]


Misschien moet je dan niet dat soort dingen gaan roepen als je nieteens de basis van sockets weet?

Sockets zijn gewoon streams, je leest er gewoon de data uit die er aan de andere kant ingeduwd wordt. Als je synchrone sockets gebruikt blokkeert een lees-actie tot er data is om van de socket te lezen.

Het zijn dus streams maar wanneer er dus iets word gewijzigd op de server dan moet je dat dus handmatig oproepen. Bij Java dacht ik dat daar wel zoiets zat ingebouwd, dat die automatisch een bericht verstuurt.

Of zeg ik nu helemaal iets verkeerd?

Moet eens beter lezen.
Sorry ben al lang wakker

[ Voor 3% gewijzigd door Xepos op 14-01-2014 09:19 ]

[Woy]

Xepos schreef op dinsdag 14 januari 2014 @ 09:17:
[...]
Het zijn dus streams maar wanneer er dus iets word gewijzigd op de server dan moet je dat dus handmatig oproepen. Bij Java dacht ik dat daar wel zoiets zat ingebouwd, dat die automatisch een bericht verstuurt.

Of zeg ik nu helemaal iets verkeerd?

Sorry ben al lang wakker

De meeste huidige communicatie protocollen zijn gebouwd boven op TCP/IP en dus sockets. Er zijn natuurlijk legio frameworks/protocollen die daar weer overheen gebouwd zijn die je werk uit handen nemen, en dingen makkelijker maken.

Ook HTTP werkt bijvoorbeel gewoon via TCP/IP sockets.

[4Real]

Wat ik mij altijd afvraag bij dit soort programma's is wat voor informatie tussen de programmas worden verzonden. Op het moment heb ik ook twee programma's die via sockets met elkaar praten. Echter weet ik niet of er een standaard is om opdracht en resultaat te verwerken. De server krijgt een JSON request met daarin key->value dictionary en die gebruik ik dan als input in de server.

Ik wil niet het topic kapen, maar als iemand hier een tip voor heeft. Graag!

[Hydra]

4Real schreef op dinsdag 14 januari 2014 @ 09:56:
Wat ik mij altijd afvraag bij dit soort programma's is wat voor informatie tussen de programmas worden verzonden. Op het moment heb ik ook twee programma's die via sockets met elkaar praten. Echter weet ik niet of er een standaard is om opdracht en resultaat te verwerken. De server krijgt een JSON request met daarin key->value dictionary en die gebruik ik dan als input in de server.

Ik wil niet het topic kapen, maar als iemand hier een tip voor heeft. Graag!

Wat je maar wil. Je kunt objecten serializen naar JSON of XML, Google protobuf gebruiken, of een van de vele andere libraries die daarvoor beschikbaar zijn. Zelf zou ik voor een simpel project waar de overhead weinig uitmaakt waarschijnlijk voor JSON gaan, is simpel te implementeren.

Voor 3D shooters wordt vaak UDP gebruikt. Je hebt minder overhead en geen 'last' van hiccups door packets die droppen, alleen kun je er niet van op aan dat alle pakketjes ook daadwerkelijk aankomen, dus daar moet je dan zelf iets voor bedenken. Er is genoeg informatie over hoe bijvoorbeeld Quake UDP gebruikt. Je kunt ook voor een combinatie gaan (doet WoW geloof ik).

[Woy]

Volgens mij gebruiken de meeste moderne games ook gewoon TCP/IP i.p.v. UDP. De overhead die dat met zich meebrengt weegt meestal gewoon niet op tegen het voordeel van gegarandeerde delivery/volgorde. Tevens zal UDP ook vaker geblokkeerd zijn op netwerken.

[CodeCaster]

4Real schreef op dinsdag 14 januari 2014 @ 09:56:
Wat ik mij altijd afvraag bij dit soort programma's is wat voor informatie tussen de programmas worden verzonden. Op het moment heb ik ook twee programma's die via sockets met elkaar praten. Echter weet ik niet of er een standaard is om opdracht en resultaat te verwerken. De server krijgt een JSON request met daarin key->value dictionary en die gebruik ik dan als input in de server.

Ik wil niet het topic kapen, maar als iemand hier een tip voor heeft. Graag!

Het eerste wat komt kijken bij het versturen van berichten over streams is message framing, omdat de zojuist gelezen fractie van een stream gedeeltelijke en/of samengevoegde berichten kan bevatten. Dit kan grofweg op twee manieren, met een length prefix ("hier komen N bytes", zie HTTP) of een delimiter ("dit was (een deel van) het bericht", zie SMTP).

De manier waarop de data vervolgens in dat bericht wordt verpakt, hangt totaal af van de situatie en data, zie Hydra's reply.

Woy schreef op dinsdag 14 januari 2014 @ 10:10:
Volgens mij gebruiken de meeste moderne games ook gewoon TCP/IP i.p.v. UDP. De overhead die dat met zich meebrengt weegt meestal gewoon niet op tegen het voordeel van gegarandeerde delivery/volgorde. Tevens zal UDP ook vaker geblokkeerd zijn op netwerken.

Voor de realtime data wordt in games wel degelijk UDP gebruikt. Bij packet loss met TCP zou je anders tot wel ettelijke seconden gaan achterlopen op de werkelijkheid tot de verbinding weer optimaal is, wat bij een FPS verre van wenselijk is.

Zie bijvoorbeeld ook The Quake3 Networking Model.

[ Voor 23% gewijzigd door CodeCaster op 14-01-2014 10:22 ]

[Woy]

@CodeCaster: Ik weet dat dat in Quake 3 gebruikt word, maar volgens mij is dat ondertussen al weer achterhaald. Nu ben ik niet in die sector werkzaam, maar dat is wat ik begrepen heb.

[Verwijderd]

Dank voor alle reacties Ik zal de door jullie gegeven voorbeelden allemaal doornemen zodra ik tijd heb. In de tussentijd nog wat dingen;

Om terug te komen op wat ik niet snapte: Het is vooral dat in tutorials (komt ook wel terug in materiaal wat hier gepost is) dat er dingen voorbij komen zoals endpoints, backlogs en buffers terwijl ik geen idee heb wat het inhoud (misschien soms een vaag idee, maar ik zou er net zo goed naast kunnen zitten en ik weet zeker dat er belangrijke dingen zijn die je erover moet weten). De enige termen die ik ken zijn zoals in VB6 met winsock IP-adres ( ), port, listen, connect, accept, send, receive. Voor de rest ben ik echt een leek.

Ik ga het doornemen, misschien kom ik er verder wel uit zo Toch verwacht ik dat een aantal dingen wat raadelachtig blijft. Zo wordt er in de link van diondokter gezegd dat de computer het niet zo leuk vindt als er teveel connecties zijn, maar wat er dan gebeurt en wat die limiet is wordt niet gezegd. Ik heb geen idee of ik dan aan 5 of aan 500 connecties moet denken. Ook heb ik geen gevoel over hoe lang een bericht/datastroom kan zijn, hoe vaak ze kunnen plaatsvinden, en welk formaat data het aantrekkelijkst is (voorheen had ik lange strings opgesteld, aaneenschakelingen van vooral int waarden, van elkaar gescheiden met een markeringskarakter).

In mijn specifieke geval: Het spel stuurt updates op aanvraag van de gebruiker (dit varieert in de praktijk van elke 10 seconden tot zo'n elke 2 minuten). Er moeten objecten gecommuniceerd worden die uit zo'n 200 variabelen bestaan (bijna allemaal ints, paar booleans en een handjevol strings). Als een gebruiker de kaart opvraagt kan dat aantal misschien wel oplopen tot 20.000 waarden (dat lijkt mij behoorlijk veel?) maar het laden mag even duren. Ik wring mij soms in bochten om het aantal variabelen zo klein mogelijk te houden maar ik heb geen idee wat het systeem eigenlijk aankan.. Misschien dat iemand op basis van deze info mij specifieke methoden of strategieen kan aanraden Ik kan me bijvoorbeeld voorstellen dat het nodig is om op de server bij te houden welke data ongewijzigd is sinds de laatste update, maar dat wordt een kostbaar systeem dat ik alleen wil bouwen als het echt nodig is. Het gedeelte TCP Socket klinkt tot nu toe in elk geval het aantrekkelijkst

[ Voor 4% gewijzigd door Verwijderd op 14-01-2014 10:35 ]

[Phyxion]

Woy schreef op dinsdag 14 januari 2014 @ 10:27:
@CodeCaster: Ik weet dat dat in Quake 3 gebruikt word, maar volgens mij is dat ondertussen al weer achterhaald. Nu ben ik niet in die sector werkzaam, maar dat is wat ik begrepen heb.

Om even een voorbeeld te geven, BF4 gebruikt nog steeds UDP

[Woy]

Phyxion schreef op dinsdag 14 januari 2014 @ 10:35:
[...]

Om even een voorbeeld te geven, BF4 gebruikt nog steeds UDP

Ik was het net zelf ook aan het kijken inderdaad

[EddoH]

Verwijderd schreef op dinsdag 14 januari 2014 @ 10:31:


Om terug te komen op wat ik niet snapte: Het is vooral dat in tutorials (komt ook wel terug in materiaal wat hier gepost is) dat er dingen voorbij komen zoals endpoints, backlogs en buffers terwijl ik geen idee heb wat het inhoud

Dit zijn niet echt specifieke networking termen, meer generieke engelse termen en concepten die vaak gebruikt worden in software. Deze kun je prima googlen zodat je in ieder geval de vertaling weet en het concept erachter beter kan snappen. Ze hebben geen specifieke betekenis betreft sockets.

[CodeCaster]

Woy schreef op dinsdag 14 januari 2014 @ 10:27:
@CodeCaster: Ik weet dat dat in Quake 3 gebruikt word, maar volgens mij is dat ondertussen al weer achterhaald. Nu ben ik niet in die sector werkzaam, maar dat is wat ik begrepen heb.

Als één TCP-pakketje opnieuw verzonden moet worden, of er moet op worden gewacht omdat het over een andere, tragere route is gegaan, blijft alle reeds ontvangen en nog opvolgende data nutteloos in een buffer staan tot de ontvangstbevestiging binnen is, terwijl de game ondertussen aan de lopende band nieuwe data aan het genereren is.

Zeker bij shooters waar je op z'n hoogst iedere ~ 100ms de meest recente data wil hebben, kun je hier niet op wachten. Dat neemt niet weg dat TCP óók wordt gebruikt, maar UDP is zeker nog niet afgeschreven.

Verwijderd schreef op dinsdag 14 januari 2014 @ 10:31:
Om terug te komen op wat ik niet snapte: Het is vooral dat in tutorials dat er dingen voorbij komen zoals endpoints, backlogs en buffers terwijl ik geen idee heb wat het inhoudt

Wat let je om ieder van de termen te Googlen?

[google=socket endpoint] -> "the IP address and port number to which the Socket is connected [or listening]."
[google=socket backlog] -> "a special constant that instructs the underlying service provider responsible for socket s to set the length of the queue of pending connections"
[google=socket buffer] -> "The socket buffer is the structure used to address and manage a packet over the entire time this packet is being processed in the kernel" (waarschijnlijk niet wat bedoeld wordt in die context, maar juist een byte-array die door jouw socket wordt gebruikt om te lezen of schrijven)

Zo wordt er in de link van diondokter gezegd dat de computer het niet zo leuk vindt als er teveel connecties zijn, maar wat er dan gebeurt en wat die limiet is wordt niet gezegd. Ik heb geen idee of ik dan aan 5 of aan 500 connecties moet denken.

Als je hierop doelt:

The server spawns a thread for each client and can, in theory, accept as many connections as you want (although in practice this is limited because you can only spawn so many threads before Windows will get upset)

[google=windows socket limit] -> duizenden tot tienduizenden.

Ook heb ik geen gevoel over hoe lang een bericht/datastroom kan zijn,

Onbeperkt.

hoe vaak ze kunnen plaatsvinden,

Wat?

en welk formaat data het aantrekkelijkst is (voorheen had ik lange strings opgesteld, aaneenschakelingen van vooral int waarden, van elkaar gescheiden met een markeringskarakter).

Zie bovenstaande posts.

[Xepos]

CodeCaster schreef op dinsdag 14 januari 2014 @ 10:43:

[...]

Onbeperkt.

Over de lengte van het pakketje. Stel je stopt er zoveel in dat het veel langer duurt om te verzenden en inmiddels zijn er al nieuwe pakketjes gereed om te verzenden. Houden de sockets hier zelf rekening mee?

Zoals in OP zijn scenario als hij nou de kaart laad maar anderen doen tijdens het laden van de kaart een aantal acties die bepaalde dingen wijzigen.
Wat is de volgorde van de pakketjes? Eerst gewoon de hele kaart en dan pas de kleine dingetjes? Of is het de snelste eerst? Waardoor de kans is dat je uiteindelijk oude gegevens ziet.

[CodeCaster]

TCP is een FIFO-stream. Wat je er het eerst in stopt, wordt het eerst gelezen. Je wil dus niet één bericht van een paar MB sturen als die data al is verouderd tegen de tijd dat het volledig is gelezen.

Om dit te realiseren kun je je map segmenteren, waardoor je tussen de map-berichten ook andere berichten kunt sturen, die eventueel updates zijn van eerder ontvangen segmenten.

[ Voor 8% gewijzigd door CodeCaster op 14-01-2014 11:01 ]

[Hydra]

CodeCaster schreef op dinsdag 14 januari 2014 @ 10:57:
TCP is een FIFO-stream.

Idd. En dat zijn redelijk basale zaken waarover meer dan genoeg informatie te vinden is op internet.

[CodeCaster]

Ik vind het internet een beetje tegenvallen qua heldere en volledige uitleg over netwerken in het algemeen en sockets in het bijzonder (de formele uitleg is er inderdaad), maar de bijbel is zo duur. Beej is een goed online alternatief.

[ Voor 21% gewijzigd door CodeCaster op 14-01-2014 11:09 ]

[Hydra]

Verwijderd schreef op dinsdag 14 januari 2014 @ 10:31:
Ik ga het doornemen, misschien kom ik er verder wel uit zo Toch verwacht ik dat een aantal dingen wat raadelachtig blijft. Zo wordt er in de link van diondokter gezegd dat de computer het niet zo leuk vindt als er teveel connecties zijn,

Mensen hebben hier nogal eens de neiging kennis te spuwen die op dat moment niet relevant is voor de vraagsteller. Limieten van aantallen connecties ga jij met jouw spelletje helemaal niet tegenaan lopen. Je bent geen MMO met duizenden spelers aan 't bouwen.

maar wat er dan gebeurt en wat die limiet is wordt niet gezegd. Ik heb geen idee of ik dan aan 5 of aan 500 connecties moet denken. Ook heb ik geen gevoel over hoe lang een bericht/datastroom kan zijn, hoe vaak ze kunnen plaatsvinden, en welk formaat data het aantrekkelijkst is (voorheen had ik lange strings opgesteld, aaneenschakelingen van vooral int waarden, van elkaar gescheiden met een markeringskarakter).

Je kunt het prima doen zoals je het eerder al deed. Je zit je nu vooraf druk te maken over dingen waar je nu uberhaupt niet tegenaan gaat lopen (if ever, wat jij doet is redelijk triviaal).

In mijn specifieke geval: Het spel stuurt updates op aanvraag van de gebruiker (dit varieert in de praktijk van elke 10 seconden tot zo'n elke 2 minuten). Er moeten objecten gecommuniceerd worden die uit zo'n 200 variabelen bestaan (bijna allemaal ints, paar booleans en een handjevol strings). Als een gebruiker de kaart opvraagt kan dat aantal misschien wel oplopen tot 20.000 waarden (dat lijkt mij behoorlijk veel?) maar het laden mag even duren. Ik wring mij soms in bochten om het aantal variabelen zo klein mogelijk te houden maar ik heb geen idee wat het systeem eigenlijk aankan.. Misschien dat iemand op basis van deze info mij specifieke methoden of strategieen kan aanraden Ik kan me bijvoorbeeld voorstellen dat het nodig is om op de server bij te houden welke data ongewijzigd is sinds de laatste update, maar dat wordt een kostbaar systeem dat ik alleen wil bouwen als het echt nodig is.

Als je een online spel speelt wordt bij elke update die je krijgt niet heel het level meegestuurd, maar krijg je updates van objecten die sinds de vorige update van plek veranderd zijn. Hoe jouw spel werkt weet ik niet, maar het is relatief simpel om verschillende berichten te bedenken en alleen de dingen die veranderen te sturen.

Maar zorg nu eerst maar eens dat je gewoon de basiscommunicatie op orde hebt, dan kun je je later altijd bezig gaan houden met het efficienter maken van het dataverkeer.

CodeCaster schreef op dinsdag 14 januari 2014 @ 11:07:
Ik vind het internet een beetje tegenvallen qua heldere en volledige uitleg over netwerken in het algemeen en sockets in het bijzonder (de formele uitleg is er inderdaad), maar de bijbel is zo duur. Beej is een goed online alternatief.

Het boek van Tanenbaum is een aanrader (een van de weinige boeken die ik voor m'n studie van begin tot einde gelezen heb) maar voor een simpele uitleg over TCP/IP gewoon overkill. Wikipedia is een prima start.

[ Voor 11% gewijzigd door Hydra op 14-01-2014 11:12 ]

[Verwijderd]

Weer dank voor de (snelle) reacties

De reden waarom ik dit mede dmv een forum wil leren, is omdat met alleen google alles zo abstract blijft. Jullie begrijpen dit al dus jullie weten de info op waarde te schatten, voor iemand anders is dit veel lastiger. Het is gewoon fijn om jullie er even over te horen. Daarom leg ik mijn specifieke situatie voor. Het had wat mij betreft goed gekund dat jullie hadden gereageerd met: "oh maar in DAT geval zou ik absoluut niet voor TCP gaan" of "ze zeggen dat het niet uitmaakt wat je invult bij backlog maar mijn ervaring is zo en zo" of "gebruik zoveel mogelijk bools" of wat dan ook.

Fijn om te horen dat het allemaal zulke grote getallen zijn. Goed punt van Xepos, ik begrijp nu dat ik er vooral op moet letten dat de berichten niet gaan "klonteren", voor de rest is lengte dus niet zo'n issue.

@ Hydra: De reden waarom ik me er nu al mee bezig houd is omdat ik deze keer vanaf het begin alles stevig en clean wil opzetten zodat het niet opnieuw uit z'n voegen barst en ik spelers moet weigeren. Je hebt gelijk dat ik inderdaad maar moet proberen en dan verder moet tweaken, maar het is wel degelijk van belang dat er geen duizenden, maar wel honderden spelers tegelijk kunnen spelen. Dit is voor mij echt een groot project met een lange geschiedenis, niet zomaar een "spelletje" dat ik uit verveling uit het niets verzin. Degelijkheid is dus een prioriteit voor mij.

[H3llrais3r]

Sockets is de beste optie, toch? Of zijn er alternatieven?

D'r zijn verschillende manieren van Client <==> Server communicatie.
Basic Socket is 1 optie maar niet per definitie de beste.
Wellicht is het beter om Webservices te gaan gebruiken.
Deze zijn veel makkelijker te implementeren dan zelf je Socket en afhandelingen te schrijven. (*mijn mening)

Daarbij heb je verschillende manieren van Webservices, Rest, SOAP...

Ik zou onderzoek doen naar verschillende soorten webservices, ieder heeft zijn voordelen en nadelen.
(Bijv.: SOAP wordt standaard niet door Android ondersteunt mocht je ooit een (native) app willen gaan bouwen.. D'r zijn dan wel libraries voor die het wel ontsluiten maar dan ben je weer daar van afhankelijk)

[Woy]

SOAP zou ik zelf nooit kiezen als je zowel de client als server in beheer hebt, het is veel te draconisch.

[Schnoop]

Verwijderd schreef op dinsdag 14 januari 2014 @ 10:31:
In mijn specifieke geval: Het spel stuurt updates op aanvraag van de gebruiker (dit varieert in de praktijk van elke 10 seconden tot zo'n elke 2 minuten). Er moeten objecten gecommuniceerd worden die uit zo'n 200 variabelen bestaan (bijna allemaal ints, paar booleans en een handjevol strings). Als een gebruiker de kaart opvraagt kan dat aantal misschien wel oplopen tot 20.000 waarden (dat lijkt mij behoorlijk veel?) maar het laden mag even duren. Ik wring mij soms in bochten om het aantal variabelen zo klein mogelijk te houden maar ik heb geen idee wat het systeem eigenlijk aankan.. Misschien dat iemand op basis van deze info mij specifieke methoden of strategieen kan aanraden Ik kan me bijvoorbeeld voorstellen dat het nodig is om op de server bij te houden welke data ongewijzigd is sinds de laatste update, maar dat wordt een kostbaar systeem dat ik alleen wil bouwen als het echt nodig is. Het gedeelte TCP Socket klinkt tot nu toe in elk geval het aantrekkelijkst

Je keuzes zijn:
-UDP
-TCP

In jouw geval zou ik kiezen voor TCP. Je geeft aan dat de gebruikers een actie verricht en deze verstuurd wordt naar de server welke deze verwerkt en informatie terug verstuurd. Ping-pong dus.
UDP wordt gebruikt bij bijvoorbeeld FPS, de server stuurt gewoon data naar de client en het zal hem verder weinig uitmaken of het aankomt (grof gezegd). De clients werken in vrijwel alle gevallen met interpolatie om "lag" te minimaliseren. Om deze reden zie je als je lagged dus ook enemies verspringen (jouw client denk dat ze rechtdoor lopen, maar even later ontvang je het bericht dat ze toch rechtsaf zijn gegaan).

Als de gebruikerinput dus gehalt kan worden totdat de gebruiker de informatie van de server ontvangt is TCP een prima oplossing.


Dan komt de vraag, wordt het SOAP, Webservices of gewoon sockets?

Bij sockets zal je zelf de server/client structuur dienen te maken.
Zie hier een voorbeeld. Je client stuurt alsware een stream aan bytes naar je server en visa versa. Je zou dus bijvoorbeeld de eerste 4 bytes kunnen gebruiken om aan te geven welke data verstuurd wordt (of welke functie de data dient af te handelen) en de bytes hierna kunnen vullen met de data (of zelf een gezipte versie ervan om het sneller te maken).

Ik weet niet of je programmeert in Visual Studio, indien wel dat zou ik wellicht kiezen voor Windows Communication Foundation (WCF).

Simpel gezegd komt het er op neer dat je een service classe maakt waar functies instaan welke de client aan kan roepen.

Hier zou bijvoorbeeld de volgende functie in kunnen staan:

code:

public List<GameCard> GetAllGameCards()
{
    return this.AllGameCards();
}

Als jij een classe hebt genaamd GameCard wordt deze automatisch geserialized en over het netwerk naar de client gestuurd als deze de Webservice.GetAllGameCards() aanvraagd. Je zult wel de GameCard classe aan moeten passen zodat deze serializable is.

Hier vind je een handige beginners tutorial over WCF.

Omdat WCF ook SOAP bindings ondersteunt ben je afgezien van de server dus niet afhankelijk van een bepaald OS.


De keuze is bij jezelf, ik zou in dit geval indien mogelijk gewoon voor WCF gaan. Ja het kost even tijd om het te leren, maar ik denk dat dit nog altijd minder zal zijn als zelf een TCP (en al helemaal UDP) client-server te schrijven.

[farlane]

Schnoop schreef op dinsdag 14 januari 2014 @ 16:20:
De keuze is bij jezelf, ik zou in dit geval indien mogelijk gewoon voor WCF gaan. Ja het kost even tijd om het te leren, maar ik denk dat dit nog altijd minder zal zijn als zelf een TCP (en al helemaal UDP) client-server te schrijven.

Really?

C#:

Socket listener;
listener.Bind( ... );

if( listener.DataAvailable )
{
    byte[] buffer = ....

    listener.ReceiveFrom( buffer, .... );

    // Do stuff
}

Het zend gedeelte is nog te simpel om over te praten...

Waarom doen mensen tegenwoordig zo moeilijk over dit soort basisdingen?

[ Voor 5% gewijzigd door farlane op 15-01-2014 11:01 ]

[sig69]

Maar je mist hier nog een stukje serialisatie/deserialisatie, message routering, etc. die je met WCF allemaal "gratis" krijgt natuurlijk. Ja, luisteren op een socket is niet zo moeilijk, maar daadwerkelijk berichten heen en weer sturen en er ook iets zinnigs mee doen vergt wel iets meer werk.

[Hydra]

Klopt m'n vermoeden dat WCF nogal MS specifiek is?

[RobIII]

Hydra schreef op woensdag 15 januari 2014 @ 11:46:
Klopt m'n vermoeden dat WCF nogal MS specifiek is?

WCF is gewoon, in de basis, een communicatieframework dat doorgaans gewoon SOAP praat.

[ Voor 13% gewijzigd door RobIII op 15-01-2014 12:12 ]

[Caelorum]

RobIII schreef op woensdag 15 januari 2014 @ 12:10:
[...] dat doorgaans gewoon SOAP praat.

Maar hoeft niet (Om het even te verduidelijken: het kan ook 'gewoon XML', binary, enz.)

[ Voor 17% gewijzigd door Caelorum op 15-01-2014 12:32 ]

[farlane]

sig69 schreef op woensdag 15 januari 2014 @ 11:37:
Maar je mist hier nog een stukje serialisatie/deserialisatie, message routering, etc. die je met WCF allemaal "gratis" krijgt natuurlijk. Ja, luisteren op een socket is niet zo moeilijk, maar daadwerkelijk berichten heen en weer sturen en er ook iets zinnigs mee doen vergt wel iets meer werk.

Afhankelijk van wat je use case, misschien niet zo heel veel meer. Er wordt (wederom) nogal anaal gedaan over iets dat in essentie iedere programmeur moet beheersen, vind ik.

[Hydra]

RobIII schreef op woensdag 15 januari 2014 @ 12:10:
[...]

WCF is gewoon, in de basis, een communicatieframework dat doorgaans gewoon SOAP praat.

Ja, maar mijn ervaringen met MS en wat zij vinden dat voldoet aan de standaarden (alsin; alles niet MS las het niet) is niet enorm positief. Dus ben dan benieuwd of het tegenwoordig beter is.

farlane schreef op woensdag 15 januari 2014 @ 15:30:
[...]

Afhankelijk van wat je use case, misschien niet zo heel veel meer. Er wordt (wederom) nogal anaal gedaan over iets dat in essentie iedere programmeur moet beheersen, vind ik.

Met dat laatste ben ik het ook eens. Spul over sockets pompen is gewoon basiskennis.

[ Voor 28% gewijzigd door Hydra op 15-01-2014 15:35 ]

[Verwijderd]

Bedankt weer voor de antwoorden, en bedankt Schnoop voor de uitleg! Ik heb dat stuk over WCF ook even doorgenomen.

Ik denk dat ik al met al voor TCP sockets ga. Ik kwam dit tegen;
http://www.codeproject.co...gh-Performance-Socket-Cod

Fijn uitgebreid artikel, wat ik zelfs vaag begin te snappen op deze manier Het gaat hier wel over een andere class (SocketAsyncEventArgs) dan wat ik elders gezien heb. Is daar een bepaalde reden voor? (vooral: is dit wel goed, dan?) Ik ben nu halverwege met het doornemen. Als niemand het hier sterk afraadt denk ik dat ik dit een kans geef Het is wel erg groot, maar in ieder geval goed gecomment en netjes modulair opgezet, dat is fijn overnemen.

(Wat betreft het technische "niveau" - nogmaals, voor jullie is dit een peulenschil omdat jullie waarschijnlijk veel programmeren, en/of een baan hebben waarin je programmeert, en/of les gehad hebt in programmeren... voor mij is het lastiger, dus excuseer. Ik wil niet uitgebreid leren netwerkprogrammeren, ik wil dit ene specifieke probleem opgelost zien zodat ik weer verder kan met de ontwikkeling van de game. Ik had programmeurs in het team maar die hadden geen tijd meer, dus ik moet het zelf op zien te knappen Als je alleen de basisoperators, methods en classes onder de knie hebt blijft 99% van de tutorials en google resultaten nèt een brug te ver, helaas)

[farlane]

Verwijderd schreef op woensdag 15 januari 2014 @ 16:04:
(Wat betreft het technische "niveau" - nogmaals, voor jullie is dit een peulenschil omdat jullie waarschijnlijk veel programmeren, en/of een baan hebben waarin je programmeert, en/of les gehad hebt in programmeren... voor mij is het lastiger, dus excuseer. Ik wil niet uitgebreid leren netwerkprogrammeren, ik wil dit ene specifieke probleem opgelost zien zodat ik weer verder kan met de ontwikkeling van de game.)

Hele socket verhaal is eigenlijk best basic, ook als je niet een of andere programmeerguru bent. ( En jij bevestigt dat eigenlijk door aan te geven dat je het gelinkte stuk een beetje snap. )

Oh ja en (nogmaals) een rule of thumb is dus dat:
- UDP vaak voor low-latency communicatie wordt gebruikt ( omdat geen handshaking, geen Nagle etc )
- TCP vaak voor high-throughput wordt gebruikt ( omdat !(UDP omdat) )

[Hydra]

Verwijderd schreef op woensdag 15 januari 2014 @ 16:04:
Fijn uitgebreid artikel, wat ik zelfs vaag begin te snappen op deze manier Het gaat hier wel over een andere class (SocketAsyncEventArgs) dan wat ik elders gezien heb. Is daar een bepaalde reden voor? (vooral: is dit wel goed, dan?) Ik ben nu halverwege met het doornemen. Als niemand het hier sterk afraadt denk ik dat ik dit een kans geef Het is wel erg groot, maar in ieder geval goed gecomment en netjes modulair opgezet, dat is fijn overnemen.

Async is nogal anders dan sychrone sockets. Async programmeren werkt met 'events': je krijgt een event binnen als er nieuwe data is. Als je synchrone sockets gebruikt heb je gewoon een thread per socket die blockt op het moment dat er geen data meer is. Dat laatste is eenvoudiger, async is 'beter' als je erg veel (duizenden) connecties hebt.

(Wat betreft het technische "niveau" - nogmaals, voor jullie is dit een peulenschil omdat jullie waarschijnlijk veel programmeren, en/of een baan hebben waarin je programmeert, en/of les gehad hebt in programmeren... voor mij is het lastiger, dus excuseer. Ik wil niet uitgebreid leren netwerkprogrammeren, ik wil dit ene specifieke probleem opgelost zien zodat ik weer verder kan met de ontwikkeling van de game. Ik had programmeurs in het team maar die hadden geen tijd meer, dus ik moet het zelf op zien te knappen Als je alleen de basisoperators, methods en classes onder de knie hebt blijft 99% van de tutorials en google resultaten nèt een brug te ver, helaas)

Tja, we zijn hier geen afhaalchinees voor kant en klare oplossingen. Mensen proberen je hier alleen maar tips te geven over de dingen die je zou moeten leren.

farlane schreef op woensdag 15 januari 2014 @ 16:24:
Oh ja en (nogmaals) een rule of thumb is dus dat:
- UDP vaak voor low-latency communicatie wordt gebruikt ( omdat geen handshaking, geen Nagle etc )
- TCP vaak voor high-throughput wordt gebruikt ( omdat !(UDP omdat) )

Mwa. Het is meer zo dat UDP gebruikt wordt als TCP niet gaat werken, da's eigenlijk de enige reden dat je zelf een protocol bovenop IP wil bouwen.

[ Voor 12% gewijzigd door Hydra op 15-01-2014 16:55 ]

[RobIII]

Hydra schreef op woensdag 15 januari 2014 @ 16:39:
Async is nogal anders dan sychrone sockets. Async programmeren werkt met 'events':

Niet helemaal (of misschien beter: dat biedt wat ruimte voor verduidelijking); sockets in .Net gebruiken:

• synchronous (blocking dus) (bijv. Send())
• asynchronous:
  • APM (bijv. BeginSend() + EndSend()) ^{"no longer recommended for new development"}
  • EAP (bijv. SendAsync())
  • TAP (Nog) niet supported

Helaas kent een Socket geen events zoals dat in VB6 bijvoorbeeld wel nog 't geval was en zoals je die bijv. gewend bent van een TextBox. Zie voor de verschillende "Asynchronous Programming Patterns" deze pagina.

[ Voor 22% gewijzigd door RobIII op 15-01-2014 17:29 ]

[Verwijderd]

Aha, bedankt, ik snap het verschil tussen sync en async nu iets beter. Inderdaad; ik ben gewend aan VB6 sockets met events.... dat waren nog eens tijden! Daarom vind ik het lastig te conceptualiseren hoe de flow van de code loopt in veel C# voorbeelden.
Maar: heh?! Als ik het goed begrijp zijn géén van de drie manieren van async aan te bevelen, en met sync heb je threads nodig. Ik heb begrepen dat threads bedoeld zijn voor paralelle processen (zoals bijvoorbeeld listen van een socket). Het komt op mij over alsof threads gebruiken voor vele connecties dat systeem een beetje misbruikt. Hydra spreekt over duizenden, maar elders zag ik iemand het hebben over 100+. Ik wil het zo bouwen dat de server zo'n 200 tot 300 connecties wel aankan. (Niet dat ik al zo veel betainschrijvingen heb ofzo, of dat iedereen gelijktijdig online is, maar ik wil het uit principe niet zo maken dat ik nu al onnodige beperkingen inbouw voor de toekomst..)

De client verstuurt data alléén op input van de speler, de server stuurt data die opgevraagd wordt door de speler, plus een update die elke 6 minuten plaatsvindt. Async leek mij in principe prima geschikt daarvoor..

Hydra schreef op woensdag 15 januari 2014 @ 16:39:

Tja, we zijn hier geen afhaalchinees voor kant en klare oplossingen. Mensen proberen je hier alleen maar tips te geven over de dingen die je zou moeten leren.

Tja, wees maar niet bang, het is niet alsof ik jullie het werk laat doen en zelf achterover zit zonder m'n hersens erover te breken Bovendien ben je van me af zodra dit opgelost is. (Naja, misschien kom ik een probleem tegen met de GUI, maar dat topic mag je dan mijden )

[ Voor 19% gewijzigd door Verwijderd op 16-01-2014 09:15 ]

[Schnoop]

farlane schreef op woensdag 15 januari 2014 @ 15:30:
[...]
Afhankelijk van wat je use case, misschien niet zo heel veel meer. Er wordt (wederom) nogal anaal gedaan over iets dat in essentie iedere programmeur moet beheersen, vind ik.

Ik vind het nogal onzin dat elke programmeur op socketniveau moet leren programmeren. Waarom zou je het hele stukje server-client met (de)serialisatie zelf gaat programmeren als het niet hoeft? Hoe "simpel" dat ook mag zijn.

WCF is gewoon user friendly. Nieuwe functie? Creer deze server-sided, update je client-service reference en klaar. Als een bepaald iets zoals WCF socket traffic gewoon makkelijker maakt waarom zou je het dan niet gebruiken.
Zeggen dat in essentie elke programmeur dit moet beheersen vink ik bijna het zelfde als zeggen dat elke programmeur in assembly moet kunnen programmeren.... Je snapt wellicht beter wat er gebeurt maar het is echt geen pré.

Maar goed, als je liever voor sockets kiest zou ik wel aanraden om gewoon zelf eens iets te proberen. Maak eens een chatapplicatie of iets in die richting om een beetje de feeling te krijgen.

Hier kan je overigens ook nog heel veel informatie vinden over sockets, streams, (a)sync en serializatie. De site ziet er wat dos achtig uit maar er staat prima info op.

En stel dat je echt geen zin hebt om je in het hele socket verhaal te verdiepen raad ik je deze library aan.
Networkcomms: Erg makkelijke library, gratis om te "testen/ontwikellen". Kost 150 dollar ofzo als je echt iets wilt releasen/verkopen wat de library gebruikt.

[Hydra]

Schnoop schreef op donderdag 16 januari 2014 @ 09:40:
Ik vind het nogal onzin dat elke programmeur op socketniveau moet leren programmeren.

Waarom? Als je dat al niet kunt kan je jezelf niet serieus programmeur noemen. Je moet gewoon weten wat onderwater bij dit soort communicatie komt kijken.

Ik vind ook dat elke programmeur moet weten hoe een CPU nu echt werkt, en dat betekent niet dat je een enorme webapplicatie in assembly moet bouwen, maar je moet wel weten hoe het werkt. En assembly is juist extreem simpel, het is alleen reteveel werk om er iets zinnigs mee te doen.

[ Voor 28% gewijzigd door Hydra op 16-01-2014 11:16 ]

[Hydra]

Verwijderd schreef op donderdag 16 januari 2014 @ 09:10:
Aha, bedankt, ik snap het verschil tussen sync en async nu iets beter. Inderdaad; ik ben gewend aan VB6 sockets met events.... dat waren nog eens tijden! Daarom vind ik het lastig te conceptualiseren hoe de flow van de code loopt in veel C# voorbeelden.
Maar: heh?! Als ik het goed begrijp zijn géén van de drie manieren van async aan te bevelen, en met sync heb je threads nodig. Ik heb begrepen dat threads bedoeld zijn voor paralelle processen (zoals bijvoorbeeld listen van een socket). Het komt op mij over alsof threads gebruiken voor vele connecties dat systeem een beetje misbruikt. Hydra spreekt over duizenden, maar elders zag ik iemand het hebben over 100+. Ik wil het zo bouwen dat de server zo'n 200 tot 300 connecties wel aankan.

Dat kan prima met gewoon synchrone TCP/IP. Het nadeel van synchrone TCP/IP is vooral dat je voor elke verbinding een thread nodig hebt. 300 threads is geen groot issue, je hebt alleen nogal wat geheugen nodig. Dat is ongeveer een MB per thread. Daarnaast heb je als nadeel dat als threads ook daadwerkelijk veel werk moeten doen het OS veel context switches aan het doen is. Maar in jouw geval zullen de threads het grootste deel van de tijd op data zitten te wachten.

Je kunt altijd later besluiten het om te bouwen als het een idee is, of nu besluiten dat je graag ook async wilt kunnen en het nu doen. Dat is verder aan jou.

Tja, wees maar niet bang, het is niet alsof ik jullie het werk laat doen en zelf achterover zit zonder m'n hersens erover te breken Bovendien ben je van me af zodra dit opgelost is. (Naja, misschien kom ik een probleem tegen met de GUI, maar dat topic mag je dan mijden )

Ik probeer vooral aan te geven dat we hier liever proberen iemand zelf het denkproces te laten doorlopen dan dat we voorgekauwde antwoorden / oplossingen geven. Dat laatste leer je namelijk niet zo veel van.