---

Jeg roder lidt med et lille program til overførsel af filer....jeg bruger
winsock control 6.0 til at sende / modtage vha. TCP protocollen......

Jeg får et sært problem når filen er sendt fra pc til pc.......filerne er
tilsyneladende identiske på de 2 pc'ere ( præcis str i bytes ) men ved
bit to bit sammenligning er der store dele af filen på modtager der er
"korrupt"............jeg sender i blokke på 2048 bytes !!

Hvad kan det skyldes !!
Hvordan kommer der snavs i modtager filen

---

Steen Gellett skrev:
> Jeg får et sært problem når filen er sendt fra pc til pc.......filerne er
> tilsyneladende identiske på de 2 pc'ere ( præcis str i bytes ) men ved
> bit to bit sammenligning er der store dele af filen på modtager der er
> "korrupt"............jeg sender i blokke på 2048 bytes !!

Hvordan sender/modtager du og hvordan sammenligner du?
Den teoretiske risiko for fejl, når du bruger TCP (modsat UDP) er ufattelig
lille.

-------
Tomas

---

"Tomas Christiansen" <toc-01-nospam@blikroer.dk> skrev i en meddelelse
news:c0ttc0$1fbv$1@news.cybercity.dk...
> Steen Gellett skrev:
> > Jeg får et sært problem når filen er sendt fra pc til pc.......filerne
er
> > tilsyneladende identiske på de 2 pc'ere ( præcis str i bytes ) men ved
> > bit to bit sammenligning er der store dele af filen på modtager der er
> > "korrupt"............jeg sender i blokke på 2048 bytes !!
>
> Hvordan sender/modtager du og hvordan sammenligner du?
> Den teoretiske risiko for fejl, når du bruger TCP (modsat UDP) er
ufattelig
> lille.

Jeg bruger WindowsCommander til at sammeligne med :
Her er min send kode

FileNumber = FreeFile
Dim Read As String
Read = Space(2048)
Open lblSendFil.Caption For Binary As #FileNumber
Do Until EOF(FileNumber)
DoEvents
PacketWait = True
Get #FileNumber, , Read
TcpServer.SendData Read
Do
DoEvents
Loop Until PacketWait = False
PacketWait = True
Loop
Close #FileNumber

Her er min modtager kode

(filen til modtagelse er åbnet andet sted fra)

TcpServer.GetData NewArrival
DataTotal = DataTotal + Len(NewArrival)
If DataTotal >= FileIndSize Then
DoEvents
Put #FileNumber, , CStr(Left(NewArrival, Len(NewArrival) -
(DataTotal - FileIndSize)))
FileInd = False
Close #FileNumber
Else
DoEvents
Put #FileNumber, , CStr(NewArrival)
End If





>
> -------
> Tomas
>

---

Steen Gellett skrev:
> Dim Read As String
....
> Open lblSendFil.Caption For Binary As #FileNumber
....
> Get #FileNumber, , Read
> TcpServer.SendData Read

Rent principielt er det noget rod at lægge binære data i en streng. Husk på
at VB arbejde med Unicode strenge, som f.eks. ved afsendelse via
Winsock-kontrollen bliver konverteret til det som Microsoft kalder ANSI.
Brug byte-arrays til binære data!

> TcpServer.GetData NewArrival
> DataTotal = DataTotal + Len(NewArrival)
> If DataTotal >= FileIndSize Then
> DoEvents

Hvorfor DoEvents her?

> Put #FileNumber, , CStr(Left(NewArrival, Len(NewArrival) -
> (DataTotal - FileIndSize)))

Hvad gør du med resten af de modtagne data?
Hvorfor prøver du at konvertere resultatet af funktionen Left til en streng?

> Else
> DoEvents

Hvorfor DoEvents her?

> Put #FileNumber, , CStr(NewArrival)

Hvilken datatype er NewArrival siden du prøver på at konvertere til en
streng?

-------
Tomas

---

"Tomas Christiansen" <toc-01-nospam@blikroer.dk> skrev i en meddelelse
news:c0u3ao$1m8t$1@news.cybercity.dk...
> Steen Gellett skrev:
> > Dim Read As String
> ...
> > Open lblSendFil.Caption For Binary As #FileNumber
> ...
> > Get #FileNumber, , Read
> > TcpServer.SendData Read
>
> Rent principielt er det noget rod at lægge binære data i en streng. Husk
på
> at VB arbejde med Unicode strenge, som f.eks. ved afsendelse via
> Winsock-kontrollen bliver konverteret til det som Microsoft kalder ANSI.
> Brug byte-arrays til binære data!
>
> > TcpServer.GetData NewArrival
> > DataTotal = DataTotal + Len(NewArrival)
> > If DataTotal >= FileIndSize Then
> > DoEvents
>
> Hvorfor DoEvents her?
>
> > Put #FileNumber, , CStr(Left(NewArrival, Len(NewArrival) -
> > (DataTotal - FileIndSize)))
>
> Hvad gør du med resten af de modtagne data?

Den linie gør at når den har hentet de sidste 2048 bytes så bliver kun det
den
skal bruge gemt..............ellers vil fil størrlesen jo blive ukorrrekt

> Hvorfor prøver du at konvertere resultatet af funktionen Left til en
streng?

Kun for at teste om det måske var her der kommer snavs ind.....men det
skader vel ikke ??

>
> > Else
> > DoEvents
>
> Hvorfor DoEvents her?

Igen forsøg.........jeg er desperat

>
> > Put #FileNumber, , CStr(NewArrival)
Her er resten af de modtagne data.........det er HELE 2048 bytes strings som
kommer ind
i en lind strøm...................indtil den når slutningen.......som du så
længere oppe


>
> Hvilken datatype er NewArrival siden du prøver på at konvertere til en
> streng?

NewArrival ER en string iforvejen.................som sagt jeg har prøvet
for at se om det hjalp,
men igen at konvertere fra string til string skader vel ikke ??




>
> -------
> Tomas
>

---

Steen Gellett skrev:
> Den linie gør at når den har hentet de sidste 2048 bytes så bliver kun det
> den skal bruge gemt..............ellers vil fil størrlesen jo blive
ukorrrekt

Nå, ja. Nu går det op for mig at du tror at du modtager data i blokke af
2048 bytes, men det gør du med rimelig stor sandsynlighed ikke!

Det som går galt for dig er, at du modtager måske 1500 bytes data og hælder
dem ned i en streng som kan indholde 2048 tegn (og som fylder 4096 bytes) og
så forventer du at systemet på magisk vis skal finde ud af hvad de restende
548 bytes skal indeholde - selvom de måske ikke er modtaget endnu!

Du skal tænke på en TCP-forbindelse som én lang strøm af bytes, som sendes
efter hinanden én efter én.

At du forsøger at sende i blokke af X bytes betyder overhovedet ikke at
modtageren modtager modtager data i de samme blokke, men bytes'ne modtages
altid i samme rækkefølge.

For det første overfører dit netværk formentlig ikke mere end 1500 bytes ad
gangen, og hvis dit netværk er routed, kan pakkerne blive yderligere
fragmenterede.

Men du skal også være ligeglad. Du skal modtage nøjagtig de data du
modtager - hverken mere eller mindre!

I din DataArrival event-procedure får du at vide hvor mange data, som ligger
i en buffer og venter på at blive behandlet (bytesTotal). Det kan være data
fra én eller fra flere netværkspakker, som er samlet i én og samme buffer.
Det ligger udenfor din kontrol.

-------
Tomas

---

"Tomas Christiansen" <toc-01-nospam@blikroer.dk> skrev i en meddelelse
news:c10tal$19id$1@news.cybercity.dk...
> Steen Gellett skrev:
> > Den linie gør at når den har hentet de sidste 2048 bytes så bliver kun
det
> > den skal bruge gemt..............ellers vil fil størrlesen jo blive
> ukorrrekt
>
> Nå, ja. Nu går det op for mig at du tror at du modtager data i blokke af
> 2048 bytes, men det gør du med rimelig stor sandsynlighed ikke!

Jeps....imellemtiden har jeg rodet med det, og lavet noget LEN statistic på
min indkomne data.............og du har helt ret..........det svinger
imellem ca 600 og 1500 i LEN..........ikke 2048 som jeg troede......


> Det som går galt for dig er, at du modtager måske 1500 bytes data og
hælder
> dem ned i en streng som kan indholde 2048 tegn (og som fylder 4096 bytes)
og
> så forventer du at systemet på magisk vis skal finde ud af hvad de
restende
> 548 bytes skal indeholde - selvom de måske ikke er modtaget endnu!
>
> Du skal tænke på en TCP-forbindelse som én lang strøm af bytes, som sendes
> efter hinanden én efter én.
>
> At du forsøger at sende i blokke af X bytes betyder overhovedet ikke at
> modtageren modtager modtager data i de samme blokke, men bytes'ne modtages
> altid i samme rækkefølge.
>
> For det første overfører dit netværk formentlig ikke mere end 1500 bytes
ad
> gangen, og hvis dit netværk er routed, kan pakkerne blive yderligere
> fragmenterede.
>
> Men du skal også være ligeglad. Du skal modtage nøjagtig de data du
> modtager - hverken mere eller mindre!
>
> I din DataArrival event-procedure får du at vide hvor mange data, som
ligger
> i en buffer og venter på at blive behandlet (bytesTotal). Det kan være
data
> fra én eller fra flere netværkspakker, som er samlet i én og samme buffer.
> Det ligger udenfor din kontrol.

Jeg har løst problemet ved at lægge kontrollen af bytes over i AFSEND
istedet
for i MODTAG..........så nu er det min TCP.SendData der styrer at der kun
kommer
det rigtige antal bytes afsted.........min modtager "æder" så bare alt hvad
der kommer ind !!

Jeg fandt bla. andet ud af det ved at se hvordan de "korrupte" data så
ud..........og det viste sig
at det var fragmenter af SAMME fil som den gentog hulter til
bulter..........præcis som du skriver...
den lagde de korrupe data ind efter de modtagne bytes ca 1500... ergo blev
ca 548 bytes gentaget
gang på gang !!!!

Så blev man så klog..............tak for hjælpen

>
> -------
> Tomas
>

---

Steen Gellett skrev:
> Så blev man så klog..............tak for hjælpen

Det glæder mig at du fik løst problemet.
Men husk at når du vil overføre binære data med Winsock kontrollen bør du
altid bruge bytearrays - dvs. noget med Dim X() As Byte. Du kan ikke være
sikker på at alt går godt, når du bruger strings!

-------
Tomas