Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
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
> >>>
> >>
> >
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB