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 Plain View
Avro >> mail # dev >> Thoughts on an RPC protocol


+
Bruce Mitchener 2010-04-07, 22:13
+
Bruce Mitchener 2010-04-08, 15:54
+
Bo Shi 2010-04-08, 21:49
+
Bruce Mitchener 2010-04-08, 22:19
+
Doug Cutting 2010-04-08, 22:43
+
Jeremy Custenborder 2010-04-09, 01:29
+
Bruce Mitchener 2010-04-09, 06:35
+
Scott Carey 2010-04-09, 16:00
+
Bruce Mitchener 2010-04-09, 16:16
+
Bo Shi 2010-04-09, 18:56
+
Scott Carey 2010-04-09, 20:54
+
Doug Cutting 2010-04-09, 21:29
+
Jeff Hodges 2010-04-10, 17:48
Copy link to this message
-
Re: Thoughts on an RPC protocol
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
>>
>
+
Jeff Hodges 2010-04-10, 17:57
+
Bruce Mitchener 2010-04-10, 17:59
+
Jeff Hodges 2010-04-10, 18:08
+
Doug Cutting 2010-04-12, 20:46
+
Jeff Hodges 2010-04-12, 21:48
+
Jeff Hodges 2010-04-12, 21:58
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