I have some problem with some Symbian 9.2 devices’ TCP stack using HTTP APIs in Client-Server over HTTP.
My application (“client”) transfers files (upload/download) to/from server using HTTP::GET and HTTP::POST (simple binary post, not multipart) – HTTP 1.1.
I use RConnection/RSocketServer to attach GPRS/HSDPA with user selected APN. After that I open RHTTPSession providing RHTTPConnectionInfo with HTTP::EHttpSocketServ and HTTP::EHttpSocketConnection. This session object is used during files transfer process. In every GET/POST transaction I create and close corresponding RHTTPTransaction object.
The implementation was written according to guidelines from S60_Platform_HTTP_Client_API_Example_v2_1_en.zip example.
The server side (“server”) is Linux RHEL 5.1/5.2 64 bit and Centos 5 32bit with Tomcat 5.5 running on it and Java servlet that handles HTTP requests from the client side.
I’ve tested my application on various Symbian 9.1 (S60 3rd) devices (mainly Nokia devices) and have not seen any problem neither in files download nor in upload.
After I started to test it on Symbian 9.2 and 9.3 (S60 3rd FP1/FP2) I found some devices with strange behavior (in files upload only).
The most problematic device I’ve struggled against was Nokia E90 Communicator.
The problem is that sometimes upload (HTTP::POST) process is interrupted by “Socket Read TimeOut” exception on server side. Looks like the client stops to send the data.
I’ve recorded TCP dump on the server side and noticed out following things:
1. After the client sends HTTP POST request it starts sending binary data in TCP packets.
2. Sometimes some of TCP packets are lost in their way from client to server, but after couple of server’s ACK (on successfully transmitted data) client’s TCP stack sends missing packets and data transfer continues.
3. After some amount of transferred data (it’s not a constant amount – from hundreds of Kb to 5-10Mb) TCP packets are lost again – client skips one or two packets and sends newer packets. The server sends back ACK for the last packet before the data loss. Here the flow may vary. There is OR
a. Client keeps sending newer packets (1-3 packets) with no regards to server’s ACK
b. Client resends one of lost packets, received server’s ACK on it and instead of sending next lost packet sends newer packet.
4. On every not matched packet client sends (newer than server is ready to receive) server sends ACK on last good packet.
5. After couple of these ACKs the client stops sending TCP packets at all.
6. After 20-120 seconds (server configured timeout) server throws an exception “Socket Read TimeOut” and sends HTTP response with some error back to client.
7. Client receives it in MHFRunL(…) function.
After client receives this HTTP response whole data transfer process is stopped and RHTTPTransaction, RHTTPSession, RConnection objects are closed.
Actually, when the upload ends in normal way, when I close these objects I see 3G/3.5G sign in disconnected mode.
After the upload ends in abnormal way, like I described above, 3G/3.5G sign stays in connected mode with no respect to closed RConnection, RHTTPSession objects.
Moreover, if I try to start another RHTTPSession, RHTTPTransaction objects, HTTP requests don’t reach the server. It seems that no data exits from device and TCP stuck is busy by something. If I exit from the client (with closing all these objects – with no leaves or whatever) even Nokia Web browser cannot open any web page. In this time GPRS connection seems to be alive and connected (attached) because I see it sometimes changes 3G to 3.5G and vice versa.
So GPRS is not accessible by any application until I kill the 3G connection via red button (Call Hang up button).
After that Web browser is working and I’m able to send HTTP requests from client to server.
As I said, our QA department was unable to reproduce it on Symbian 9.1 devices.
The same code with same SIM card via same APN against the same server run smoothly on all Symbian 9.1 devices and makes troubles on some of Symbian 9.2 phones ( I had no time to test it thoroughly on all 9.2 devices).
From Symbian 9.2 devices I’ve seen this problem on E90 80-90% of times, on N95/N95 8G 30-40% of times, Nokia 6120, SAMSUNG i560/G810 – never.
I also checked it on 6210 Navigator (Symbian 9.3) – it happened only once to me from 10 uploads (5.5Mb each upload).
It seems to me that there is some bug in TCP stack implementation from Symbian 9.2 (may be some specific devices…)
Any help is more than appreciated.