0

I would like to create a mechanism to allow clients to subscribe to the contents of a blob-storage bucket.

Traditionally (HTTP 1.1) this would involve polling for new items, then issuing a GET requests for each item.

Mechanisms such as gRPC allow responses to be streamed, however that particular mechanism relies on messages being loaded into memory, limiting incoming messages to a few MB.

Does a "push" mechanism exist that would allow a server to transmit larger payloads to clients without requiring the client to request that specific payload?

Andy N
  • 1,238
  • 1
  • 12
  • 30
  • You should be able to send large files from server to client using a streaming service. What problem are you having exactly? To make sure we're talking about the same thing, gRPC does not use QUIC, it's HTTP/2 over TCP. – drfloob Nov 09 '22 at 18:54
  • I'm trying to identify a mechanism that will allow me to push large payloads. Searches for "gRPC max message size" led me to believe that gRPC was not the correct tool for the job. Or that doing so would require chunking. Therefore my attention turned to QUIC. Perhaps I've dismissed gRPC to quickly. Have I? – Andy N Nov 10 '22 at 15:52
  • QUIC is a transport protocol, similar to TCP. So it's a bit strange that you consider QUIC as an alternative for gRPC. It would make more sense to investigate if HTTP2 or HTTP3 server-push provide what you need. – Peter Nov 12 '22 at 17:38
  • @Peter - QUIC is tough to compare like-for-like as it works across multiple OSI layers. It's on my radar as its UDP-based. It seemed to check all the boxes (in theory) for "pushing" streams of data. I wasn't sure if HTTP3 was the only-show-in-town for QUIC. I haven't properly evaluated server-push. I was put off by lack of uptake and talk of deprecation. I'll give it another look - thanks! – Andy N Nov 14 '22 at 11:23

0 Answers0