Handle WebSocket handshake timeouts

[shilder]

Added new option handshake-timeout for websocket client

[shilder]

Related to #346 More like request for discussion. Some opened questions

1. Is it ok to use somewhat private method (.in time/*clock*) to schedule timeout handler execution ?
2. There are already couple of specific Exception classes for different timeouts (like ReadTimeoutException and so on). Should i add another class ? Something like WebSocketHandshakeTimeoutException ?

[kachayev]

@shilder Regarding WebSocketHandshakeTimeoutException: 👍. It's better to keep all timeouts separate when possible, so the user can distinguish them somehow later. Subclassing works just fine for that.

[ztellman]

I was trying to figure out why you used the .in accessor here, and realized that manifold.time/in doesn't allow it to be cancelled. That's my bad, I'm going to merge these changes in and then fix the underlying method so we don't have to reach under the covers.

[ztellman]

@kachayev it seems this no longer merges after I brought in the ping functionality, since you have more familiarity with that would you mind getting it into order?

[kachayev]

@ztellman Sure, I'll take care.

[kachayev]

We're not on I/O thread here, so we should probably close the channel, not the context. Right? @ztellman

[kachayev]

One another thing... Maybe it's better to use EventLoop executor to schedule the task (ctx.executor().schedule) instead of manifold's clock? We can also just trigger user event from the runnable and check if the handshake was complete in :user-triggered. It seems like this approach would leave fewer spaces for race conditions. What do you think? @shilder @ztellman

I still wonder why this functionality is not implemented in Netty, e.g. SslHandler supports handshake timeout as a parameter. I'm going to open an issue to start a discussion there.

[shilder]

One another thing... Maybe it's better to use EventLoop executor to schedule the task (ctx.executor().schedule) instead of manifold's clock

Yes, we can use EventExecutor and Netty is using it internally in IdleStateHandler to schedule timeout handlers.

And about :user-triggered - yes, it will work, but I'm not sure how it will help with race conditions ? AFAIU Future#cancel provides synchronization point. Or maybe you are talking about situation where context is closed by timeout handler while another thread awaits on Future#cancel ? I'm not a Netty expert, so I'm not sure how it handles serialization of events for context

[kachayev]

Not only for IdleTimeoutHandler but for all timeout tasks. Future canceling is what I want to avoid here specifically because of a synchronization: it might hurt performance when you introduce sync primitives to the pipeline running on I/O thread.

If you don’t mind, I can update your PR.

[shilder]

If you don’t mind, I can update your PR.

Sure, go ahead

[kachayev]

On it!

[kachayev]

The more I work with this functionality, the more I wonder why don't we use Netty's WebSocket*ProtocolHandler to deal with handshakes? It doesn't support timeouts out of the box (at least for now). Apart from that, it's a well-tested implementation that we can leverage injecting our own handler & realizing deferred with newly created netty/sink on HANDSHAKE_COMPLETE user event triggered by Netty's handler. @ztellman WDYT? Any objections?

[kachayev]

@shilder I've reimplemented timeouts, please double check on your side. Notable changes:

1. Avoid .cancel sync on I/O threads
2. Schedule timeout on I/O threads
3. Schedule timeout only when the handshake was effectively flushed, not before
4. Cancel timeout when processing is done, avoid 2 timeouts

I've also added a test case to check that the solution works. Should we do the same for a server handler?

[kachayev]

From what I can see, there's no necessary to introduce the same for server's handshake, as it's just about flushing response to the client.

@ztellman Now ready for review/merge.

[kachayev]

@ztellman Merged with the latest changes from master, so now it's mergeable.

@shilder I've also moved timeout cancelation to d/finally' instead of d/chain'. Does it make sense?

[ztellman]

This has conflicts with the other WS changes I merged, but will merge once those are resolved.

[kachayev]

@ztellman Done!

[kachayev]

@ztellman Fixed conflicts here.

[kachayev]

I'm going to rebase to 1.0.0 to merge with latest changes there. Substantial portion of the code is intertwined with websockets pipeline changes we've made so far.

[kachayev]

As of now, merging into 1.0.0 branch to accumulate pre-release changes there.