Moro,
Olen tuossa väkästellyt ohjelmaa, jolla käyrän plottaukseen tarvittavia pisteitä siirretään UDP:llä verkon yli. Kun lähetysnopeus nousee riittävän suureksi tapahtuu vastaanottopäässä jotain veikeää ja socketti menee "tukkoon" ts. recvfrom ei saa luettua socketista dataa, mutta ei myöskään palauta mitään virhettä ja jää blokkaamaan (ikuisesti). Jos lähetysnopeutta pienentää, tapahtuu socketissa jonkin sortin timeout (n. 80 sekunnin päästä) ja vastaanotto jatkuu normaalisti.
Osaisiko jojku sanoa, mitä tuossa tapahtuu, eli miksi socketti jumiutuu ja miten siihen voisi vastaanottopäässä reagoida? Jumin tapahtuessa dataa liikku ~4-5 megatavua sekunnissa 100Mbit/s lähiverkossa.
Kiitokset vastauksista!
Olen tuossa väkästellyt ohjelmaa, jolla käyrän plottaukseen tarvittavia pisteitä siirretään UDP:llä verkon yli. Kun lähetysnopeus nousee riittävän suureksi tapahtuu vastaanottopäässä jotain veikeää ja socketti menee "tukkoon" ts. recvfrom ei saa luettua socketista dataa, mutta ei myöskään palauta mitään virhettä ja jää blokkaamaan (ikuisesti). Jos lähetysnopeutta pienentää, tapahtuu socketissa jonkin sortin timeout (n. 80 sekunnin päästä) ja vastaanotto jatkuu normaalisti.
Osaisiko jojku sanoa, mitä tuossa tapahtuu, eli miksi socketti jumiutuu ja miten siihen voisi vastaanottopäässä reagoida? Jumin tapahtuessa dataa liikku ~4-5 megatavua sekunnissa 100Mbit/s lähiverkossa.
Kiitokset vastauksista!
Vastaukset 5
Vanhimmat
Kahden 100Mbs noden välillä pitäis saada joku 11- ~12 MB liikkumaan sekunnissa hyvissä olosuhteissa.
Saisko sinne vastaanottopäähän jotain debuggeria tai vaikka printtais jotain tekstiä konsoliin? Näkis sen kohdan mihin se aina jumii.
Joo, tuo teoreettinen nopeus on varmasti jotain tuollaista.
Ohjelmahan ei sinänsä jää jumiin mitenkään, vaan recvfrom funktio alkaa jostain syystä blokkaamaan vastaanottopäässä (aivan kuten silloin, kun socketin vstaanottopuskurissa ei ole mitään luettavaa).
Olen tarkastanut kaikki winsock-funktioiden kutsujen paluuarvot (ja ovat ok) sekä yrittänyt kasvattaa SO_RCVBUF kokoa ilman tulosta. Lisäksi tarkistan SO_ERROR:in arvon vastaanotto-loopin sisällä, jos vaikka socketti menisi rikki, mutta nollaa pukkaa sieltäkin.
Eli paperilla sekä lähetys että vastaanottopäässä kaikki menee putkeen, mutta käytänössä sitten ei. :/
tai palomuuria, verkkokortin ajuria yms. softia. Koita muuttaa keskeytystiheyttä ajurin asetuksista. Eihän kumpikaan kone ole muuten kannettava...? Koita debugata ubuntun livecd:llä ja netcatilla (nc) udp-tilassa.
Jotain mietteitä...
Oletko katsonut "netstat -s" komennolla mitä UDP ja IP tilastot näyttävät, tai "netstat -e" komennolla mitä ethernet tilastot näyttävät. Eli kasvaako vastaanotettujen datagramminen tai virheiden määrä, jne. Eli mille tasolle paketit tuossa jumiutuneessa tilanteessa jäävät?
Ilmeisesti kun puskuri menee yli tai lähes täyteen, ei ajuri enää pysty vastaanottamaan yhtä kokonaista datagrammia, josta johtuen se alkaa hylätä pirstoutuneita datagrammeja virheellisinä, josta sitten seuraa se "jumiutuminen" koska ei ole mitään mitä vastaanottaa.
Voiko olla mahdollista, että kysymyksessä on lähetys pään ongelma? Jos kysymyksessä lähetyspään ongelmasta, eikä ole XP tai ME, niin silloin voi olla kyseessä:
http://support.microsoft.com/kb/233401
Voi olla että suuri määrä paketteja vaikka niiden koko on pieni aihetaa jonkin sortin ongelman alatasolla.
Lähetätkö kerralla useamman pisteen tiedot vai ainoastaan yhden pisteen tiedot ? kokeile kasvataa pakettikokoa.
Jos on mahdollista toteuta mini vastaanotto vaikka pythonilla, ja katso jumitaako se. Jolloin tiedät onko ongelma ajuritasolla (ajurit päivitetty ?) vai omassa koodissa.