[WIP][RFC] Concept for connection timeout

[cboden]

The implementation for a connection timeout. Any connector could use the method internally to create a connection timeout.

[clue]

A huge 👍 on the feature, but a 👎 on the implementation.

As it stands, this implementation doesn't really cancel the connection attempt, it merely discards the resulting connection after the timeout has expired. As such, the event loop keeps waiting for the connection and the socket resource still consumes system resources and network I/O.

This feature sounds like a perfect candidate for cancellable promises. However, its spec is still in draft and hence not yet supported in react/promise (see reactphp/promise#14).

[cboden]

This should be doable now via CancellablePromiseInterface

[WyriHaximus]

@cboden are you planning on updating this PR soon or want me to make a PR to your PR using CancellablePromiseInterface?

[cboden]

@WyriHaximus Help is always welcome :-)

[WyriHaximus]

@cboden alright will look into it :).

[cboden]

Added cancellable. Still WIP, API needs adjusting, needs tests. I'm not sure if the trait belongs in this library, maybe Stream instead as it isn't solely tied to a connecting client.

[clue]

👍 for pushing this forward, though I'm not sure I like the API and how it's intertwined with the "default" Connector.

IMO we should first figure out some use cases for this feature to see how this is actually going to be used.

The socket-client component is quite lowlevel, so it's unlikely to be used by many users directly. It's probably more likely going to be used as part of some high level abstractions (say, a Redis or MySQL client implementation). These high level components depend on a ConnectorInterface and will likely use DI to inject this. They probably care little about how the connector works. Neither should they care about any "additional" parameters. They do care about the target (hostname and port). Hence (IMHO) they should not have to take care of connection timeouts.

I'm not sure if the trait belongs in this library

I agree that this should probably be moved to a new component instead (promise-timeout or just timeout perhaps?).

[Renegade334]

Is much gained from having a default value for $seconds here? Any value is pretty arbitrary.