On 9/15/2017 7:44 AM, Rob McKenna wrote:
Perhaps I'm misunderstanding you here. Can you illustrate this a bit
further?
The basic point is simple: removing the closing blocking even receiving
timeout is not set.
Applications already have to set a read timeout
I did not get the point. Applications don't have to set a read timeout.
Xuelei
, my proposal doesn't
alter this fact. (i.e. if the read timeout isn't set applications which
call close could potentially get stuck in readReply indefinitely)
-Rob
On 15/09/17 07:23, Xuelei Fan wrote:
On 9/15/2017 7:07 AM, Rob McKenna wrote:
But they are inextricably linked regardless.
When we close an SSLSocket it performs a readReply which is subject to
the read timeout. So if no read timeout is specified, the call to
readReply will hang indefinitely.
That's one of what I worried about. Applications have to set receiving
timeout in your proposal. I don't want closing timeout binding to receiving
timeout. It's doable and the impact is minimal.
Xuelei
If a read timeout is specified we
would need to maintain two separate timeouts and take each into account
when polling.
What you are suggesting would effectively necessitate a reimplementation
of the close mechanics discarding the read timeout completely. (which
would be a significant enough change in terms of compatibility)
-Rob
On 13/09/17 03:56, Xuelei Fan wrote:
On 9/13/2017 8:52 AM, Rob McKenna wrote:
W.r.t. a separate timeout, the underlying mechanics of a close already
depend on the readTimeout in this situation.
That's a concerns of mine. In order to work for your countermeasure,
applications have to set receiving timeout, and take care of the closing
timeout when evaluate what's a right timeout value. The mixing could be
misleading and not easy to use.
Xuelei
