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
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
>