TCP latency

[amit_mairantz]

Hi all,

My application runs a proprietary protocol over a standard HTTP over a TCP socket (bound to port 8080) which works perfectly. The normal round trip (measured by the application as well as by server sniffer) for the local network (UMTS) is around 400ms-600ms, except for the initial request/response where the round trip can measure up to 3 times as much (i.e. around 1800ms). Can anyone shed some light over this phenomena?

I also made sure that:
1. Latency is not due to TCP 3 way connection handshake (SYN and SYN/ACK) that is preformed before the request is issued when the TCP connection is established.

2. Latency is not due to DNS resolving because server runs a static IP

I will emphasize that the application I'm running has some real-time criteria meaning that the first request/response latency is crucial. Am I doing something wrong or is it normal network behavior? is it possible to reduce this latency? how?

Thanks Danny

[Paul.Todd]

Probably when you start pushing data over the socket this requires the account to be validated to see whether packet data is allowed on the account and this is where the delay is coming in.

You can try setting the AP to "When avaliable" in the "Packet Data" settings of the phone tab of the settings application and see if that makes a difference. Speaking from experience it did for me.

[wizard_hu_]

Personally I am no network expert, but I would not call an UMTS network access 'local'. My guess would be that some kind of routing path is what builds up on the first request, and that can take some time. And if you count connection establishment (to the network itself) into the first request, it also takes time.

[Sorcery-ltd]

If you are establishing the PDP context and setting up the TCP session before you need to send the first data but the round trip time is too long for the first request, then can you just send some dummy data first - some kind of redundant request-response?

Generally you can't rely on low-latency on a mobile network. For example, if your user roams onto 2.5G then the round trip is likely to go above 2 seconds in my experience. Also, if the cell you are in is busy then you may have to wait a little longer to be granted an appropriate channel (or code in the case of UMTS).

Also, HTTP over TCP is hopeless for anything real-time. A packet can be lost and then re-sent at any point, particularly over a cellular link. If you have genuine hard timing constraints then you'll have to use UDP (which will speed things up by avoiding the HTTP stack anyway) and handle packet losses yourself.

Sorcery