Binary To ASCII?

  • Thread starter Thread starter pbd22
  • Start date Start date
pbd22 said:
Hi Robin,

Yes, that is pretty much all i am trying to do. I have written code on
the client
that reports the amount of bytes being loaded on the server "as it is
being loaded".
This provides the logic for a progress meter on the client. I need to
know when the file size prior transmission equals the amount of bytes
on the remote ftp server for the progress to be completed. I figured
that a byte-to-byte comparrison would be an obvious indicator but i
didn't anticipate this problem.

I will look into your checksum idea, thanks.
Click to expand...
------------------------------

I went and googled "checksum .net" and came up with a bunch of hits, so
hopefully this will help you.

Good luck.
Robin S.
 
------------------------------

I went and googled "checksum .net" and came up with a bunch of hits, so
hopefully this will help you.

Good luck.
Robin S.
Click to expand...

Thanks Robin,

I have come up with the following SHA1 code for VB.NET checksums using
the .NET Cryptography package. I will mess around with this and thanks
again. Also, if anybody out there can come up with a solution for the
byte-by-byte comparrison approach, I would be interested if a solution
is possible.

Thanks again all for your help.

Imports System.IO
Imports System.Security.Cryptography

Private Shared Function GetChecksum(ByVal file As String) As String
Imports (FileStream stream = File.OpenRead(file))
{
Dim sha As SHA256Managed = New SHA256Managed()
Dim checksum() As Byte = sha.ComputeHash(stream)
Return
BitConverter.ToString(checksum).Replace("-",String.Empty)
}
End Function
 
pbd22 said:
This provides the logic for a progress meter on the client. I need to
know when the file size prior transmission equals the amount of bytes
on the remote ftp server for the progress to be completed. I figured
that a byte-to-byte comparrison would be an obvious indicator but i
didn't anticipate this problem.
Click to expand...

Pardon me but it sounds like a different need. The "file" is the same
length in all cases, i.e. if you open the file and check the length both had
better return the same value. The reason one is "larger" is only due to the
space occupied on the drive. The difference could be larger still if 2048
byte blocks were used and (for instance) a file you transmit was 1 byte
longer than an even 2048 block chunk. It will take 2048 bytes of disk space
to write the 1 byte of data. That "data" will not be transmitted if you
then copy the file back because it isn't allocated to the file but rather
allocated to the file system. That space on the drive is occupied but it
doesn't become part of the file.

If you determine prior to transmitting that you have 410,000 bytes to send
then your progress meter need only keep track of the bytes transferred as it
does not change regardless of the block size of the receiving computer.

If you are trying to confirm something afterwards then you have more work
but I'll guess this isn't typically done. And in that case a checksum or
hash value would indicate the file was transmitted correctly.

Hope this helps,
Tom
 
pbd22 said:
Thank you all for your responses. From what I gather from your
responses, it sounds like line breaks or something of that nature may
be causing the difference when the file lands on the FTP server? I did
what was suggested and right-clicked the file (these are video files,
by the way) prior to upload. I did two tests:

client: 4760952
ftp server: 4760439

client: 12444894
ftp server: 12444381

In both (indeed, all) cases, the amount of reported bytes *reduces*
once the file lands on the ftp server and the bytes are counted. In
both of the above cases, by around 500 bytes.

So, then, """how do i adjust for this programatically??""".

I am trying to do something like this in pseudo-code:

if the amt of bytes prior to upload = the amt of bytes after upload
then do something
else do something else.

The way things are going, this will never evaluate to true. Or, it
will evaluate to true at the wrong times. How do i replace the amount
of bytes taken out on the ftp server so the above condition makes
sense? Can somebody explain to me how to do this in VB.NET? I would
very much appreciate that.

Thanks for your help.
Click to expand...

You can't adjust for this. If the file sizes differ, they have not been
transfered correctly.

Make sure that the FTP program is really sending the files in binary
mode. If it sends them in ASCII mode, bytes that happens to be the same
as the character code for a line feed will be removed from the file.
 
You can't adjust for this. If the file sizes differ, they have not been
transfered correctly.

Make sure that the FTP program is really sending the files in binary
mode. If it sends them in ASCII mode, bytes that happens to be the same
as the character code for a line feed will be removed from the file.
Click to expand...


Thanks Goran.

I am indeed sending in Binary mode. I have it set to true.

I am wondering if anybody here is familiar with Microsoft's clsFTP
class? I think I see where my problem is and am wondering if anybody
knows where in the this class is the line that is actually "sending"
the bytes to the server. Tom, I think you are right that my mistake is
counting the bytes on the FTP server end. If somebody could show me
where the bytes are "leaving" instead of "arriving" that would be
seriously helpful. I cant seem to find that logic in the class.

If you don't know clsFTP, the class can be viewed here:
http://www.dotnethero.com/hero/vbnet/ftp.aspx?nmx=8_4

I was previously using the while loop inside the UploadFile method to
count bytes but that, I now know, was giving me an incorrect count:

'Upload the file.
m_iBytes = input.Read(m_aBuffer, 0, m_aBuffer.Length)
Do While (m_iBytes > 0)
cSocket.Send(m_aBuffer, m_iBytes, 0)
m_iBytes = input.Read(m_aBuffer, 0, m_aBuffer.Length)
Loop
input.Close()

Thanks for your help.
 
Back
Top