[C#] Design probleem UDP server

[Verwijderd]

voor een project ben ik bezig met een udp server.

hierbij komt via een UDP pakket data binnen max (1500bytes) per keer. vanaf ong 200 verschillende devices.
al die devices hebben een aparte database (mysql)
de server zal een belasting hebben van ongeveer 5-20 pakketten per seconde, max 100 in piek momenten.

Bij bv een TCP verbinding laat ik voor elke client connectie een thread aanmaken en hierbinnen word alle data verwerkt. nu komt bij UDP alles binnen via 1 connectie dus moet een andere oplossing bedenken.

nu laat ik de data al asynchroon verwerken, dus de main thread zal niet wachten tot hij klaar is.
hoe zou ik het beste de data kunnen gaan verwerken.

a) elke keer een thread opstarten om de data te verwerken (async doet inpricipe al het zelfde)
maar elke keer de database verbinding leggen lijkt me onhandig / niet snel.

b) een list met classes voor elk device en deze als argument meegeven met de async functie
1x de database verbinding opzetten en deze instand houden.


ik denk zelf dat optie b het beste is
of is een andere methode beter.?


@ H!GHGuY
voor elk device een apparte DB dus momenteel ong 200 databases
de clients maken zelf een verbinding met de server,

het word nu async afgehandeld door de socket zie system.net.sockets.socket.beginreceivefrom

[ Voor 15% gewijzigd door Verwijderd op 14-06-2010 19:52 ]

[Sebazzz]

Methode A aanpassen, je threads laten lopen en de connectie alive laten houden en wanneer er werk binnenkomt dispatchen naar één van je lopende threads. Dus een threadpool maken. Ik geloof niet dat ze standaard .NET threadpool voldoet.

[H!GHGuY]

Ik denk dat een deployment diagram hier wel op z'n plaats is, want wie wat doet is me onduidelijk.

de udp server krijgt binnenkomende trafiek en handelt deze nu reeds async af. (hoe? thread pool, thread per UDP pakket, ...) Wie moet een connectie leggen naar welke database en per welke data eenheid heb je zo'n connectie nodig? Gaat het over 1 DB of meerdere DB's?

Er mist gewoonweg teveel cruciale informatie om ook maar enige aanbevelingen te doen.

[roy-t]

Sebazzz schreef op maandag 14 juni 2010 @ 19:43:
Methode A aanpassen, je threads laten lopen en de connectie alive laten houden en wanneer er werk binnenkomt dispatchen naar één van je lopende threads. Dus een threadpool maken. Ik geloof niet dat ze standaard .NET threadpool voldoet.

Inderdaad, en dit lijkt me ook de beste oplossing. (Heet trouwens gewoon ThreadPool die class).

Anders zou je een soort van pipelining opzet kunnen gebruik met queues waarin packets wachten om afgehandeld te worden door een Thread. Maar deels doet de ThreadPool class dit ook al (je kunt instellen hoeveel maximum threads er worden gemaakt, maar dit regelt de ThreadPool normaliter zelf aan de hand van het systeem waar het op draait).

[pedorus]

Ik denk dat je 'niet' niet hebt gezien.. Het probleem met de ThreadPool is dat deze niet de database-connectie voor je bijhoudt, en steeds een nieuwe connectie per pakketje onnodige overhead geeft. Je kunt dus beter bijvoorbeeld iets met BlockingCollection doen (bij .net 4).

Verder zie ik 2 design-problemen:

• wat doe je bij packet loss?
• waarom heb je in hemelsnaam een aparte database per device?

[roy-t]

pedorus schreef op dinsdag 15 juni 2010 @ 12:03:
Ik denk dat je 'niet' niet hebt gezien.. Het probleem met de ThreadPool is dat deze niet de database-connectie voor je bijhoudt, en steeds een nieuwe connectie per pakketje onnodige overhead geeft. Je kunt dus beter bijvoorbeeld iets met BlockingCollection doen (bij .net 4).

Verder zie ik 2 design-problemen:

• wat doe je bij packet loss?
• waarom heb je in hemelsnaam een aparte database per device?

Dat is onzin, een ThreadPool is gewoon een verzameling threads, de connectie delen tussen die threads kun je helemaal zelf regelen.

[pedorus]

roy-t schreef op dinsdag 15 juni 2010 @ 14:53:
[...]

Dat is onzin, een ThreadPool is gewoon een verzameling threads, de connectie delen tussen die threads kun je helemaal zelf regelen.

Als je de Threads in eigen beheer hebt, dan kun je ze zeer eenvoudig een vaste connectie geven. ThreadPool threads zijn niet in eigen beheer, dus hoe wil je dit gaan doen zonder extra onnodige synchronisatie (in feite een handmatige connection pool)? Verder wil je juist niet de connectie delen tussen meerdere threads, maar elke thread moet zijn eigen connectie krijgen, in ieder geval als het om hetzelfde tijdstip van gebruik gaat.

Overigens is ook het beëindigen van je applicatie lastig met ThreadPool, maar dat is vooral een issue als perse alle taakjes uitgevoerd moeten worden..

Hebben trouwens die 200 databases allemaal een eigen server of niet?

[Sebazzz]

Volgens mij zijn jullie in verwarring met het begrip ThreadPool en de .NET implementatie ervan.

[Verwijderd]

@pedorus die data van die devices mogen absoluut niet bij elkaar in 1 database kunnen van verschillende projecten zijn die echt gescheiden moeten blijven.

packetloss kan optreden, maar het device krijgt een bevestiging vd server dat zijn pakket is aangekomen.
als hij niks ontvangt binnen x seconden stuurt hij het opnieuw.

[ Voor 35% gewijzigd door Verwijderd op 15-06-2010 18:38 ]

[TheNameless]

Een producer/consumer achtige oplossing lijkt mij ook het best

Dus 1 of meerdere threads die "werk" produceren op een threadsafe queue (.NET 4 heeft een nieuwe IProducerConsumerCollection, die lijkt mij daar wel geschikt voor).

En een x aantal "worker" threads die het werk doen (dus opslaan in de database).
Vervolgens kan je ook nog gebruik maken van een connectionpool voor het open houden van connecties naar de database.
Je zal dan wel wat overhead krijgen wat betreft het synchronizeren op de connectionpool, maar 200 connecties en 200 threads open houden lijkt me ook niet bevorderlijk qua overhead

Waarom zou trouwens de ingebouwde ThreadPool niet voldoende zijn?

[SKiLLa]

ThreadPool voldoet prima indien je een Producer-consumer queue/collection gebruikt (en dus niet simpelweg 1:1 thread-per-datapacket gebruikt).