[C#] UdpClient workaround ?

[Verwijderd]

Aloa,

Sinds een paar dagen ben ik bezig met een applicatie in C#, dat gebruik maakt van Udp. Het was de bedoeling dat mijn applicatie een datagram zou versturen, en de response zou opvangen, zodat ik er vervolgens verder wat onzinnigs mee zou kunnen doen.
Het sturen van de datagram ging perfect, ook het ontvangen van de response van de server werkte, tenminste, dat dacht ik.
Na een ander datagram te versturen, waar ik als response meerdere packets zou moeten krijgen, ging het mis: ik kreeg alleen het eerste packet binnen.
Een oplossing zou kunnen zijn: 'vang' X aantal packets op, maar dat zal alleen werken wanneer je weet hoeveel packets je moet terugkrijgen, en niet wanneer je een dynamisch aantal packets krijgt.
En nu dat laatste dus toch bij mij het geval is, ben ik eigelijk wel benieuwd hoe andere mensen een workaround voor dit probleem/deze bug hebben gevonden.
Zelf heb ik nu gekozen voor Threads die wachten op de response. Vervolgens kill ik de thread na X ms, en geef een foutmelding.
Een echt nette oplossing vind ik het niet, maar goed

[Orphix]

Is dat niet het hele idee achter UDP?
Als je zekerheid wilt over de connectie moet je TCP nemen. UDP is meer bedoeld om een zooi packets te sturen en het maakt niet zoveel uit als er een paar niet aankomen (bijvoorbeeld bij quake over internet)

[Verwijderd]

Maar wel voor als je iets maakt dat informatie van een server moet verkrijgen (gamespy-like). En aangezien HL per speler een packet stuurt, is het wel zo fijn dat je zeker weet dat je alle packets hebt

btw, dit kan ook niet via TCP

[Stephan Oudmaijer]

ik weet niet hoe et in c# zit, maar je moet lijkt mij lezen totdat de server de connectie sluit dus de input wordt EOF of null. Nu lees je waarschijnlijk totdat er geen paketten meer zijn. Je applicatie is meestal super snel met lezen, sneller dan de server paketten stuurt, je thread stop omdat er niets meer te lezen is maar er komen nog wel paketten maar later. tenminste zo ging het bij mij in java mis

hoop dat je er wat aan heb, suk6

[Verwijderd]

Heh, Udp is juist 'connectionless' wat inhoudt dat er geen connectie is met de server zegmaar...
De receive method van een udpclient wacht op response en blocked de rest van je applicatie totdat 'ie zn zin heeft'.
Ik denk dat het alleen maar mogelijk is om gebruik te maken van Threads in dit geval, icm een timeout semantic.. Wanneer je een timeout constateerd, sluit je de UdpClient en zal de thread ook niet meer kunnen lezen als het ware, wat als gevolg heeft dat je de thread kunt killen.

[Soultaker]

Ik denk dat in dit soort situaties altijd met een timeout gewerkt wordt. Na het versturen van 'n packet wacht je dan dus een seconde of twee en daarna verwerk je alle binnengekomen data tot de socket buffer leeg is.

Hoe dat specifiek in C# moet, weet ik niet. Je moet in ieder geval gegevens zo kunnen uitlezen, dat je OS niet 'blocked' (wacht op invoer) zodra de buffer leeg is.

In sommige situaties zul je de pakketjes willen verwerken zodra ze binnenkomen (en dus niet eerst wachten om ze vervolgens allemaal tegelijk te verwerken), bijvoorbeeld als je een ping-tijd wilt weergeven. Dan zul je op een of andere manier moeten zorgen dat je met een timeout kunt ontvangen. Traditioneel gaat dat met 'n select-call, maar nogmaals, dat kan per OS verschillen.

In elk geval verdient een goede single-threaded oplossing de voorkeur boven 'n multi-threaded optie, vanwege de extra overhead en complexiteit van je programma die je op die manier introduceert.