Netty/HTTP (Server) Implementation

[vjn]

I'm filing this since the reactivesocket-http-netty repository isn't present. I'm working on an HTTP (1.1 will do; 2 will be more efficient) implementation described below, wanted to get feedback on the approach.

• Browser JS clients are to be supported in addition to ones built with other stacks.
• Reactive Socket protocol bytes are sent/received as-is over HTTP.
• Client-to-server messages are sent using POST. (Batching will be allowed, but streaming is not possible since browser support does not yet exist.)
• Server to client messages are streamed as-is in the response.
• In both cases, the encoding is application/octet-stream.

[NiteshKant]

My $0.02

ReactiveSocket is a stateful protocol built on top of a long-lived, full-duplex connection which provides a very "conversational" interaction. Few of the benefits of such an interaction are:

• Bi-directional flow control: request-n down and onNext up.
• Stream cancellation (unsubscription)
• Request Leasing.
• Stream multiplexing on the same connection.

None of the above can be achieved via a stateless, uni-directional (post initial request) protocol such as HTTP/1.1. So, it is not so much about efficiency in this case but just lack of features when running ReactiveSocket over HTTP/1.1.
Running ReactiveSocket in such a degraded mode IMHO doesn't add value. What you are trying to achieve can very much be achieved via HTTP chunking (primarily the streamed responses) and you do not need ReactiveSocket.

[vjn]

@NiteshKant, it'd be nice to have the same API, regardless of transport. I believe all of those benefits can be had in HTTP/2. If things can be made to work with 1.1, even if less efficiently, why not? HTTP/1.1 does not have stream multiplexing, of course, but request(n) and cancellation can be made to work.

[NiteshKant]

request(n) and cancellation requires signal from the client post request send i.e. interleaved with response stream. How would that work with HTTP/1.1?

[vjn]

In the case of HTTP/1.1, a second connection would be required to send the POST, since the original response will be long-running, and kept open.

[NiteshKant]

Alright. I will be eager to hear others opinion around here but managing state across different connections IMO gets a bit ugly. YMMV

[stevegury]

HTTP/1 is probably usable if you control the network topology (e.g. guarantee that there isn't any HTTP proxy). But HTTP/2 would definitely be a better fit.

[lehecka]

to @stevegury: I am assuming that you are talking about the case when there is a HTTP proxy, which doesn't understand SSE, buffers the traffic from server to client. Then the response stream from server to client will not flow. Is that what you meant?

[stevegury]

Yes + the fact that if you use two connections, they may not reach the same server.

[vjn]

True. I think that complication about the connections not reaching the same back-end server on account of load-balancing is a deal-breaker for HTTP/1.1 in common cases. (I do have an example in mind where this wouldn't be a problem.) So agree, @NiteshKant.

[robertroeser]

If there's nothing else I recommend closing the issue.

[vjn]

Agree, closing the issue.