Ah, right! This is the part I was missing.
So my fix is intended to address this specific circumstance only (where
we get caught in the while loop in waitForClose() indefinitely despite
having set a read timeout). In this situation it would be reasonable for
somebody to set a read timeout in the hope that the close() call would
not hang indefinitely. Unfortunately due to the while loop in
waitForClose it does regardless. (hence my assertion that applications
already have to set a read timeout to attempt to avoid this situation)
So you're suggesting that we take the read timeout out of the close
mechanics completely and replace it with something more appropriate?
Given that closing an SSLSocket requires a read operation in order to
receive the close_notify though, I'm not sure how to accomplish that.
Can you go into a little bit more detail?
-Rob
On 15/09/17 07:57, Xuelei Fan wrote:
> 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
