File Transfer Problem in c#

[Abhishek]

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 = (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

 

[Jon Skeet [C# MVP]]

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.

 

[Jeya]

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.



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 = (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

 

[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

 

[Abhishek]

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.

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.



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 = (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

 

[Jon Skeet [C# MVP]]

[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.]

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 [C# MVP]]

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 [C# MVP]]

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.

 

[Abhishek]

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?

[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.]

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 [C# MVP]]

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.

 

[Abhishek]

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

[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.]

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.

 

[Abhishek]

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

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?

[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.]

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.