While I recommend actually reading RFC 3080 (it is an easy read), this
summary may help...
Framing: Length prefixed data, nothing unusual.
Encoding: Messages are effectively this:
enum message_type {
message,// a request
reply, // when there's only a single re
Hi Bruce,
Would this RPC protocol take the role of the transport in the Avro
specification or would it replace the protocol? If the handshake
occurs on channel 0 while the request/response payloads are
transferred on a different channel, this would not meet the existing
wire protocol as described
Hi Bo,
Thanks for your feedback!
On Thu, Apr 8, 2010 at 3:49 PM, Bo Shi wrote:
> Hi Bruce,
>
> Would this RPC protocol take the role of the transport in the Avro
> specification or would it replace the protocol? If the handshake
> occurs on channel 0 while the request/response payloads are
> t
Bruce,
Overall this looks like a good approach to me.
How do you anticipate allocating channels? I'm guessing this would be
one per client object, that a pool of open connections to servers would
be maintained, and creating a new client object would allocate a new
channel.
Currently we per
I really like the model that Voldemort uses for their protocol buffers
implementation. I ported their client to .net and it was really
simple. The framing is really simple as it prefixes an integer value
before binary data. The binary data is a request made with a protocol
buffer, and so is the res
Doug,
I'm happy to hear that you like this approach!
Allocation of channels seems to be something specific to an application. In
my app, I'd have a channel for the streaming data that is constantly
arriving and a channel for making requests on and getting back answers
immediately. Others could
On Apr 8, 2010, at 11:35 PM, Bruce Mitchener wrote:
> Doug,
>
> I'm happy to hear that you like this approach!
>
> Allocation of channels seems to be something specific to an application. In
> my app, I'd have a channel for the streaming data that is constantly
> arriving and a channel for mak
On Fri, Apr 9, 2010 at 10:00 AM, Scott Carey wrote:
>
> On Apr 8, 2010, at 11:35 PM, Bruce Mitchener wrote:
>
> > Doug,
> >
> > I'm happy to hear that you like this approach!
> >
> > Allocation of channels seems to be something specific to an application.
> In
> > my app, I'd have a channel for t
On Fri, Apr 9, 2010 at 2:35 AM, Bruce Mitchener
wrote:
> Doug,
>
> I'm happy to hear that you like this approach!
>
> Allocation of channels seems to be something specific to an application. In
> my app, I'd have a channel for the streaming data that is constantly
> arriving and a channel for mak
On Apr 9, 2010, at 11:56 AM, Bo Shi wrote:
> On Fri, Apr 9, 2010 at 2:35 AM, Bruce Mitchener
> wrote:
>> Doug,
>>
>> I'm happy to hear that you like this approach!
>>
>> Allocation of channels seems to be something specific to an application. In
>> my app, I'd have a channel for the streaming
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 t
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.c
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 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.
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 wrote:
> Oh, and it's been partially implemented in Chromium, so there's a
> quasi-reference implementation.
> --
> Jeff
>
> On
What specific changes would you propose making to my proposal?
- Bruce
On Sat, Apr 10, 2010 at 11:57 AM, Jeff Hodges 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
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
wrote:
> What specific changes would you propose making to my proposal?
>
> - Bruce
>
> On Sat, Apr 10, 2010 at 11:57 AM, Jeff Hodges wrote:
Jeff Hodges 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 fo
I hadn't thought of adding SASL to SPDY. I haven't dived into the
community, yet, to see if they've discussed it.
The philosophy behind BEEP seems pretty good, even if the crazy XML
style of the actual spec is not a good match (as put in an earlier
email). The lack of community is worrisome, of co
Er, note that I'm generally lightly positive on using it as a
influence on the protocol, even if portions of the philosophy I find
less than ideal. I mentioned the lack of community because a lack of
active means whatever obstacles occur due to its fundamental nature
aren't well-known and well-def
19 matches
Mail list logo
