Connectiontimeout Versus Sockettimeout

ConnectionTimeout versus SocketTimeout

A connection timeout occurs only upon starting the TCP connection. This usually happens if the remote machine does not answer. This means that the server has been shut down, you used the wrong IP/DNS name, wrong port or the network connection to the server is down.

A socket timeout is dedicated to monitor the continuous incoming data flow. If the data flow is interrupted for the specified timeout the connection is regarded as stalled/broken. Of course this only works with connections where data is received all the time.

By setting socket timeout to 1 this would require that every millisecond new data is received (assuming that you read the data block wise and the block is large enough)!

If only the incoming stream stalls for more than a millisecond you are running into a timeout.

What is the difference between connection and read timeout for sockets?

1. What is the difference between connection and read timeout for sockets?

The connection timeout is the timeout in making the initial connection; i.e. completing the TCP connection handshake. The read timeout is the timeout on waiting to read data¹. If the server (or network) fails to deliver any data <timeout> seconds after the client makes a socket read call, a read timeout error will be raised.

2. What does connection timeout set to "infinity" mean? In what situation can it remain in an infinitive loop? and what can trigger that the infinity-loop dies?

It means that the connection attempt can potentially block for ever. There is no infinite loop, but the attempt to connect can be unblocked by another thread closing the socket. (A Thread.interrupt() call may also do the trick ... not sure.)

3. What does read timeout set to "infinity" mean? In what situation can it remain in an infinite loop? What can trigger that the infinite loop to end?

It means that a call to read on the socket stream may block for ever. Once again there is no infinite loop, but the read can be unblocked by a Thread.interrupt() call, closing the socket, and (of course) the other end sending data or closing the connection.

---

^{1 - It is not ... as one commenter thought ... the timeout on how long a socket can be open, or idle.}

Connection timeout and socket timeout advice

There's no reason whatsoever why they should be equal. Considering each condition separately, you want to set it high enough that a timeout will indicate a genuine problem rather than just a temporary overload, and low enough that you maintain responsiveness of the application.

As a rule, 40 seconds is far too long for a connect timeout. I would view anything in double figures with suspicion. A server should be able to accept tens or hundreds of connections per second.

Read timeouts are a completely different matter. The 'correct' value, if there is such a thing, depends entirely on the average service time for the request and on its variance. As a starting point, you might want to set it to double the expected service time, or the average service time plus two or three standard deviations, depending entirely on your service level requirements and the performance of your server and its variance. There is no hard and fast rule about this. Many contractual service level agreements (SLAs) specify a 'normal' response time of two seconds, which may inform your deliberations. But it's your decision.

HttpClient 4.3.5 ConnectionRequestTimeOut vs ConnectTimeout for HttpConnectionParams.setConnectionTimeout in 4.0.1

In version 4.3 of Apache Http Client the configuration was refactored (again).
the new way as the following code:

RequestConfig requestConfig =RequestConfig.custom()
.setConnectTimeout(connectTimeout)
.setConnectionRequestTimeout(connectionRequestTimeout)
.setSocketTimeout(socketTimeout).build();

connectTimeout is the timeout until a connection with the server is established. connectionRequestTimeout is used when requesting a connection from the connection manager.

Connection and connection request timeout

HttpClient has a way to set connection and socket timeout (setConnectionTimeout() and setTimeout()) according to the HttpClient javadocs.

Connection timeout is the timeout until a connection with the server is established.

Socket timeout is the timeout to receive data (socket timeout).

Example:

Let's say you point your browser to access a web page. If the server does not anwser in X seconds, a connection timeout will occur. But if it establishes the connection, then the server will start to process the result for the browser. If it does not ends this processing in Y seconds, a socket timeout will occur.

What's the difference between loginTimeout, connectTimeout and socketTimeout in pgjdbc

As documented in the PostgreSQL JDBC documentation:

• loginTimeout = int

  Specify how long to wait for establishment of a database connection.
  The timeout is specified in seconds.

• connectTimeout = int

  The timeout value used for socket connect operations. If connecting
  to the server takes longer than this value, the connection is broken.
  The timeout is specified in seconds and a value of zero means that it
  is disabled.

• socketTimeout = int

  The timeout value used for socket read operations. If reading from
  the server takes longer than this value, the connection is closed.
  This can be used as both a brute force global query timeout and a
  method of detecting network problems. The timeout is specified in
  seconds and a value of zero means that it is disabled.

• cancelSignalTimeout = int

  Cancel command is sent out of band over its own connection, so
  cancel message can itself get stuck. This property controls "connect
  timeout" and "socket timeout" used for cancel commands. The timeout is
  specified in seconds. Default value is 10 seconds.

The connectTimeout and socketTimeout are timeouts on low-level socket operations. The connectTimeout governs the time needed to establish a TCP socket connection. Establishing a TCP connection doesn't guarantee a login (it doesn't even guarantee that you're connecting to a PostgreSQL server, just that you connected to something that accepted your TCP connection). A socketTimeout governs the time a socket can be blocked waiting to read from a socket. This involves all reads from the server, not just during connect, but also during subsequent interaction with the server (eg executing queries).

On the other hand loginTimeout governs the PostgreSQL protocol operation of connecting and authenticating to the PostgreSQL server. This involves establishing a TCP connection followed by one or more exchanges of packets for the handshake and authentication to the PostgreSQL server (I'm not familiar with the details of the PostgreSQL protocol, so I can't be very specific).

Exchanging these packets can take additional time, or if you connected to something that isn't a PostgreSQL server the packet exchange may stall. It might be possible to solve this with careful control of both connectTimeout and socketTimeout, but there are no guarantees (eg data is being exchanged, but the login never completes). In addition, as the socketTimeout also governs all other operations on the connection, you may want to set it higher (eg for other operations that take a long time to get a response back) than you are willing to wait for the login to complete.

The cancelSignalTimeout is used as the connect and socket timeout of the separate TCP connection used for cancel commands.

What is a connection timeout during a http request

I will try to answer it a little bit more informally.

Connection timeout - is a time period within which a connection between a client and a server must be established. Suppose that you navigate your browser (client) to some website (server). What happens is that your browser starts to listen for a response message from that server but this response may never arrive for various reasons (e.g. server is offline). So if there is still no response from the server after X seconds, your browser will 'give up' on waiting, otherwise it might get stuck waiting for eternity.

Request timeout - as in the previous case where client wasn't willing to wait for response from server for too long, server is not willing to keep unused connection alive for too long either. Once the connection between server and client has been established, client must periodically inform server that it is still there by sending information to that server. If client fails to send any information to server in a specified time, server simply drops this connection as it thinks that client is no longer there to communicate with it (why wasting resources meaninglessly).

Time to live (TTL) - is a value specified inside of a packet that is set when the packet is created (usually to 255) that tells how long the packet can be left alive in a network. As this packet goes through the network, it arrives at routers that sit on the path between the packet's origin and its destination. Each time the router resends the packet, it also decrements its TTL value by 1 and if that value drops to 0, instead of resending the packet, router simply drops it as the packet is not supposed to live any longer. This mechanism is used to prevent network from flooding by data as each packet can live inside of it for only limited amount of 'time'.

Redis client Lettuce command timeout versus socket timeout

In socket options you specify connect timeout. This is a maximum time allowed for Redis client (Lettuce) to try to establish a TCP/IP connection to a Redis Server. This value should be relatively small (e.g. up to 1 minute).

If client could not establish connection to a server within 1 minute I guess it's safe to say server is not available (server is down, address/port is wrong, network security like firewalls prohibit connection etc).

The command timeout is completely different. Once connection is established, client can send commands to the server. It expects server to respond to those command. The timeout configures for how long client will be waiting for a response to a command from the server.

I think this timeout can be set to a bigger value (e.g a few minutes) in case client command sends a lot of data to the server and it takes time to transfer and store so much data.

---

Related Topics