0

I'm writing a client using AsyncHttpClient (AHC) v2.0beta (using Netty 4 as a provider) that streams audio in real-time and it needs to receive server data in real-time too (while streaming). Imagine a HTTP client streaming the microphone's output as the user speaks and receiving the audio transcription has it happens in real time. In short, it's a bidirectional real-time communication over HTTP (chunked multipart request/response).

In order to do that, I had to hack AHC a bit. For instance, there is a blocking call to wait for input data in org.asynchttpclient.multipart.MultipartBody#read(ByteBuffer buffer) which is implemented on top of Netty's io.netty.handler.stream.ChunkedInput.

This somewhat works. The problem is that my custom AsyncHandler will not get onBodyPartReceived() callbacks until the request has finished streaming. They receiving events get pilled up, probably because Netty isn't reading while there is still content to write. Playing with the network stack, I noticed I was only able to receive server responses while streaming if the client was having network contention while writing.

Can someone tell me if this behavior is the result of my particular implementation (blocking in MultipartBody#read()) or an architectural design constrain imposed by Netty's internal implementation?

As a side note, reading and writing happens inside a single IO thread nioEventLoopGroup-X.

FabienB
  • 1,104
  • 2
  • 11
  • 22
  • You may want to look into websockets, they are designed with async processing in mind, unlike http, what can flow over proxies and those proxies may not support bidirectional communication – Ferrybig Mar 23 '16 at 11:50
  • @Ferrybig That's a good remark. WebSocket is another interface we support more suited for this kind of use case. HTTP is a supported interface. I can't get around this: business requirement. – FabienB Mar 23 '16 at 13:01
  • Receiving while the client is sending is not supported in http, and thus only exists as a hack. Are you allowed to use 2 connections/requests? 1 for sending, the other for receiving – Ferrybig Mar 23 '16 at 13:06
  • Another solution might be rolling your own "not really http" stack using sockets, and use that for your streaming requirements – Ferrybig Mar 23 '16 at 13:13
  • @Ferrybig I agree that's it's kind of a hack over the Request/Response design of HTTP. I'm not allowed to use two connections. I've already explored using sockets and it works. I loose all the advantages of a HTTP client library and the existing code around it. I'd rather have a way to make Netty be more "aggressive" when it comes to reading even if content is still left to write and keep the existing architecture intact. – FabienB Mar 23 '16 at 15:06

0 Answers0