On Aug 27, 10:06 pm, Mark Hahn <[email protected]> wrote: > I understand your concerns. I'm just surprised that extending the timeout > beyond five minutes would make any difference. Surely your app can refresh > the connection within 5 mins. >
No, we can't do that. As I mentioned, once the app goes into background, it is suspended -- there's absolutely nothing it can do. And there's a good chance that the OS will disconnect the socket. So typically, when the user brings the app into the foreground, we have no choice but to establish a new socket -- and this is where anything that can cut down latency will help. Chaitanya > On Mon, Aug 27, 2012 at 3:44 AM, Chaitanya Gupta > <[email protected]>wrote: > > > > > > > > > On Aug 25, 11:38 pm, Mark Hahn <[email protected]> wrote: > > > What is the "convincing use case"? > > > The objective is to reduce latency. Assume that you have a simple > > request-response protocol where the client sends a message "Ping" in > > response to which the server sends a response "Pong". If client > > doesn't have a prior socket open with the server, how many round-trips > > does it take before the user can see the response "Pong"? > > > For plain TCP sockets, it takes about two round trips: > > > Client Server > > > SYN --------> > > <-------- SYN-ACK > > ACK --------> > > Ping --------> > > <-------- Pong > > > For a full TLS handshake, it takes about four round trips: > > > Client Server > > > SYN --------> > > <-------- SYN-ACK > > ACK --------> > > ClientHello --------> > > ServerHello > > Certificate* > > ServerKeyExchange* > > CertificateRequest* > > <-------- ServerHelloDone > > Certificate* > > ClientKeyExchange > > CertificateVerify* > > [ChangeCipherSpec] --------> > > NewSessionTicket > > <-------- [ChangeCipherSpec] > > Ping --------> > > <-------- Pong > > > For TLS with session resumption, it is three round-trips: > > > Client Server > > > SYN --------> > > <-------- SYN-ACK > > ACK --------> > > (SessionTicket extension) --------> > > ServerHello > > (empty SessionTicket extension) > > NewSessionTicket > > <-------- [ChangeCipherSpec] > > [ChangeCipherSpec] --------> > > Ping --------> > > <-------- Pong > > > Now, assume that this ping-pong protocol that you have invented is for > > a mobile app. Which means that a lot of your users will be accessing > > the app from slow wireless networks like EDGE. From where I live, the > > round-trip time (RTT) on an EDGE network to a server in the US varied > > between 800-900 ms last morning. This works out to the following > > costs just taking into account the RTTs: > > > Plain TCP: 1.6-1.8s > > TLS with handshake: 3.2-3.6s > > TLS with resumption: 2.4-2.7s > > > Nothing beats plain TCP but since we don't want anyone snooping in on > > this traffic we have to use TLS. TLS with session resumption is not > > great but it is still atleast 800-900 ms faster than TLS with full > > handshake. And we haven't even taken into account the bandwidth costs > > yet: assuming ~1500 bytes per certificate and a chain of three certs, > > on a 70 kbps connection you can add another 0.5 seconds to the cost > > for a full TLS handshake (and we have still not looked at > > retransmission costs -- 2.5G/3G networks are quite lossy). > > > Now, the first time a user connects we will have go through the > > complete TLS handshake -- we can't avoid it. But subsequently, the > > costs reduce greatly. You may ask, instead of trying to reconnect, can > > we keep the socket open indefinitely? Sure we can, but if the user is > > on an iOS device, the moment he takes the app into background, two > > things will happen: > > > 1. Your app gets suspended > > 2. Your socket can be torn down by the OS at any time > > > This means that, whenever the user brings your app to the foreground > > again, its quite possible that we will need to establish a new socket. > > And here we would like to reduce the latency as much as possible. > > While the typical user might bring the app into the foreground several > > times a day, he would not do so every five minutes. > > > That is why it would be great if we can extend TLS session timeout. > > While the latency costs are not so visible on a fast fixed line > > connection, they are very much so on slow wireless networks. > > > Thanks, > > Chaitanya > > > > On Sat, Aug 25, 2012 at 11:18 AM, Satyam Shekhar < > > [email protected]>wrote: > > > > > Hi, > > > > > On Sat, Aug 25, 2012 at 5:22 PM, Ben Noordhuis <[email protected]> > > wrote: > > > > >> On Sat, Aug 25, 2012 at 10:52 AM, Chaitanya Gupta > > > >> <[email protected]> wrote: > > > >> > I need to support TLS session resumption in my node.js app. I am > > > >> > creating a TLS server usingrequire('tls').createServer(). By > > default, > > > >> > the server has a session ticket lifetime of 300 seconds (as seen > > with > > > >> > OpenSSL's s_client). > > > > >> > I need the session timeout to be beyond 300 seconds. How can I do > > > >> > this? I couldn't find anything in node's API docs that could help. > > > > >> Node doesn't let you do that. If you have a convincing use case, > > > >> please open an issue and we'll add it. > > > > > I want to contribute this. > > > > > I was thinking of implementing it in one of the following ways - > > > > > 1. > > > > i) Take sessionTimeout as an option to createServer > > > > ii) Expose a method setTimeout on SecureContext in node_crypto.cc which > > > > calls SSL_CTX_set_timeout, and use that to set default session timeout > > for > > > > the context, from the "connection" event callback inside createServer. > > > > > 2. > > > > i) Expose setSessionTimeout on CryptoStream in tls.js which again calls > > > > setSessionTimeout exposed by Connection in node_crypto.cc. This > > > > calls SSL_SESSION_set_timeout to set the timeout for that session. > > Now, the > > > > user can call setSessionTimeout on the exposed CleartextStream to set > > the > > > > timeout. > > > > > What do you think? > > > > > -- satyam > > > > >> -- > > > >> Job Board:http://jobs.nodejs.org/ > > > >> Posting guidelines: > > > >>https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > > > >> You received this message because you are subscribed to the Google > > > >> Groups "nodejs" group. > > > >> To post to this group, send email to [email protected] > > > >> To unsubscribe from this group, send email to > > > >> [email protected] > > > >> For more options, visit this group at > > > >>http://groups.google.com/group/nodejs?hl=en?hl=en > > > > > -- > > > > Job Board:http://jobs.nodejs.org/ > > > > Posting guidelines: > > > >https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > > > > You received this message because you are subscribed to the Google > > > > Groups "nodejs" group. > > > > To post to this group, send email to [email protected] > > > > To unsubscribe from this group, send email to > > > > [email protected] > > > > For more options, visit this group at > > > >http://groups.google.com/group/nodejs?hl=en?hl=en > > > -- > > Job Board:http://jobs.nodejs.org/ > > Posting guidelines: > >https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > > You received this message because you are subscribed to the Google > > Groups "nodejs" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group at > >http://groups.google.com/group/nodejs?hl=en?hl=en -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
