RFR [11] 8197564: HTTP Client implementation - JEP 321

[Wenbo Zhu]

On Tue, Mar 27, 2018 at 7:34 PM, James Roper <james at lightbend.com> wrote:

> On 23 March 2018 at 04:36, Wenbo Zhu <wenboz at google.com> wrote:
>>
>> +1
>>
>> Message-based flow-control is unspecified by the websocket protocol; and
>> exposing byte-based flow-control (via RS) as part of the WS API seems a
>> rather questionable approach.
>>
>
> No one is suggesting a byte based flow control mechanism, RS flow control
> is never byte based (unless you use Publisher<Byte>/Subscriber<Byte>, but
> no one ever does that because it's incredibly inefficient). Not even TCP
> supports byte based flow control, it's packet based. I'm not sure why
> you're raising byte based flow control here.
>
Not sure this is the case - TCP does packet based flow-control.  Maybe we
are talking about different things. WS protocol as a L7 protocol has no
concept of flow-control (back-pressure) and this is why I mentioned it has
to be byte-based (or packet-based if such a thing exists).


> The WebSocket protocol does have implied flow control semantics by virtue
> of the fact that it is layered on top of TCP. The current WebSocket API in
> JEP 321 offers frame based flow control using an API very similar to RS,
> which for all intents and purposes, is message based flow control, since
> I've never actually seen, in the wild, fragmented WebSocket messages be
> used. Of course, due to the mismatch of TCP packets, OS buffers and
> WebSocket frames, there is lag in the propagation of flow control while
> buffers fill up, but it is none the less there.
>
> Any useful RS support will have to involve some application-level
>> protocols.
>>
>
> I completely disagree with this statement. As someone who has been
> involved in/led the implementation of multiple WebSocket clients and
> servers (including Play Framework, Lagom Framework and Akka HTTP), I can
> tell you from my experience that after the initial WebSocket handshake,
> WebSockets can be offered to application developers as just streams of
> messages using Reactive Streams, without any additional WebSocket protocol
> exposure, and still be useful for 99% of use cases. It certainly does not
> have to involve exposing the protocol to the application, most applications
> care nothing about message fragmentation, they care nothing about close
> codes or reasons beyond whether the connection was terminated with a
> success or error, and they care nothing about pings/pongs. Everything that
> they do care about, Reactive Streams gives a way of expressing.
>

I don't see the role of RS if the WS wire protocol doesn't support any
signaling for the receiver to notify the sender to "slow down", except to
respect the basic TCP flow-control.

I am reasonably familiar with the IETF WS spec (
https://tools.ietf.org/html/rfc6455) ... and it would be useful if you
could point out how exactly flow-control is supposed to work with RS on top
of Websockets.

Thanks.


> > with the understanding that such a helper will limit the capabilities
>>> and performance when its used - eg, the range of options for closing, range
>>> of options for how errors are handled, and perhaps introduce some small
>>> performance penalties such as additional allocations and/or buffer copies.
>>>
>>> That is a whole set of comprises and decisions that would need to
>>> be considered.
>>>
>>> > The use case here is how well this API will interact with other APIs.
>>> WebSockets are rarely used in isolation from other technologies. Most non
>>> trivial usages of WebSockets will involve plumbing the WebSocket API to
>>> some other source or sink of streaming data - for example, a message
>>> broker, a database, perhaps a gRPC stream to another service.
>>>
>>> I could well image a set of vertical-market specific libraries being
>>> built
>>> on top of the WebSocket API, and that is how it should be. In this
>>> specific area, providing the lowest level API is an enabler for others.
>>>
>>> > The question is, how difficult will it be to connect those two APIs?
>>>
>>> I imagine some work may be required, but certainly much less than
>>> without the WebSocket API.
>>>
>>> > Will their backpressure mechanisms map to each other easily?
>>>
>>> I see no reason that it should not. Are you aware of any?
>>>
>>> >  Will their failure handling and error handling semantics map to each
>>> other easily?
>>>
>>> I see no reason that they should not. In fact, most higher-level APIs
>>> provide more coarse grain error handling.
>>>
>>> > How many lines of boilerplate will it take to hook them up?
>>>
>>> I guess that depends on the particular library's functionality, will it
>>> support/handle/expose partial message delivery, buffering, etc. I
>>> don’t see this as boilerplate though.
>>>
>>> > If the WebSocket provides an option to use Reactive Streams, then for
>>> any other sources/sink of streamed data that support Reactive Streams,
>>> application developers will have an option where the answers are guaranteed
>>> to be yes without the developer having to do any mapping themselves, and
>>> the lines of code to do that will be one.
>>>
>>> Sure, if one has a higher-level library that works with Reactive Streams,
>>> and one wants to use WebSocket as a transport, then it would be little
>>> work if Java SE provided a Reactive Streams interface to WebSocket.
>>> There are also vertical-markets using WebSocket, but not using Reactive
>>> Streams.
>>>
>>> At this point in JEP 321, I do not want to increase the scope of the
>>> project
>>> to include a Reactive Streams interface for WebSocket. This is something
>>> that can, and should, be considered separate to JEP 321. It could follow
>>> in a future release if deemed appropriate, or not, but adding it at this
>>> point
>>> will add risk to JEP 321, which I am not willing to do.
>>>
>>> -Chris.
>>>
>>>
>>
>
>
> --
> *James Roper*
> *Senior Octonaut*
>
> Lightbend <https://www.lightbend.com/> – Build reactive apps!
> Twitter: @jroper <https://twitter.com/jroper>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20180328/66a5c3cb/attachment.html>