Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Avro, mail # dev - Thoughts on an RPC protocol


Copy link to this message
-
Re: Thoughts on an RPC protocol
Bruce Mitchener 2010-04-10, 17:59
What specific changes would you propose making to my proposal?

 - Bruce

On Sat, Apr 10, 2010 at 11:57 AM, Jeff Hodges <[EMAIL PROTECTED]> wrote:

> Sorry for the spam. Python, java and apache httpd implementations
> listed at the project page: http://www.chromium.org/spdy
>
> On Sat, Apr 10, 2010 at 10:53 AM, Jeff Hodges <[EMAIL PROTECTED]> wrote:
> > Oh, and it's been partially implemented in Chromium, so there's a
> > quasi-reference implementation.
> > --
> > Jeff
> >
> > On Sat, Apr 10, 2010 at 10:48 AM, Jeff Hodges <[EMAIL PROTECTED]>
> wrote:
> >> To throw another set of ideas into the hat, SPDY[1][2] would be good
> >> to learn from. SPDY takes the basics of HTTP and makes them fast.
> >> Benefits we would enjoy include:
> >>
> >> * Multiplexed streams
> >> * Request prioritization
> >> * HTTP header compression
> >> * Server push
> >>
> >> Currently in draft form.
> >>
> >> [1] http://dev.chromium.org/spdy/spdy-whitepaper
> >> [2] http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2
> >> --
> >> Jeff
> >> On Fri, Apr 9, 2010 at 2:29 PM, Doug Cutting <[EMAIL PROTECTED]>
> wrote:
> >>> Scott Carey wrote:
> >>>>
> >>>> I also have not wrapped my head around routing/proxy use cases.  From
> >>>> a somewhat ignorant perspective on them -- I'd rather have a solid
> >>>> point-to-point protocol that just works, is simple, and can meet the
> >>>> vast majority of use cases with high performance than one that
> >>>> happens to be capable of sophisticated routing but has a lot of other
> >>>> limitations or is a lot harder to implement and debug.
> >>>
> >>> FWIW, they're theoretical at this point.  I was only stating that
> prefixing
> >>> every request and response with handshakes makes stuff like proxies
> trivial,
> >>> since the protocol becomes stateless.  Once we start having sessions
> things
> >>> get trickier.  For example, many HTTP client libraries cache
> connections,
> >>> so, if you're building on top of one of those, it's hard to know when a
> new
> >>> connection is opened.
> >>>
> >>> One approach is to declare that the current framing and handshake rules
> only
> >>> apply to HTTP, currently our only standard transport.  Then we can
> define a
> >>> new transport that's point-to-point, stateful, etc. which may handle
> framing
> >>> and handshakes differently.  Thus we can retain back-compatibility.
>  Make
> >>> sense?
> >>>
> >>> Doug
> >>>
> >>
> >
>