In this introduction article: http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html
It states that reasons for TCP keep alive are:
Preventing disconnection due to network inactivity
Detect dead peers
So in my application, there is a busy TCP socket. Packets are frequently sent back and forth between the two peers - so there is a good amount of packets with ACK flag set.
The application protocol uses other means for dead peer detection.
Is TCP keepalive still necessary for the case above?
No. TCP keepalive is practically a 0 byte-long tcp packet. If you can be sure on your app protocol, it is unneeded.
Related
As socks5 rfc says,
A UDP association terminates when the TCP connection
that the UDP ASSOCIATE request arrived on terminates.
I wonder, doesn't "the TCP connection that the UDP ASSOCIATE request arrived on" just terminate when it timeouts? As there is no more data need to be sent in that TCP connection.
Should the client send meaningless data in that TCP connection just to keep it alive while it need the UDP association?
I wonder, doesn't "the TCP connection that the UDP ASSOCIATE request arrived on" just terminate when it timeouts?
No. The TCP connection is kept alive as a signal that the proxied UDP socket is still valid. Without it the client has no way of knowing whether the server is still reachable or whether the UDP socket is still allocated.
Similarly, without the TCP connection the server has no other way of knowing whether the client is still connected.
Should the client send meaningless data in that TCP connection just to keep it alive while it need the UDP association?
There's no need to send meaningless data. Just keep the connection alive. TCP has a built-in keepalive mechanism which can be turned on.
Edit: It's worth pointing out that the default TCP keepalive times on both Linux and Windows is fairly long. See this question on ways of tweaking it for specific sockets.
I have the following queries:
1) Does TCP guarantee delivery of packets and thus is thus application level re-transmission ever required if transport protocol used is TCP. Lets say I have established a TCP connection between a client and server, and server sends a message to the client. However the client goes offline and comes back only after say 10 hours, so will TCP stack handle re-transmission and delivering message to the client or will the application running on the server need to handle it?
2) Related to the above question, is application level ACK needed if transport protocol is TCP. One reason for application ACK would be that without it, the application would not know when the remote end received the message. Is there any reason other than that? Meaning is the delivery of the message itself guaranteed?
Does TCP guarantee delivery of packets and thus is thus application level re-transmission ever required if transport protocol used is TCP
TCP guarantees delivery of message stream bytes to the TCP layer on the other end of the TCP connection. So an application shouldn't have to bother with the nuances of retransmission. However, read the rest of my answer before taking that as an absolute.
However the client goes offline and comes back only after say 10 hours, so will TCP stack handle re-transmission and delivering message to the client or will the application running on the server need to handle it?
No, not really. Even though TCP has some degree of retry logic for individual TCP packets, it can not perform reconnections if the remote endpoint is disconnected. In other words, it will eventually "time out" waiting to get a TCP ACK from the remote side and do a few retries. But will eventually give up and notify the application through the socket interface that the remote endpoint connection is in a dead or closed state. Typical pattern is that when a client application detects that it lost the socket connection to the server, it either reports an error to the user interface of the application or retries the connection. Either way, it's application level decision on how to handle a failed TCP connection.
is application level ACK needed if transport protocol is TCP
Yes, absolutely. Most client-server protocols has some notion of a request/response pair of messages. A TCP socket can only indicate to the application if data "sent" by the application is successfully queued to the kernel's network stack. It provides no guarantees that the application on top of the socket on the remote end actually "got it" or "processed it". Your protocol on top of TCP should provide some sort of response indication when ever a message is processed. Use HTTP as a good example here. Imagine if an application would send an HTTP POST message to the server, but there was not acknowledgement (e.g. 200 OK) from the server. How would the client know the server processed it?
In a world of Network Address Translators (NATs) and proxy servers, TCP connections that are idle (no data between each other) can fail as the NAT or proxy closes the connection on behalf of the actual endpoint because it perceives a lack of data being sent. The solution is to have some sort of periodic "ping" and "pong" protocol by which the applications can keep the TCP connection alive in the absences of having no data to send.
I'm new to socket programming. I am wondering what is the internet and hardware overhead of create a TCP connection and let it be idle?
For example, There are1000 clients, each creates a tcp connection to a single server and after tcp connection established, at this point what is the internet or hardware overhead?
There is a 3-way TCP handshake that takes place to establish a TCP connection.
After the connection has been established, the only data that flows through the connection is what the applications send and, if enabled, TCP keep-alives (TCP segment with 0 payload).
Cannot understand the philosophy of setKeepAlive method in Node.js' net sockets. What happens after initialDelay finishes?
This method controls TCP keep-alive functionality on the underlying TCP socket. Check out this article for information on TCP Keepalive. Here's a snippet that explains what initialDelay (the "keepalive timer") does:
2.1. What is TCP keepalive?
The keepalive concept is very simple: when you set up a TCP connection, you associate a set of timers. Some of these timers deal with the keepalive procedure. When the keepalive timer reaches zero, you send your peer a keepalive probe packet with no data in it and the ACK flag turned on. You can do this because of the TCP/IP specifications, as a sort of duplicate ACK, and the remote endpoint will have no arguments, as TCP is a stream-oriented protocol. On the other hand, you will receive a reply from the remote host (which doesn't need to support keepalive at all, just TCP/IP), with no data and the ACK set.
If you receive a reply to your keepalive probe, you can assert that the connection is still up and running without worrying about the user-level implementation. In fact, TCP permits you to handle a stream, not packets, and so a zero-length data packet is not dangerous for the user program.
This procedure is useful because if the other peers lose their connection (for example by rebooting) you will notice that the connection is broken, even if you don't have traffic on it. If the keepalive probes are not replied to by your peer, you can assert that the connection cannot be considered valid and then take the correct action.
First of all, is there any problem with using both UDP and TCP on the same server?
Secondly, can I use the same port number?
Yes, you can use the same port number for both TCP and UDP. Many protocols already do this, for example DNS works on udp/53 and tcp/53.
Technically the port pools for each protocol are completely independent, but for higher level protocols that can use either TCP or UDP it's convention that they default to the same port number.
When writing your server, bear in mind that the sequence of events for a TCP socket is much harder than for a UDP socket, since as well as the normal socket and bind calls you also have to listen and accept.
Furthermore that accept call will return a new socket and it's that socket that you'll then have to also poll for receive events. Your server should be prepared to continue accepting connections on the original socket whilst simultaneously servicing multiple clients each of which will be triggering receive events on their own sockets.
Firstly,there is no problem using both tcp and udp on the server.
Secondly,we can have both UDP and TCP requests on same port ,because each request is identified by a quintuple contained by source IP ,Destination IP, Source Port, Destination Port, PROTOCOL(as protocol can be TCP or UDP).