views:

716

answers:

4

Hi all,

I have a problem on Windows Mobile 6.0. I would like to create a TCP connection which does not use the Nagle algorithm, so it sends my data when I call "send" function, and does not buffer calls, having too small amount of data.

I tried the following:

BOOL b = TRUE; setsockopt(socketfd, IPPROTO_TCP, TCP_NODELAY, (char*)(&b), sizeof(BOOL));

It works fine on desktop. But on Windows Mobile, if I set this value, than I make a query for it, the returned value is 8. And the network traffic analysis shows that the nothing changed.

Is there any way to force a flush to my socket?

A: 

Are you setting the option on both ends of the connection and after the connection has been established? I just had someone test it and it worked fine with TCP over ActiveSync, significantly improving the command-response cycle time in the test app (about a 4x improvement in fact).

ctacke
A: 

The server is given I cannot modify it, but i.e.: our Symbian client works fine with it, with this option. I tried setting this option both before and after creating the connection but nothing changed. I use TCP over Windows Mobile Device Center(since I use Vista).

A: 

It just occurred to me, (this is a wild guess and probably not likely) but maybe you're having a delayed ack problem due to your send buffer being smaller than the size of the data you're writing. Nagle may have nothing to do with it.

Does the receiving side send any data back immediately? If not, your peer will delay it's ack for up to 200ms waiting to piggy back it's ack on some data to make better use of bandwidth.

When the send buffer on the socket is smaller than the data in this case the call to write will block until the ack has been received and all the data sent.

For example if your send buffer is 8192 bytes and you send 8193 bytes and your peer sends no data back then your write will block for 200ms ( or however long your peers implementation delays the ack) effectively making it look like Nagle is killing you even when it's disabled.

If this is the case you could either increase the send buffer size or have your peer always send you back a null byte to force the ack to be sent immediately.

Otherwise, I would maybe try playing around with NTttcp_x86 a bit to model your applications send / receive patterns and see if maybe something else is going on.

Robert S. Barnes
A: 

It seems to me that TCP_NODELAY option is not supported for windows mobile edition. Check the MSDN documentation, it might have something to that effect, but I remember a while back struggling with setting few socket options including TCP_NODELAY and setting send and receive buffer, and the setsockopt call would fail. Check that setsockopt returns false, if not, get the ::WSAGetLastError() and see if that leads you anywhere. In my case, I remember having to do without these options as they were not supported. I was working on Windows Mobile 5.

navigator