I have a problem transfering files using sockets from pocket pc(.net compact
c#) to desktop(not using .net just mfc and sockets 2 API). The socket
communication is not a issue and I am able to transfer data across.On the
serve I am using Socket 2 API (recv function to read bytes)and not using
..NET. I use FileStream to open the file on the pocket pc, then associate a
BinaryReader object with the stream and call ReadBytes to read all the bytes
into a byte array. I have a connected socket and I send this byte array
asynchronously over the network. I get the file on my computer but image
data is corrupted. I tried debugging, and found that the values that I have
in the byte array are not the same as they are in the file. Rather the
header information of the JPG gets transferred correctly. Since the file was
originally on the PC and was downloaded to the emulator by adding it to the
project. I assume that the byte values at their corresponding locations
should match with what the byte array contains after loading the file data
on the pocket pc. It does not! For instance the byte #213 is having decimal
value 62 on the PC when I see the corresponding index in the byte array it
reads 65. Is this a problem of encoding? Unicode and ASCII? Does it have
anything to do with byte ordering? why is this happening? what is the way
out to provide a simple byte to byte transfer of files from hand-held to PC
and from PC to hand-held over the network? Please reply because at this
point I have tried all options and I don't have a way out. I am able to
send textmessages to and fro client and server.
Following is the code snippet of client and server.
Server
FILE *pFile = NULL;//file pointer
BYTE recvbuf[1024];
pFile = fopen(strFileName,"w");//opens a file for writing if the file does
exist it will empty it
int bytesRecv = SOCKET_ERROR;//initializes to an error value.
//this a while loop that keep reading bytes till the terminating symbol is
not found in the stream
while( bytesRecv == SOCKET_ERROR || !boTermFound)
{//keep reading and writing bytes till you read the end of the message
bytesRecv = recv(AcceptSocket, (char*)recvbuf, 1024, 0 );
//have to check weather the last n bytes contain the terminator string
if (bytesRecv == 0 || bytesRecv == WSAECONNRESET )
{
AfxMessageBox( "Connection Closed");
return false;
break;
}
boTermFound = CheckForTerminator(strTermString,recvbuf,bytesRecv );
fwrite(recvbuf, sizeof(BYTE),bytesRecv, pFile);
}
fclose(pFile)
Client (.net compact c#)
-------------------------
FileStream myFileStream;
myFileStream = new
FileStream(m_strFileName,FileMode.Open,FileAccess. Read,FileShare.Read);//an
instance of FileStream
byte[] b = new byte[myFileStream.Length];//create a byte array to store
for(long i=0;i<myFileStream.Length;i++)
b[i] = (byte)myFileStream.ReadByte();
myFileStream.Close();
_socket.BeginSend(b, 0, b.Length,
SocketFlags.None, null, null);
// send the terminator
_asyncEvent.Reset();
_socket.BeginSend(Network.TerminatorBytes, 0,
Network.TerminatorBytes.Length, SocketFlags.None, _sendCallback, true);
//this is just code that indicates termination of data.
This is becoming a serious problem. My whole project depends on
succcessfully able to transfer jpg images. Please look into this.
Regards, Abhishek
11  6591 
Abhishek <ga*****@rpi.edu> wrote: I have a problem transfering files using sockets from pocket pc(.net compact
c#) to desktop(not using .net just mfc and sockets 2 API). The socket
communication is not a issue and I am able to transfer data across.On the
serve I am using Socket 2 API (recv function to read bytes)and not using
.NET. I use FileStream to open the file on the pocket pc, then associate a
BinaryReader object with the stream and call ReadBytes to read all the bytes
into a byte array.
That's not what the code you posted does. The code you posted reads
each byte in turn, which is pretty horrendous in terms of performance.
I'd actually use neither technique - I'd create a memory stream, and
read chunks from the file stream until you can't read any more, writing
the chunks to the memory stream as you go and then calling ToArray on
the memory stream afterwards. That way you won't get into problems if
the file size changes while you're reading, too.
I have a connected socket and I send this byte array
asynchronously over the network.
Right - the first thing to do is find out what side the error's on. I
suggest you write simple code on each side which doesn't deal with
files at all, it just either writes a fixed block of binary out to the
socket, or writes the bytes to the screen for comparison (on the reader
side).
One problem I can see on the client side is that you've effectively got
more than one thread sending data - you're sending the terminator
asynchonrously with respect to the jpeg itself, which can't be a good
idea. I don't think the terminator is a good idea in the first place,
to be honest - what's to stop it appearing in the main file? Send a
length before the data instead.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
hi,
I had a same kind of problem with my smtp gateway...
I solved th problem by checking termination char and extract the exact data
then send to the filestram to write.
In my case
Reply from smtp server...read [1024] bytes say if the actual data is only 24
bytes .Net will fill with "\0\0\0..." the rest.
Not sure..about your problem.
Jeyapandian.
"Abhishek" <ga*****@rpi.edu> wrote in message
news:uJ**************@TK2MSFTNGP12.phx.gbl...
I have a problem transfering files using sockets from pocket pc(.net compact
c#) to desktop(not using .net just mfc and sockets 2 API). The socket
communication is not a issue and I am able to transfer data across.On the
serve I am using Socket 2 API (recv function to read bytes)and not using
..NET. I use FileStream to open the file on the pocket pc, then associate a
BinaryReader object with the stream and call ReadBytes to read all the bytes
into a byte array. I have a connected socket and I send this byte array
asynchronously over the network. I get the file on my computer but image
data is corrupted. I tried debugging, and found that the values that I have
in the byte array are not the same as they are in the file. Rather the
header information of the JPG gets transferred correctly. Since the file was
originally on the PC and was downloaded to the emulator by adding it to the
project. I assume that the byte values at their corresponding locations
should match with what the byte array contains after loading the file data
on the pocket pc. It does not! For instance the byte #213 is having decimal
value 62 on the PC when I see the corresponding index in the byte array it
reads 65. Is this a problem of encoding? Unicode and ASCII? Does it have
anything to do with byte ordering? why is this happening? what is the way
out to provide a simple byte to byte transfer of files from hand-held to PC
and from PC to hand-held over the network? Please reply because at this
point I have tried all options and I don't have a way out. I am able to
send textmessages to and fro client and server.
Following is the code snippet of client and server.
Server
FILE *pFile = NULL;//file pointer
BYTE recvbuf[1024];
pFile = fopen(strFileName,"w");//opens a file for writing if the file does
exist it will empty it
int bytesRecv = SOCKET_ERROR;//initializes to an error value.
//this a while loop that keep reading bytes till the terminating symbol is
not found in the stream
while( bytesRecv == SOCKET_ERROR || !boTermFound)
{//keep reading and writing bytes till you read the end of the message
bytesRecv = recv(AcceptSocket, (char*)recvbuf, 1024, 0 );
//have to check weather the last n bytes contain the terminator string
if (bytesRecv == 0 || bytesRecv == WSAECONNRESET )
{
AfxMessageBox( "Connection Closed");
return false;
break;
}
boTermFound = CheckForTerminator(strTermString,recvbuf,bytesRecv );
fwrite(recvbuf, sizeof(BYTE),bytesRecv, pFile);
}
fclose(pFile)
Client (.net compact c#)
-------------------------
FileStream myFileStream;
myFileStream = new
FileStream(m_strFileName,FileMode.Open,FileAccess. Read,FileShare.Read);//an
instance of FileStream
byte[] b = new byte[myFileStream.Length];//create a byte array to store
for(long i=0;i<myFileStream.Length;i++)
b[i] = (byte)myFileStream.ReadByte();
myFileStream.Close();
_socket.BeginSend(b, 0, b.Length,
SocketFlags.None, null, null);
// send the terminator
_asyncEvent.Reset();
_socket.BeginSend(Network.TerminatorBytes, 0,
Network.TerminatorBytes.Length, SocketFlags.None, _sendCallback, true);
//this is just code that indicates termination of data.
This is becoming a serious problem. My whole project depends on
succcessfully able to transfer jpg images. Please look into this.
Regards, Abhishek
The code I put down there is slightly different there because I have been
trying all different kind of things and this was the latest changes I was
underway. I have also used the BinaryReader method and did not work. I know
reading byte to byte is horrendous but right now I want to transfer my data
without any corruption and that is my major concern.
Its is likely that using a terminator string might not be a good idea but a
terminator string wont repeate twice. In my case I do get the terminator
string at the end of the byte transfer only. So the terminator string is not
getting mixed somewhere in the middle of the data.
About the problem being there on the client end or server end it seems most
likely it is the client end. Because I have a one JPG file which I transfer
from the desktop to the pocket pc. This is the very file I am trying to send
back using sockets. Now the way I am checking this is I am loading the files
in byte array at both ends. The first 213 bytes in the pocket pc and the
desktop are identical but things change after the 214 byte, its deciamal
value on the desktop version of the file is 62 and its value in the pocket
pc version is 65. The character corresponding to 62 is '>' and that is what
it shows when i open the file in binary on the desktop. Now from this byte
onwards things are no longer identical. Things get different if not
drastically. So what my feeling is that the pocket pc interprets byte data
in a different manner using a different encoding. But I dont know. I tried
loading the same file on the pocket pc using one file stream and writing
using another filestream and it made a copy of the image file on the pocket
pc so loading of the byte data seems ok from the pokcet pc environment but
is not having the same correspondance with the byte data on the desktop. I
hope I have answered all your questions. Please give me hints what to do
next?
Abhishek
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Abhishek <ga*****@rpi.edu> wrote: I have a problem transfering files using sockets from pocket pc(.net
compact c#) to desktop(not using .net just mfc and sockets 2 API). The socket
communication is not a issue and I am able to transfer data across.On
the serve I am using Socket 2 API (recv function to read bytes)and not using
.NET. I use FileStream to open the file on the pocket pc, then
associate a BinaryReader object with the stream and call ReadBytes to read all the
bytes into a byte array.
That's not what the code you posted does. The code you posted reads
each byte in turn, which is pretty horrendous in terms of performance.
I'd actually use neither technique - I'd create a memory stream, and
read chunks from the file stream until you can't read any more, writing
the chunks to the memory stream as you go and then calling ToArray on
the memory stream afterwards. That way you won't get into problems if
the file size changes while you're reading, too.
I have a connected socket and I send this byte array
asynchronously over the network.
Right - the first thing to do is find out what side the error's on. I
suggest you write simple code on each side which doesn't deal with
files at all, it just either writes a fixed block of binary out to the
socket, or writes the bytes to the screen for comparison (on the reader
side).
One problem I can see on the client side is that you've effectively got
more than one thread sending data - you're sending the terminator
asynchonrously with respect to the jpeg itself, which can't be a good
idea. I don't think the terminator is a good idea in the first place,
to be honest - what's to stop it appearing in the main file? Send a
length before the data instead.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
So you mean i check for the first occurance of \0 or a repeated sequence of
\0\0\0 ?
You are talking of this in referene to byte transfer or simply ASCII
transfer bec I am able to do text transfer without any problems.
"Jeya" <je**@cmtsp.com.sg> wrote in message
news:Oa**************@TK2MSFTNGP12.phx.gbl... hi,
I had a same kind of problem with my smtp gateway...
I solved th problem by checking termination char and extract the exact
data then send to the filestram to write.
In my case
Reply from smtp server...read [1024] bytes say if the actual data is only
24 bytes .Net will fill with "\0\0\0..." the rest.
Not sure..about your problem.
Jeyapandian.
"Abhishek" <ga*****@rpi.edu> wrote in message
news:uJ**************@TK2MSFTNGP12.phx.gbl...
I have a problem transfering files using sockets from pocket pc(.net
compact c#) to desktop(not using .net just mfc and sockets 2 API). The socket
communication is not a issue and I am able to transfer data across.On the
serve I am using Socket 2 API (recv function to read bytes)and not using
.NET. I use FileStream to open the file on the pocket pc, then associate
a BinaryReader object with the stream and call ReadBytes to read all the
bytes into a byte array. I have a connected socket and I send this byte array
asynchronously over the network. I get the file on my computer but image
data is corrupted. I tried debugging, and found that the values that I
have in the byte array are not the same as they are in the file. Rather the
header information of the JPG gets transferred correctly. Since the file
was originally on the PC and was downloaded to the emulator by adding it to
the project. I assume that the byte values at their corresponding locations
should match with what the byte array contains after loading the file data
on the pocket pc. It does not! For instance the byte #213 is having
decimal value 62 on the PC when I see the corresponding index in the byte array it
reads 65. Is this a problem of encoding? Unicode and ASCII? Does it have
anything to do with byte ordering? why is this happening? what is the way
out to provide a simple byte to byte transfer of files from hand-held to
PC and from PC to hand-held over the network? Please reply because at this
point I have tried all options and I don't have a way out. I am able to
send textmessages to and fro client and server.
Following is the code snippet of client and server.
Server
FILE *pFile = NULL;//file pointer
BYTE recvbuf[1024];
pFile = fopen(strFileName,"w");//opens a file for writing if the file does
exist it will empty it
int bytesRecv = SOCKET_ERROR;//initializes to an error value.
//this a while loop that keep reading bytes till the terminating symbol is
not found in the stream
while( bytesRecv == SOCKET_ERROR || !boTermFound)
{//keep reading and writing bytes till you read the end of the message
bytesRecv = recv(AcceptSocket, (char*)recvbuf, 1024, 0 );
//have to check weather the last n bytes contain the terminator string
if (bytesRecv == 0 || bytesRecv == WSAECONNRESET )
{
AfxMessageBox( "Connection Closed");
return false;
break;
}
boTermFound = CheckForTerminator(strTermString,recvbuf,bytesRecv );
fwrite(recvbuf, sizeof(BYTE),bytesRecv, pFile);
}
fclose(pFile)
Client (.net compact c#)
-------------------------
FileStream myFileStream;
myFileStream = new
FileStream(m_strFileName,FileMode.Open,FileAccess. Read,FileShare.Read);//an instance of FileStream
byte[] b = new byte[myFileStream.Length];//create a byte array to store
for(long i=0;i<myFileStream.Length;i++)
b[i] = (byte)myFileStream.ReadByte();
myFileStream.Close();
_socket.BeginSend(b, 0, b.Length,
SocketFlags.None, null, null);
// send the terminator
_asyncEvent.Reset();
_socket.BeginSend(Network.TerminatorBytes, 0,
Network.TerminatorBytes.Length, SocketFlags.None, _sendCallback, true);
//this is just code that indicates termination of data.
This is becoming a serious problem. My whole project depends on
succcessfully able to transfer jpg images. Please look into this.
Regards, Abhishek
[As answered in email - please note my signature, which requests that
you *don't* CC me if you're replying to the group as well.]
Abhishek <ga*****@rpi.edu> wrote: The code I put down there is slightly different there because
I have been trying all different kind of things and this was
the latest changes I was underway. I have also used the
BinaryReader method and did not work. I know reading byte to
byte is horrendous but right now I want to transfer my data
without any corruption and that is my major concern.
Its is likely that using a terminator string might not be a
good idea but a terminator string wont repeate twice. In my
case I do get the terminator string at the end of the byte
transfer only. So the terminator string is not getting mixed
somewhere in the middle of the data.
It's a bad idea to mix binary data and character data - and a
terminator *string* sounds like character data in the middle of binary
data. A length prefix is definitely a nicer way to go here - it also
means the other end will know how much to expect.
Writing the terminator string asynchronously is *definitely* a bad idea
though.
About the problem being there on the client end or server end
it seems most likely it is the client end. Because I have a
one JPG file which I transfer from the desktop to the pocket
pc. This is the very file I am trying to send back using
sockets. Now the way I am checking this is I am loading the
files in byte array at both ends. The first 213 bytes in the
pocket pc and the desktop are identical but things change
after the 214 byte, its deciamal value on the desktop version
of the file is 62 and its value in the pocket pc version is
65. The character corresponding to 62 is '>' and that is what
it shows when i open the file in binary on the desktop.
So which byte did the Pocket PC send? If it's the correct one, the
problem is on the server. If it's the wrong one, the problem is on the
client.
Again, you need to be very clear of the difference between a byte and a
character. Deal *entirely* in binary terms for this.
Now
from this byte onwards things are no longer identical. Things
get different if not drastically. So what my feeling is that
the pocket pc interprets byte data in a different manner
using a different encoding.
There *are* no encodings involved in binary data - only character data.
But I dont know. I tried loading
the same file on the pocket pc using one file stream and
writing using another filestream and it made a copy of the
image file on the pocket pc so loading of the byte data seems
ok from the pokcet pc environment but is not having the same
correspondance with the byte data on the desktop. I hope I
have answered all your questions. Please give me hints what
to do next?
Write a very simple app to replace the server one, and get it to just
output (in hex) whatever it receives.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Abhishek <ga*****@rpi.edu> wrote: So you mean i check for the first occurance of \0 or a repeated sequence of
\0\0\0 ?
You are talking of this in referene to byte transfer or simply ASCII
transfer bec I am able to do text transfer without any problems.
The problem Jeya was talking about isn't your problem here, as you're
writing as many bytes as you're reading.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jeya <je**@cmtsp.com.sg> wrote: I had a same kind of problem with my smtp gateway...
I solved th problem by checking termination char and extract the exact data
then send to the filestram to write.
In my case
Reply from smtp server...read [1024] bytes say if the actual data is only 24
bytes .Net will fill with "\0\0\0..." the rest.
No, .NET doesn't fill the rest at all - it leaves it exactly as it was,
and it's up to you to use the return value of Read to see how much has
been read. A lot of IO problems are caused by people assuming that Read
will read *exactly* the number of bytes specified.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Sorry for not noticing that comment in your signature.
I have tried exactly what you said. I removed asynchronous send . I also
removed any terminator strings. At the server end I hardcode the number of
bytes the client was sending for quick prototyping. Now there is no mix of
binary data with character data and there is just one call to send. However,
I still use BinaryReader to read the bytes so the next I will try with the
memory stream but I don't know how that is going to help. One more thing to
note the file on the desktop has the size 40,016 bytes but the when this
file is opened using a file stream object in the pocket pc its length is
41,031 bytes. And finally the size of the file I write after getting data
becomes on the desktop (41,178 bytes).
Another thing to note here is that I am doing all this in a emulator? I hope
there are no known bugs with the emulator concerned to what I am trying to
do.
I don't really see any trouble with the server or server program because the
server is getting the bytes which the client is transferring. I have
debugged and seen that all the byte values that the client is sending is
received by the server with one to one correspondence. but it seams the
client is reading the wrong byte values. because what byte values the client
is reading in the first place does not hold a one to one correspondence
between what byte values the image has on the desktop.
What more do you suggest I can try?
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... [As answered in email - please note my signature, which requests that
you *don't* CC me if you're replying to the group as well.]
Abhishek <ga*****@rpi.edu> wrote: The code I put down there is slightly different there because
I have been trying all different kind of things and this was
the latest changes I was underway. I have also used the
BinaryReader method and did not work. I know reading byte to
byte is horrendous but right now I want to transfer my data
without any corruption and that is my major concern.
Its is likely that using a terminator string might not be a
good idea but a terminator string wont repeate twice. In my
case I do get the terminator string at the end of the byte
transfer only. So the terminator string is not getting mixed
somewhere in the middle of the data.
It's a bad idea to mix binary data and character data - and a
terminator *string* sounds like character data in the middle of binary
data. A length prefix is definitely a nicer way to go here - it also
means the other end will know how much to expect.
Writing the terminator string asynchronously is *definitely* a bad idea
though.
About the problem being there on the client end or server end
it seems most likely it is the client end. Because I have a
one JPG file which I transfer from the desktop to the pocket
pc. This is the very file I am trying to send back using
sockets. Now the way I am checking this is I am loading the
files in byte array at both ends. The first 213 bytes in the
pocket pc and the desktop are identical but things change
after the 214 byte, its deciamal value on the desktop version
of the file is 62 and its value in the pocket pc version is
65. The character corresponding to 62 is '>' and that is what
it shows when i open the file in binary on the desktop.
So which byte did the Pocket PC send? If it's the correct one, the
problem is on the server. If it's the wrong one, the problem is on the
client.
Again, you need to be very clear of the difference between a byte and a
character. Deal *entirely* in binary terms for this.
Now
from this byte onwards things are no longer identical. Things
get different if not drastically. So what my feeling is that
the pocket pc interprets byte data in a different manner
using a different encoding.
There *are* no encodings involved in binary data - only character data.
But I dont know. I tried loading
the same file on the pocket pc using one file stream and
writing using another filestream and it made a copy of the
image file on the pocket pc so loading of the byte data seems
ok from the pokcet pc environment but is not having the same
correspondance with the byte data on the desktop. I hope I
have answered all your questions. Please give me hints what
to do next?
Write a very simple app to replace the server one, and get it to just
output (in hex) whatever it receives.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Abhishek <ga*****@rpi.edu> wrote: Sorry for not noticing that comment in your signature.
I have tried exactly what you said. I removed asynchronous send . I also
removed any terminator strings. At the server end I hardcode the number of
bytes the client was sending for quick prototyping. Now there is no mix of
binary data with character data and there is just one call to send. However,
I still use BinaryReader to read the bytes so the next I will try with the
memory stream but I don't know how that is going to help. One more thing to
note the file on the desktop has the size 40,016 bytes but the when this
file is opened using a file stream object in the pocket pc its length is
41,031 bytes.
Right. That's the first thing to fix then. How did you get the image to
the desktop in the first place?
And finally the size of the file I write after getting data
becomes on the desktop (41,178 bytes).
It sounds like *something* is still doing things incorrectly,
certainly.
Another thing to note here is that I am doing all this in a emulator? I hope
there are no known bugs with the emulator concerned to what I am trying to
do.
I shouldn't think so.
I don't really see any trouble with the server or server program because the
server is getting the bytes which the client is transferring. I have
debugged and seen that all the byte values that the client is sending is
received by the server with one to one correspondence. but it seams the
client is reading the wrong byte values. because what byte values the client
is reading in the first place does not hold a one to one correspondence
between what byte values the image has on the desktop.
What more do you suggest I can try?
I suggest you write a short but complete program (one for each side)
which demonstrates the problem (and nothing else). If you then mail me
a sample image which gives you problems, I'll have a look and try to
reproduce it. If I can reproduce it, I can have a good crack at fixing
it.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Well, I also did what you said like make the server program very simple. And
there is some interesting observation I got. Firstly I reduced the file size
to just 498 bytes. What I see is that though the server recieves 498 bytes
it writes more to the file. So this time i removed the code to write a file
instead simply printed out the hex values of each recieved byte. It turns
out the fwrite in inserting data on its own.
For instance, after the byte # 259 it inserted a byte # 260 with value 0D.
Now, it seems the problem might be with fwrite and what it appears to me is
that there is some kind of padding or alignment taking place but why?
Abhishek
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... [As answered in email - please note my signature, which requests that
you *don't* CC me if you're replying to the group as well.]
Abhishek <ga*****@rpi.edu> wrote: The code I put down there is slightly different there because
I have been trying all different kind of things and this was
the latest changes I was underway. I have also used the
BinaryReader method and did not work. I know reading byte to
byte is horrendous but right now I want to transfer my data
without any corruption and that is my major concern.
Its is likely that using a terminator string might not be a
good idea but a terminator string wont repeate twice. In my
case I do get the terminator string at the end of the byte
transfer only. So the terminator string is not getting mixed
somewhere in the middle of the data.
It's a bad idea to mix binary data and character data - and a
terminator *string* sounds like character data in the middle of binary
data. A length prefix is definitely a nicer way to go here - it also
means the other end will know how much to expect.
Writing the terminator string asynchronously is *definitely* a bad idea
though.
About the problem being there on the client end or server end
it seems most likely it is the client end. Because I have a
one JPG file which I transfer from the desktop to the pocket
pc. This is the very file I am trying to send back using
sockets. Now the way I am checking this is I am loading the
files in byte array at both ends. The first 213 bytes in the
pocket pc and the desktop are identical but things change
after the 214 byte, its deciamal value on the desktop version
of the file is 62 and its value in the pocket pc version is
65. The character corresponding to 62 is '>' and that is what
it shows when i open the file in binary on the desktop.
So which byte did the Pocket PC send? If it's the correct one, the
problem is on the server. If it's the wrong one, the problem is on the
client.
Again, you need to be very clear of the difference between a byte and a
character. Deal *entirely* in binary terms for this.
Now
from this byte onwards things are no longer identical. Things
get different if not drastically. So what my feeling is that
the pocket pc interprets byte data in a different manner
using a different encoding.
There *are* no encodings involved in binary data - only character data.
But I dont know. I tried loading
the same file on the pocket pc using one file stream and
writing using another filestream and it made a copy of the
image file on the pocket pc so loading of the byte data seems
ok from the pokcet pc environment but is not having the same
correspondance with the byte data on the desktop. I hope I
have answered all your questions. Please give me hints what
to do next?
Write a very simple app to replace the server one, and get it to just
output (in hex) whatever it receives.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Well the problem got solved. Thanks Jon for your useful tips.
It turned out that I was opening the file in the default mode. The default
mode was text. So all newline and linefeeds were not getting suppressed. So
when I opened the file in binary the fwrite suppressed all linefeeds and
carrige returns.
Ciao!
Abhishek
"Abhishek" <ga*****@rpi.edu> wrote in message
news:%2******************@tk2msftngp13.phx.gbl... Sorry for not noticing that comment in your signature.
I have tried exactly what you said. I removed asynchronous send . I also
removed any terminator strings. At the server end I hardcode the number of
bytes the client was sending for quick prototyping. Now there is no mix of
binary data with character data and there is just one call to send.
However, I still use BinaryReader to read the bytes so the next I will try with the
memory stream but I don't know how that is going to help. One more thing
to note the file on the desktop has the size 40,016 bytes but the when this
file is opened using a file stream object in the pocket pc its length is
41,031 bytes. And finally the size of the file I write after getting data
becomes on the desktop (41,178 bytes).
Another thing to note here is that I am doing all this in a emulator? I
hope there are no known bugs with the emulator concerned to what I am trying to
do.
I don't really see any trouble with the server or server program because
the server is getting the bytes which the client is transferring. I have
debugged and seen that all the byte values that the client is sending is
received by the server with one to one correspondence. but it seams the
client is reading the wrong byte values. because what byte values the
client is reading in the first place does not hold a one to one correspondence
between what byte values the image has on the desktop.
What more do you suggest I can try?
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... [As answered in email - please note my signature, which requests that
you *don't* CC me if you're replying to the group as well.]
Abhishek <ga*****@rpi.edu> wrote: The code I put down there is slightly different there because
I have been trying all different kind of things and this was
the latest changes I was underway. I have also used the
BinaryReader method and did not work. I know reading byte to
byte is horrendous but right now I want to transfer my data
without any corruption and that is my major concern.
Its is likely that using a terminator string might not be a
good idea but a terminator string wont repeate twice. In my
case I do get the terminator string at the end of the byte
transfer only. So the terminator string is not getting mixed
somewhere in the middle of the data.
It's a bad idea to mix binary data and character data - and a
terminator *string* sounds like character data in the middle of binary
data. A length prefix is definitely a nicer way to go here - it also
means the other end will know how much to expect.
Writing the terminator string asynchronously is *definitely* a bad idea
though.
About the problem being there on the client end or server end
it seems most likely it is the client end. Because I have a
one JPG file which I transfer from the desktop to the pocket
pc. This is the very file I am trying to send back using
sockets. Now the way I am checking this is I am loading the
files in byte array at both ends. The first 213 bytes in the
pocket pc and the desktop are identical but things change
after the 214 byte, its deciamal value on the desktop version
of the file is 62 and its value in the pocket pc version is
65. The character corresponding to 62 is '>' and that is what
it shows when i open the file in binary on the desktop.
So which byte did the Pocket PC send? If it's the correct one, the
problem is on the server. If it's the wrong one, the problem is on the
client.
Again, you need to be very clear of the difference between a byte and a
character. Deal *entirely* in binary terms for this.
Now
from this byte onwards things are no longer identical. Things
get different if not drastically. So what my feeling is that
the pocket pc interprets byte data in a different manner
using a different encoding.
There *are* no encodings involved in binary data - only character data.
But I dont know. I tried loading
the same file on the pocket pc using one file stream and
writing using another filestream and it made a copy of the
image file on the pocket pc so loading of the byte data seems
ok from the pokcet pc environment but is not having the same
correspondance with the byte data on the desktop. I hope I
have answered all your questions. Please give me hints what
to do next?
Write a very simple app to replace the server one, and get it to just
output (in hex) whatever it receives.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Lingyun Yang |
last post by:
*** post for FREE via your newsreader at post.newsfeed.com ***
Dear all,
I have a file it's binary data viewed in UltraEdit is
EF BB BF 0D 0A 3C .......
I want to read them into a int or long...
|
by: Stephan Steiner |
last post by:
Hi
Generally,
FileInfo fi = new FileInfo(path);
long size = fi.Length;
gets you the length of a file in bytes. However, when copying files, even
while the copy operation is still in...
|
by: Xarky |
last post by:
Hi,
I am downloading a GIF file(as a mail attachement) with this file
format, Content-Transfer-Encoding: base64;
Now I am writing the downloaded data to a file with this technique:
...
|
by: Nathan |
last post by:
I have an aspx page with a data grid, some textboxes, and an update button.
This page also has one html input element with type=file (not inside the data
grid and runat=server).
The update...
|
by: Alex |
last post by:
Hello,
I'm trying to write a little php script to transfert some
files from a server to clients (web/http).
It's working fin with small files. But transfering big files
(try on 1Gb) failed!...
| | |
by: David |
last post by:
I have googled to no avail on getting specifically what I'm looking for. I
have found plenty of full blown apps that implement some type of file
transfer but what I'm specifcally looking for is an...
|
by: tedpottel |
last post by:
Hi,
My program has the following code to transfer a binary file
f = open(pathanme+filename,'rb')
print "start transfer"
self.fthHandle.storbinary('STOR '+filename, f)
How can I do an ASCII...
|
by: fiona |
last post by:
Yucca Valley, CA, - October 2007: Catalyst Development Corporation,
publisher of SocketTools, SocketWrench and LogicGem, today announced
the release of Catalyst File Transfer .NET V5.0. For...
|
by: Thom Little |
last post by:
I need to transfer an XML file between an application on the client and the
server. This would in fact be a copy of the application's .config file.
HTML <input form=...would transfer the file...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
