Setting SO_TIMEOUT on client socket channel

["이희승 (Trustin Lee)"]

OK. What value are you exactly setting as SO_TIMEOUT? By default, Netty 
sets SO_TIMEOUT to 1 second already.

chudak wrote:
 > We aren't talking about the success rate of the deliveries...we are 
talking
 > about the client connection hanging indefinitely when it is not 
getting tcp
 > acks back from the server. We've found that in the case that we can setup
 > the tcp connection but the data packets are not getting through that tcp
 > will keep trying to retransmit every 2 minutes...and then the OS will
 > finally time the connection out after 15 minutes. This is much to long to
 > hang around with a failed connection.
 >
 > We've found that if we set the SO_TIMEOUT on the underlying socket 
that it
 > correctly times out the connection if it can't read any data after the
 > timeout period. We are only able to do this because we had to extend 
the OIO
 > code to be able to inject a socket factory so we can handle SSL. To solve
 > the above we've also had to add another wrapper around our socket 
factories
 > that injects the SO_TIMEOUT, which is just another hack. It seems 
like this
 > should be supported by the framework.
 >
 >
 > Trustin Lee wrote:
 >> As far as I know, SO_TIMEOUT does not affect the success rate of packet
 >> deliveries. It just tells how soon socket read() should return before it
 >> receives data so that the application can do something else till the
 >> next read() attempt.
 >>
 >> Netty uses SO_TIMEOUT internally to check if there is any pending
 >> setInterestOps() request every second.
 >>
 >> HTH
 >>
 >> chudak wrote:
 >> > There doesn't appear to be any way to do this. We can set the connect
 >> timeout
 >> > by using the options method of the client bootstrap, e.g.:
 >> >
 >> > bootstrap.setOption("connectTimeoutMillis", 30);
 >> >
 >> > We can also set other socket options, e.g.:
 >> >
 >> > bootstrap.setOption("tcpNoDelay", true);
 >> >
 >> > We are running our netty client on a mobile device and in low network
 >> > coverage situations where we are getting lots of packet loss,
 >> especially
 >> > during the SSL handshake, the connection hangs indefinitely.
 >> >
 >> > Any reason this isn't supported, especially for OIO?
 >> >
 >> >
 >> >
 >> > --
 >> > View this message in context:
 >> 
http://netty-forums-and-mailing-lists.685743.n2.nabble.com/Setting-SO-TIMEOUT-on-client-socket-channel-tp6938557p6938557.html
 >> > Sent from the Netty User Group mailing list archive at Nabble.com.
 >> > _______________________________________________
 >> > netty-users mailing list
 >> > netty-users at .jboss
 >> > https://lists.jboss.org/mailman/listinfo/netty-users
 >>
 >> _______________________________________________
 >> netty-users mailing list
 >> netty-users at .jboss
 >> https://lists.jboss.org/mailman/listinfo/netty-users
 >>
 >
 >
 > --
 > View this message in context: 
http://netty-forums-and-mailing-lists.685743.n2.nabble.com/Setting-SO-TIMEOUT-on-client-socket-channel-tp6938557p6941181.html
 > Sent from the Netty User Group mailing list archive at Nabble.com.
 > _______________________________________________
 > netty-users mailing list
 > netty-users at lists.jboss.org
 > https://lists.jboss.org/mailman/listinfo/netty-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20111028/bc9ea10f/attachment.html