07-26-2010 11:27 AM
To all BlackBerry networking experts out there.
The explanation of the problem will be long enough, so I'll try to structure the message for easier navigation.
Recently we switched from HttpConnection to raw sockets in our application. This was not an easy decision (a lot of additional code had to be written and debugged) - it stemmed from the fact that HttpConnection on different devices behaves very differently and sometimes we would just hang there forever trying to read something while enough bytes were available in the system buffers (I've seen that with my own eyes; can elaborate if anyone is interested). There were other reasons but this was the main one.
Previously working solution
Once we switched to sockets and implemented our own HttpConnection (not me - someone more knowledgeable in BB networking did that), our problems disappeared. In order to reduce the probability of getting stuck forever we check the socket's InputStream.available() and, if there is still 0, Thread.sleep() for some small interval (makes me cringe, but hey, the user is making a blocking call!) then read just one byte (hoping there would be something). This worked for all trackball/touchcpad devices and all kinds of connections (MDS is a separate issue, but we managed)...
... until we tested on Storm (5.0 Storm1 and 5.0 Storm2 - both behaved the same way) with all but WiFi connections disabled. We connected WiFi to our company's router (I then repeated the test at home with my own wireless router and got the same results). BB browser worked fine. However, our code started failing on our internal timeouts. When I connected the phone to the debugger and set up some breakpoints, I quickly discovered that InputStream.available() was always returning zero! I kid you not!
Our code was constantly diverted to waiting, reading one byte, waiting, reading another byte, ... Even when I tweaked the way we time out the download was exceptionally slow (as in "unbearable").
Worse yet - when I tried waiting for longer interval (100 ms) before doing the first read, then reading characters one-by-one without waiting, the phone started randomly rebooting!
Has anyone seen anything similar? If yes, what was your overall approach? I won't sit idly waiting for responses here - I still have some ideas to try - but if anyone has been there it would be nice if you could just nudge me in the right direction.
Thanks in advance,
Solved! Go to Solution.
07-26-2010 12:14 PM
Other people have had problems with available(). I am surprised you managed to get as far as you have, to be honest I thought it always returned 0.
We do socket connections and always prefix the transmission with a header field that includes the length. So the socket read on the Blackberry is basically
a) Read header
b) Read data
c) Process data
d) Go to (a).
Another user and I have had problems recently with OS 5.0 and http connections using WiFi - it locks up and/or times out when reading the response. This is the Thread
I would recommend you change your implementation of socket and data detection along these sorts of lines, in other words, know how much data there is to be read, and implement some sort of stall detection/recovery.
Does this make sense?
07-26-2010 01:11 PM
We already have all kinds of stall detection in place, and we made our server people add content-length to all responses. Sometimes we request that data be gzipped but then the server sends information in chunks. Naturally, each chunk has its own chunk header with length, and the HTTP headers are always followed by \r\n\r\n, so it is always possible to detect the end of the stream. We just wanted to make sure that the users rarely, if ever, waited for more than 3-5 sec (and succeeded on most devices and connection types) for the requested information to load.
In that regard what I've read in the thread you provided is somewhat depressing: it seems you also get occasional 15+ sec delays with WiFi. I do sincerely hope that RIM will make the process of updating 5.0 devices to 6.0 (once that becomes available) really simple and transparent so that our users, who are not computer experts, will want and be able to upgrade the OS. Oh yes, and I also hope they have a better networking code !
07-26-2010 05:33 PM
Can I just clarify something here. It seems the Server code still thinks it is talking http, but you have written socket hadnling code for the BlackBerry end. So you are processing the raw http yourselves. is that correct?
07-26-2010 07:01 PM
Yes, we have implemented our own HttpConnection, creating and reading HTTP headers, combining chunks and so on. It works very well on all kinds of connections, but has the problems I described with WiFi only phones (especially 5.0 Storms, even though Bold has had its share of problems as well).
07-26-2010 07:10 PM
In that case I would say that you are seeing the same problems that we saw in the Thread I referenced. Definitely something up in RIM WiFi land. Do you think we should raise an Issue Tracker Issue?
BTW, we see the problem on other phones too, such as 9000 Bolds that have been upgraded.
07-26-2010 10:41 PM
Yes, that's what I thought when I reviewed the link you posted. I guess everyone would benefit if we raised an issue. I hope you have enough information to provide, but I can chime in if necessary.
However, even if the issue is raised and resolved in 6.0, my main problem is that our customers are not technical people and are unlikely to upgrade their phones. Thus our objective is to whip this networking beast into shape somehow, using whatever trickery to make it work in the vast majority of cases.
And that "vast majority" is currently in danger: our previous code (already released and working on trackball/touchpad devices), slightly modified for Storm UI (I added some touchEvent processing), is failing on Storm WiFi in 100% of cases. I have made some modifications which actually caused the application to start working - but seemingly also caused at least two spontaneous reboots, which are "kind of" a show stopper.
I suspect not all computer science professors teach their students how to solve this kind of problems... Mine didn't.