2

I have a java application acting a a server and an android phone acting as a client. They are communicating over TCP sockets.

I often have the client sleep and when its buffer fills I want the wifi radio to be able to go to sleep. The problem is the client isn't sleeping. I noticed wireshark says my server is sending the a TCP KeepAlive packet approximately every half second so the wifi can't sleep. I've tried the following on the server and client.

connectionSocket.setKeepAlive(false);

But this appears to change nothing. I am using wireshark to analyze the traffic. Here is a screen shot of wireshark... the black lines indicate where my client is asleep and it's receieve buffer is full. Can I stop the keepAlive packets from being sent by the server?

Thanks!

Michael
  • 21
  • 1
  • 2
  • 1
    I cannot see your screen shot. – secmask Mar 10 '11 at 05:07
  • " I noticed wireshark says my server is sending the a TCP KeepAlive packet approximately every half second " What platform is this? Sending a TCP KeepAlive probe every half second seems incredibly aggressive. – Rick Jones Jun 28 '21 at 00:41

3 Answers3

1

TCP connections stay open until closed, the keep alive mechanism is here to detect connection failures.

Check out this link: Does a TCP socket connection have a "keep alive"?

Community
  • 1
  • 1
Joel Arnold
  • 1,201
  • 13
  • 28
  • Ah, according to a fellow in your link it looks like there isn't really much I can do. A follow up question I have then is how does 802.11psm ever put the radio to sleep if there are so many keep alive packets sent from the server.... seems like the first is sent after .5s then 1s then 2s apart... soem sort of exponential function, but still it takes several seconds for it to get to a point where the packets are far enough apart to sleep. – Michael Mar 10 '11 at 04:52
  • I think you have two options, either close the connection and reopen it before sending the content of the buffer, or use UDP (which is connectionless) instead of TCP. Here is an example: http://www.java-samples.com/j2me/udp-datagram-free-j2me-sample-program.htm – Joel Arnold Mar 10 '11 at 20:42
  • @JoelArnold, this answer doesn't explain why the function setKeepAlive(false) is not working.. – Pacerier Jul 25 '12 at 07:16
  • @Pacerier You are right. Looking at it again I would need to see the screenshot of the OP before being able to say anything. The packets are probably not TCP keepalive packets since the default delay should be a minimum of 2 hours... – Joel Arnold Aug 02 '12 at 10:06
0

The intermediate device between the server and the client will also initiate TCP keep-alive,such as firewalls, gatekeepers. it seems that the client cannot prevent TCP keep-alive.

lujiaqiu
  • 1
  • 1
  • TCP keep-alive is optional and needs to be deactivated by default. https://datatracker.ietf.org/doc/html/rfc1122#page-101 – supernova Jun 24 '21 at 10:10
  • I can't open this link，I am using WebSocket based on okhttp, I can’t change the server environment, can the client stop the TCP keep-alive packet sent by the server? thanks for your response. – lujiaqiu Jun 25 '21 at 03:17
  • Try: https://www.rfc-editor.org/rfc/rfc1122.html#page-101 – supernova Jun 28 '21 at 00:31
  • "The intermediate device between the server and the client will also initiate TCP keep-alive" which intermediate devices do this?? – Rick Jones Jun 28 '21 at 00:42
  • For example, GAP will be like this. – lujiaqiu Jun 28 '21 at 06:53
0

Indeed TCP keep alive behaviour depends on the implementation of the TCP stack. Having said this, one should follow the RFC standard. Even if the TCP implementation supports keep-alive, it should default to not using it unless requested on the connection.

See RFC 1122 section 4.2.3.6 "TCP Keep-Alives"

Cite:

Implementors MAY include "keep-alives" in their TCP
implementations, although this practice is not universally
accepted. If keep-alives are included, the application MUST
be able to turn them on or off for each TCP connection, and
they MUST default to off.
supernova
  • 1,762
  • 1
  • 14
  • 31