Socket.Send crashes phone

C

cyberco

WM5 PPC, .Net CF2, C#

As I mentioned here: http://groups.google.com/group/
microsoft.public.dotnet.framework.compactframework/browse_frm/thread/
78b6b19138bea875
I had troubles uploading a large files using the HttpWebRequest class.
So now I'm using plain sockets, which works just
fine.....except.......when uploading one audio file via GPRS (not via
ActiveSync).

I've tried uploading in chuncks but that didn't work, see my
discussion here:
http://groups.google.com/group/microsoft.public.dotnet.framework/
browse_frm/thread/bc5f8bce74b53b77

What I'm doing now is creating one big binary file of all the files
that need to be uploaded. That way I know the size in advance.
Although uploading multiple images and/or videos works just fine, the
problems is with audio files. Uploading one audio file sometimes
results in the Socket.Send() method to completely crash my phone
(Fujitsu-Siemens Loox). I can regenerate the crash. There is no way to
catch the exception. I have made sure all files are closed etc, but
nothing helps.

What could possibly be the problem here?
 
P

Paul G. Tobey [eMVP]

Since the socket has *NO IDEA* what you're sending, you're either passing
the wrong number of bytes, trying to send something that's so huge that the
socket buffers won't hold it, or trying to send something from a file that
someone else has open. You're going to have to catch the exception to
figure out what's going on, or at least examine the exception dialog
displayed when the crash occurs.

Tell us again how you are accomplishing this send. You're passing a byte[]
to send that contains 10MB of data? Or what?

Paul T.
 
C

cyberco

- It is unlikely that the number of bytes is incorrect, the socket
crashes quite quick afterly starting to send the bytes, not at the
end. Besides, the number of bytes is correct when using other types of
binary files (images, video).
- The number of bytes doesn't really affect the situation. I am
sending around 100Kb, but I am able to send much more than that (~5Mb)
in images and video.
- I take every measure possible to make sure nobody else locks the
file, and I flush and close the stream of the audiorecorder.
- Catching the exception is impossible since the exception crashes the
phone. I did the try/catch thing anyway, but that doesn't help.
- I'm indeed passing a byte[] to Socket.Send()
- The problem only occurs once in a while (with around the same size
of file), so it has to be something else than the nr. of bytes or so.
 
P

Paul G. Tobey [eMVP]

Sorry, but the socket doesn't know what type of file you are sending, so
*you* are incorporating the error in some way when it's an audio file.
You're trying to interpret the data as a string or something, or it's the
amount of data being sent. You'll have to show the code and send the file
that's causing the problem, I think. Based on your description of what is
happening, I think you're using up all of the memory on the device, so it
can't continue. Don't pass the whole file in a single send call is the only
advice without more debugging information...

Paul T.

cyberco said:
- It is unlikely that the number of bytes is incorrect, the socket
crashes quite quick afterly starting to send the bytes, not at the
end. Besides, the number of bytes is correct when using other types of
binary files (images, video).
- The number of bytes doesn't really affect the situation. I am
sending around 100Kb, but I am able to send much more than that (~5Mb)
in images and video.
- I take every measure possible to make sure nobody else locks the
file, and I flush and close the stream of the audiorecorder.
- Catching the exception is impossible since the exception crashes the
phone. I did the try/catch thing anyway, but that doesn't help.
- I'm indeed passing a byte[] to Socket.Send()
- The problem only occurs once in a while (with around the same size
of file), so it has to be something else than the nr. of bytes or so.


Since the socket has *NO IDEA* what you're sending, you're either passing
the wrong number of bytes, trying to send something that's so huge that
the
socket buffers won't hold it, or trying to send something from a file
that
someone else has open. You're going to have to catch the exception to
figure out what's going on, or at least examine the exception dialog
displayed when the crash occurs.

Tell us again how you are accomplishing this send. You're passing a
byte[]
to send that contains 10MB of data? Or what?

Paul T.
 
C

cyberco

Here's the relevant part of the code. The file I'm sending is just a
plain wav file created with Windows Media Player, but remember that
I'm first combining all files into one big binary file
(tmpUploadFile). As I've mentioned in one of my previous discussions I
ran into problems sending chunks of data. Oh, and the following
snippet works fine most of the time, even if the amount of data I'm
sending is *much* larger.

====================
FileStream tmpFileStream = new FileStream(tmpUploadFile,
FileMode.Open, FileAccess.Read);
long nrBytes = tmpFileStream.Length;
StringBuilder postString = new StringBuilder("POST /servlet HTTP/1.1\r
\n");
postString.Append("Host: " + HOST + "\r\n");
postString.Append("User-Agent: Windows Mobile 5 PPC\r\n");
postString.Append("Accept: */*;q=0.5\r\n");
postString.Append("Keep-Alive: 300\r\n");
postString.Append("Connection: keep-alive\r\n");
postString.Append("Content-Type: multipart/form-data; boundary=" +
BOUNDARY + "\r\n");
postString.Append("Content-Length: " + nrBytes + "\r\n");
postString.Append("\r\n");
postString.Append("\r\n");
socket.Send(Encoding.UTF8.GetBytes(postString.ToString()));
byte[] bytes = new byte[nrBytes];
tmpFileStream.Read(bytes, 0, (int)nrBytes);
tmpFileStream.Close();
socket.Send(bytes);
====================
 
P

Paul G. Tobey [eMVP]

So, you've come up with the number of bytes somehow and stored it in
nrBytes. Maybe that's wrong. Note that just because you pass nrBytes to

tmpFileStream.Read(bytes, 0, (int)nrBytes);

DOES NOT mean that you will actually get back that many valid bytes in
bytes. I think that your problem is very likely just some assumption that
you're making that happens to be wrong (you're assuming that some allocation
is successful; you're assuming that a read or a write has happened because a
given method has returned; you're assuming that because you've asked for a
send, that send has happened, etc.) I don't spot something completely wrong
with the code, but it won't work perfectly every time and I'd suspect that
some intermittent difference with the "perfect run" and you not reacting
properly to that difference is what's causing the problem.

Paul T.
 
C

cyberco

Thanks, Paul,

You are right about reading/sending the bytes (I should have been more
careful). I changed the code to make sure all bytes are read/sent.
Anyway, I solved the problem, which came from the audio recorder.

I am using OpenNetCF's OpenNETCF.Media.WaveAudio library for recording
the audio files.

======================
FileStream audioRecordingStream = new FileStream(path,
FileMode.Create);
Recorder recorder = new Recorder();
// Hook into the delegate for when the recording is finished.
recorder.DoneRecording += new
WaveFinishedHandler(recorderDoneRecording);
recorder.RecordFor(audioRecordingStream, MAX_RECORDING_TIME,
SoundFormats.Mono8bit11kHz);
======================

Users of my application can stop the recording before
MAX_RECORDING_TIME is reached. This is done by invoking
recorder.Stop(). The recorder will in turn invoke the DoneRecording
handle. The problem is that I MUST invoke recorder.Stop() in
recorderDoneRecording (the delegate/handle) again, else the resulting
file somehow seems corrupt (I can play it in a player, but
Socket.Send() breaks on it). Invoking recorder.stop() in the handle
solved my problem. Still, it' s weird that the error occurs only once
in a while. I'll report this back to OpenNetCF.

Thanks for your help!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top