Home | About | Sematext search-lucene.com search-hadoop.com
 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
+
Jeff Hodges 2010-04-10, 17:53
+
Jeff Hodges 2010-04-10, 17:57
+
Bruce Mitchener 2010-04-10, 17:59
Copy link to this message
-
Re: Thoughts on an RPC protocol
Jeff Hodges 2010-04-10, 18:08
I may have misunderstood the direction this thread had taken. I'm
still going through the spec.
--
Jeff

On Sat, Apr 10, 2010 at 10:59 AM, Bruce Mitchener
<[EMAIL PROTECTED]> wrote:
> 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
>> >>>
>> >>
>> >
>>
>
+
Doug Cutting 2010-04-12, 20:46
+
Jeff Hodges 2010-04-12, 21:48
+
Jeff Hodges 2010-04-12, 21:58