Hej på er! Mitt förslag är att spara ner allt mottaget data i en kö av något slag. Låt sedan en annan tråd än Udp-tråden ligga och plocka meddelanden från kön i sin egen takt. Då kan du sänka prion på den tråd som behandlar meddelanden så att den (teoretiskt) inte tar resurser av Udp-tråden. Problemet är bara att min server applikation, behöver agera så fort som möjligt på den inkommna datan då diverse olika sakers styrs beroende på den inkommna datan. Så jag behöver processa den när den kommer in. Frågan är bara hur man löser detta på bärsta sätt? Om det är viktigare att processa meddelanden så fort som möjligt än att få alla meddelanden så tycker jag att du ska processa på samma tråd som du tar emot meddelanden. Så att det blir sekvensiellt. Tack för svaret Johan, alltid bra med feedback och förslag på lösningar :) Om du har en mellanlandning i en queue så kan du t.ex. enkelt lägga till prioritet, eller se till att bara x antal processningar får köras samtidigt. Den möjligheten har du inte om du slänger direkt i threadpool. Dit inlägg väckte två frågor hos mig: Vad applikationen gör är att den samlar ihop mätdata från diverse klienter, baserat på datan som kommer in styr applikation olika förlopp. Jag skulle inte vilja kalla det realtidapp kanske, men givetvis är så bra prestanda och så låga svarstider som möjligt önskvärt. Applikationen fungerar i dagsläget, men då jag märkt att jag tappat en hel del meddelanden fick det mig givetvis att börja fundera över en bättre lösning. Det känns inte som att den lösning jag använder i dagsläget med att köra alla algoritmer och beräkningar från samma tråd som tar emot Udp data är optimalt, så därför kom tanken med att köra algoritmerna och processandet på en threadpool istället, vad tror ni om detta?, kommer det medföra bättre prestanda då UDP tråden kommer att bli mera avlsatad?, kanske är en Queue ett bra alternativ det oxå? Jag skulle troligtvis gjort ungefär så här: "Bara för att man har mer spadar så går det inte fortare att gräva." Rent hypotetiskt skulle det gå snabbare om: Så i detta fallet tycker jag tre trådar är överdrift. Nej, men å andra sidan har jag ingen aning om vad som görs med datan.Udp socket med recive thread.
Har ett par funderingar/tankar angående en applikation som hanterar UDP kommunikation som jag skulle behöva ha lite tips och svar angående. Jag börjar med att beskriva applikationen och dess omgiving.
Systemet består av ett 15-tal hårdvaru klienter i ett ethernet nätverk som kommunicarar via UDP till en central server där min .NET 2.0 applikation körs. Klienterna har till uppgift att läsa in infromation från omgivningen och i sin tur skicka data strängar till server applikationen. Ca 7st strängar /sek från varje klient. Detta innebär alltså att jag igenomsnitt får in ca 100 st datasträngar/sek till min udp socket i server programmet. Dessa datasträngar tas emot, verifieraras, och analyseraras. Där efter görs medelvärdesberäkningar och diverse andra processer körs beroende på resultat.
Klassen som hanterar UDP kommunikationen innehåller en Thread som konternuerligt ligger och tar emot data på en specifik UDP port. Jag har fått känslan av att jag tappar en hel del data från klienterna. Jag vet att UDP inte är ett säkert protokoll vad gäller leverans av meddelande, men det känns som tok för mycket trafik faller bort. I dagsläget startas och körs analys och bearbetnings processerna på den thread som oxå tar emot udp datan, den gör alltså detta utan att starta någon nya tråd för dessa processer. Vad jag tror händer är att dessa processer då tar för mycket tid av min UDP thread, som inte hinner med att ta emot alla inkommande datasträngar. Ett förslag vore att starta alla analyser och bearbetnings processer på en Thread pool, som gör att dessa rutiner startas från min UDP Thread men sedan körs på fristående threads. Detta borde göra att min udp recive thread får tid att hantera de meddelande som kommer in, men då kanske någon annan problematik uppstår?
Är det någon som har några tips hur man löser ett sådant här senario på bästa sätt?, andra råd och tips?
Tack på förhand
JohanSv: Udp socket med recive thread.
/johan/Sv:Udp socket med recive thread.
Sv: Udp socket med recive thread.
Om det är viktigare att processa många meddelanden tycker jag du ska trycka ner meddelandena i en kö (tex en System.Collection.Generic.Queue<>) och ha en tråd som kollar och processar kön hela tiden.
Om du kollar kön i en loop kommer det inte bli många millisekunder i fördröjning innan du tagit hand om respektive meddelande. Om det är 'dyrt' att processa ett meddelande kan du använda trådpoolen för själva processandet.
Jag tror inte at Queue är trådsäker så tänk på att lägga Enqueue/Dequeue -operationer inom ett lock-block.
/johan/Sv:Udp socket med recive thread.
Är dock inte riktigt med på vad skillnaden blir i de två följande exemplen, det första exemplet är som du beskrev det och det andra som jag funderade över i mitt första inlägg. Är dock ingen Thread expert.
1. Vid inkommen datasträng köa strängen i en queue, denna queue har sedan en egen tillägnad tråd som har till uppgift att plocka ur meddelandena, för att processa dem på threadpool.
2. Vid inkommen datasträng starta processa meddelandet på threadpool.
Vad vinner man på att lägga den inkommna datan i en Queue och sedan processa dem i en threadpool, än att processa dem direkt i en threadpool. Då threadpoolen ändå är skiljd från min UDP thread och får sina egen 'time slice' ?
Finns det fler personer där ute som har någon bra lösning på detta problem ?, förslag tas mer än gärna emot.Sv: Udp socket med recive thread.
Sv: Udp socket med recive thread.
Det låter som om du beskriver en realtids applikation. JAg undrar hur lämpligt windows och .net plattformen är för att utveckla realtidsapplikationer?
Hur skulle det påverka att använda en port för varje klient.
Skulle det kunna reducera förluster?Sv:Udp socket med recive thread.
Jag har tyvärr inte kontroll över klienterna (utvecklas inte av mig) och de kommunicarar alla på samma port, så att ändra port är tyvärr inget alternativ. Därför måste jag använda endast en UDP tråd i min applikation som är bunden till denna port och där kolla avsändarens ip för att få identited på meddelandet.Sv: Udp socket med recive thread.
Klient -> UDPmsg -> Port -> (A:Tråd som tar emot data) -> Queue -> (B:Tråd hämtar data från kön) -> (C:Tråd/trådar som behandlar data).
A har som enda uppgift att ta emot inkommande data på angiven port och utan stoppa in informationen i en kö, kön kan lösas på olika sätt.
B Ligger och bevakar kön, om data finns i kön och någon C-tråd "ledig" så hämtar B data från kön och skickar det till C(n) för bearbetning. B startar det antal C-trådar som behövs.
C kan vara en eller flera trådar som har till uppgift att behandla data. Om behandlingen av varje data tar längre tid än själva mottagandet, A och B, så kan du ju skapa flera C-trådar och på så vis få en parallell behandling av datat.
Alternativt kan du skippa B och skapa ett antal C-trådar som alla själva bevakar kön. Så fort en C-tråd är "ledig" kollar den om det finns något i kön och hämtar i så fall första datat från kön för behandling.Sv:Udp socket med recive thread.
Citat från en lärare.
I detta fallet rör det sig om user level trådar.
Behövs det verkligen mer än två trådar?
Vad tjänar man på att ha tre trådar?
Den tråd som läser från kön kan väl även behandla data.Sv: Udp socket med recive thread.
a) uppgiften som ska göras kan tänkas vänta på någonting annat (ex. en fil, nätverk etc.)
eller
b) smp (flera fysiska trådar mao)Sv:Udp socket med recive thread.
Eller kan du konkret se någon vinst som jag missar?Sv: Udp socket med recive thread.