[C#] DataReader totale lengte van een row

[Verwijderd]

voor een projectje moet ik weten wat de totale lengte van een row is welke ik via een Datareader van een mssql server terug krijg. maar moet de totale lengte weten voor dat ik wat met de data ga doen (word via tcp verzonden en moet meerdere rows combineren in 1 pakketje)

dit kan ik doen via bv

in de query's elke keer onderstaande toe tevoegen

code:

ISNULL(datalength(veld0),0)+
ISNULL(datalength(veld1),0) enz

maar vind dat geen super oplossing

2x door de data heenlopen 1x om te kijken of het nog wel past.. is erg lelijke oplossing.

heb msdn al na gespit maar kan nergens een property vinden van de DataReader waarin de huidige grootte staat.

iemand een idee. of zijn er alleen maar minder mooie oplossingen

[RobIII]

Ik zie even niet waarom het "in 1 pakketje" zou moeten

[Verwijderd]

RobIII schreef op zaterdag 06 maart 2010 @ 22:59:
Ik zie even niet waarom het "in 1 pakketje" zou moeten

het "in 1 pakketje" is er voor dat er minder pakketten heen en weer gestuurd worden tussen de server en het apparaat wat er mee verbonden is. en de buffer in dat apparaat is gelimiteerd op 1500 bytes.

dus wil zoveel mogelijk in 1x verzenden.

[RobIII]

Dan laat je dat toch over aan je IP stack? Je zou nog wat compressie toe kunnen voegen, maar als x-bytes aan data verzonden moet worden dan moet x-bytes aan data verzonden worden. Of dat in 10 pakketjes van 500 bytes gebeurt of 5 pakketjes van 1000 bytes boeit toch niet? Net zo min als het boeit dat een "datarow" in 2-en gehakt zou worden en verdeeld over 2 pakketjes verzonden zou worden. Ik zie het hele probleem niet. Laat het over aan je IP stack en laat die er zich over druk maken. Wat roest het je applicatie hoe groot de buffer aan de andere kant is? Daar is de MTU (o.a.) voor. En daarbij is 1500 bytes helemaal niet gek; het is zelfs de ethernet standaard (max) grootte.

[ Voor 21% gewijzigd door RobIII op 06-03-2010 23:41 ]

[Verwijderd]

de totale lengte van alle date in de datarow is altijd kleiner dan 1500 bytes. kan goed zijn dat er 10 pakketten van 100bytes er naar toe moeten. dus vul die buffer dan maximaal

op de MTU is die buffer grootte ook op uitgezocht. maar het apparaat verbind zich via een gprs verbinding
waarvan de verbinding niet altijd super is. bij verschillende providers blijft een verbinding openstaan terwijl het apparaat uitgezet kan zijn in de tussen tijd. het verzonden pakket verdwijnt dan in een "zwart gat" zonder dat
er een fout met het schrijven tcp verbinding onstaat.

en daarom zit er nog een bevestings protocol bij tussen welke elk pakket bevestigd. en het protocol moet compatibel zijn met een apparaat dat maar totaal 4k sram heeft.

enja in theorie zou dit niet mogen kunnen maar het gebeurd wel dat die pakketten gewoon verdwijnen in het niets..

[RobIII]

Verwijderd schreef op zaterdag 06 maart 2010 @ 23:56:
de totale lengte van alle date in de datarow is altijd kleiner dan 1500 bytes. kan goed zijn dat er 10 pakketten van 100bytes er naar toe moeten. dus vul die buffer dan maximaal

Dan kap je de data toch gewoon in pakketten van 1500 bytes? Gewoon 1500 bytes vullen (stel dat je dan op 2 rows + nog wat data van row 3 zit) en een nieuw pakket vullen. Maar again: dat doet je IP stack normaliter gewoon voor je. Feitelijk kun je alle data (rows, velden) appenden aan een byte-array en die byte-array gaan verzenden in 1500-bytes grote blokken. Voor het netwerk is het niet interessent waar rows of verlden ophouden of beginnen. Dat is iets voor je applicatielaag.

Verwijderd schreef op zaterdag 06 maart 2010 @ 23:56:
het verzonden pakket verdwijnt dan in een "zwart gat" zonder dat er een fout met het schrijven tcp verbinding onstaat.

Dat is wel heel vaag; wat voor apparaat is het en wat draait er voor OS/IP stack op dan? Want TCP garandeert nou nét juist dat data afgeleverd is (of dat je weet dat het niet lukt(e)).

Verwijderd schreef op zaterdag 06 maart 2010 @ 23:56:
en daarom zit er nog een bevestings protocol bij tussen welke elk pakket bevestigd

Dat is gewoon dubbelop en (IMHO) in 9 v.d. 10 gevallen onzinnig of overbodig.

Verwijderd schreef op zaterdag 06 maart 2010 @ 23:56:
en het protocol moet compatibel zijn met een apparaat dat maar totaal 4k sram heeft.

Dan wil je neem ik aan juist geen extra "bevestigingsprotocol" (=extra overhead) hebben.

Verwijderd schreef op zaterdag 06 maart 2010 @ 23:56:
enja in theorie zou dit niet mogen kunnen maar het gebeurd wel dat die pakketten gewoon verdwijnen in het niets..

Dan zou ik eerst eens gaan uitzoeken hoe dat komt. Het probleem lijkt me eerder (op gut feel) in je "bevestigingsprotocol" te zitten dan in het eeuwenoude, goeie ouwe betrouwbare, TCP protocol.

[ Voor 9% gewijzigd door RobIII op 07-03-2010 00:08 ]

[Verwijderd]

Dat is wel heel vaag; wat voor apparaat is het en wat draait er voor OS/IP stack op dan? Want TCP garandeert nou nét juist dat data afgeleverd is (of dat je weet dat het niet lukt(e)).

dat heb ik ook altijd lopen beweren tegen collega's wie dit ook ondervonden dat pakketjes verdwenen
dat dit niet kon. maar ben er achter dat dit dus helaas wel kan.


os 1 apparaat is windows CE. andere is eigen software op een atmega.

wij verwachten dat het verdwijnen van die pakketten in het niets door de telecom providers komt. de providers hebben veel dingen beperkt. welke dan weer door het aanvragen van product codes weer word opengezet

Dan zou ik eerst eens gaan uitzoeken hoe dat komt. Het probleem lijkt me eerder (op gut feel) in je "bevestigingsprotocol" te zitten dan in het eeuwenoude, goeie ouwe betrouwbare, TCP protocol.

het afluisteren van verbindingen door bv etherreal ed laat echt zien dat die pakketten worden verstuurd naar een open verbinding via gprs van een apparaat wat net uit staat.

dit probleem doet zich niet voor binnen een bedraad netwerk.

[ Voor 25% gewijzigd door Verwijderd op 07-03-2010 00:38 ]

[RobIII]

Verwijderd schreef op zondag 07 maart 2010 @ 00:35:
wij verwachten dat het verdwijnen van die pakketten in het niets door de telecom providers komt. de providers hebben veel dingen beperkt. welke dan weer door het aanvragen van product codes weer word opengezet

Los van wat providers zouden doen: TCP verwacht gewoon een ACK op een verzonden pakketje. Komt die ACK nooit dan krijg je een timeout op dat pakket en wordt het alsnog nog een keer verzonden door je IP stack. Daar merkt/ziet je applicatielaag niets van in eerste instantie.
Ik neig toch heel sterk naar de "eigen software" en dat daar een probleem in zit.

Verwijderd schreef op zondag 07 maart 2010 @ 00:35:
het afluisteren van verbindingen door bv etherreal ed laat echt zien dat die pakketten worden verstuurd naar een open verbinding via gprs van een apparaat wat net uit staat.

Ik volg het effe niet: als een apparaat uit staat heeft heel het "bevestigingsprotocol" (noch überhaupt een netwerkverbinding) toch geen nut De verbinding is er immers niet. En wiedes dat die pakketten dan in het niets verdwijnen. Waar moeten ze anders naar toe, de pakkethemel? En hoe valt dit samen met je topicstart waar het gaat over buffers, datarows en pakketsizes van 1500 bytes

Zoals ik eerder zei: pak een buffer van 1500bytes, vul die tot aan de rand met data, geef 'm een schop naar de overkant en vul de volgende buffer. Het boeit geen zak of je halverwege een "row" of "field" een buffer een schop zou moeten geven, die row construct je aan de andere kant toch weer door de ontvangen data aan elkaar te plakken. Dus het is ook niet interessant om de "totale lengte van een row" vooraf te bepalen ofzo. Het moet toch naar de overkant. Waarom je complete rows "in 1 pakketje" zou willen verzenden is mij een raadsel.

[ Voor 50% gewijzigd door RobIII op 07-03-2010 00:53 ]

[Gomez12]

Tja wat verloren pakketjes betreft.

In het (verre) verleden heb ik redelijk vaak meegemaakt dat een provider dingen ging bundelen en overging naar short-bursts op het eigen mobiele netwerk.
Dan kreeg je een ACK terug van het device bij de provider wat de pakketjes bundelde terwijl ze nog niet verzonden/ontvangen waren aan de device kant...

Lijkt me dat een beetje provider dit tegenwoordig wel op orde heeft, dit was allemaal nog met radiogolven -> land -> ander land -> radio golven. Maar het kan wel gebeuren...

Persoonlijk zou ik heden ten dage een provider eruit schoppen als ik extra verificatie lagen bovenop TCP moest leggen omdat hij gewoon basisprincipes van huidige netwerken schendt... Dat is niet erg zolang het niet relevant is, maar als je in de problemen komt dan wegwezen

Voorbeeldje wat ik me bijv net bedenk is dat een NAT-router dit soort grappen ook best zou kunnen uithalen ( ken de hele theorie van NAT niet ). Het interne apparaat bestaat niet voor de buitenwereld dus buitenwereld stuurt alles naar de NAT-device, deze zou volgens mij best een ACK kunnen retourneren...

[ Voor 22% gewijzigd door Gomez12 op 07-03-2010 01:35 ]

[MrBucket]

Verwijderd schreef op zaterdag 06 maart 2010 @ 23:56:
de totale lengte van alle date in de datarow is altijd kleiner dan 1500 bytes. kan goed zijn dat er 10 pakketten van 100bytes er naar toe moeten. dus vul die buffer dan maximaal

Vooropgesteld dat je niet ook nog wil garanderen dat er alleen gehele datarows in je pakketje terecht komen, zou ik je aanraden om gewoon een BufferedStream om je TCP connectie heen te gebruiken. Die zorgt er dan wel voor dat je met elk pakketje maximale data verstuurt.

Snel, safe, simpel

[Remus]

RobIII schreef op zondag 07 maart 2010 @ 00:38:
[...]
Zoals ik eerder zei: pak een buffer van 1500bytes, vul die tot aan de rand met data, geef 'm een schop naar de overkant en vul de volgende buffer. Het boeit geen zak of je halverwege een "row" of "field" een buffer een schop zou moeten geven, die row construct je aan de andere kant toch weer door de ontvangen data aan elkaar te plakken. Dus het is ook niet interessant om de "totale lengte van een row" vooraf te bepalen ofzo. Het moet toch naar de overkant. Waarom je complete rows "in 1 pakketje" zou willen verzenden is mij een raadsel.

Ik zou iets minder dan 1500 nemen, aangezien er ook nog TCP/IP headers in die 1500 moeten passen. Heeft GPRS trouwens wel een MTU van 1500?

[RobIII]

Remus schreef op zondag 07 maart 2010 @ 10:25:
Ik zou iets minder dan 1500 nemen, aangezien er ook nog TCP/IP headers in die 1500 moeten passen.

Volgens mij zijn die 1500 bytes de actual (max) payload die in een pakketje passen. Een pakketje kan tot 1538 bytes groot zijn als ik me niet vergis (dus inc. headers etc).

Remus schreef op zondag 07 maart 2010 @ 10:25:
Heeft GPRS trouwens wel een MTU van 1500?

Dat weet ik dan weer niet

[ Voor 8% gewijzigd door RobIII op 07-03-2010 13:31 ]

[EfBe]

Ik begrijp niet echt waarom je niet op de server (zendende) kant alle data in een buffer laadt en die streamt (gepacked). Dat is efficient (Want tcp/ip vult alle pakketjes volledig) en je zit niet op het niveau van een tcp stack te vrotten. Een open datareader vanaf Windows CE (dus compact framework) lijkt me niet echt jofel, want je moet dan een database toegang open stellen aan wireless access. Je kunt beter je handheld contact laten maken met een service die dan je data access verzorgt (en daar dus de datareader opent, data ophaalt, packt en naar de handheld stuurt).

Ook moet je even op de kalender kijken. Het is 2010, niet 1990, dus dat er af en toe een packetje opnieuw moet, ik begrijp niet echt waarom je daarop focused, want neem dan een betere wifi verbinding