Avro
  1. Avro
  2. AVRO-334

If possible, do not close the socket after every request in sample_ipc_server.py

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: python
    • Labels:
      None

      Issue Links

        Activity

        Hide
        Jeff Hammerbacher added a comment -

        Moved Avro's RPC to HTTP and removed sample_ipc_server.py, rendering this ticket obsolete.

        Show
        Jeff Hammerbacher added a comment - Moved Avro's RPC to HTTP and removed sample_ipc_server.py, rendering this ticket obsolete.
        Hide
        Doug Cutting added a comment -

        > the focus should just be on good documentation and testing for running Avro RPC over arbitrary transports.

        Yes, I agree, that's a good short-term focus. The spec currently defines the binary format of requests and responses. But to test compatibility of implementations we need a wire protocol. Rather than use a TCP socket-based protocl for this interoperability testing I think we're better off using HTTP for now, since it's well specified and has conforming implementations. The topic of this bug illustrates this: HTTP has explicit rules about keep-alive, while our not-yet-fully-specified TCP socket protocol does not. Our time is better spent, in the short-term, ensuring interoperability than fully-specifying a TCP socket protocol.

        Long-term, our goal is to have a high-performance, standard wire protocol for Avro RPC, so that clients and services in different languages and from different institutions can interact. HTTP gives us a standard wire protocol, but there are concerns its performance, lack of multiplexing, and the appropriateness of its security. Until we develop a protocol that addresses these, we should only describe HTTP in the spec and we should use HTTP for interoperability testing, lest we end up with a hodge-podge of incompatible legacy protocols that folks might expect us to support forever.

        Show
        Doug Cutting added a comment - > the focus should just be on good documentation and testing for running Avro RPC over arbitrary transports. Yes, I agree, that's a good short-term focus. The spec currently defines the binary format of requests and responses. But to test compatibility of implementations we need a wire protocol. Rather than use a TCP socket-based protocl for this interoperability testing I think we're better off using HTTP for now, since it's well specified and has conforming implementations. The topic of this bug illustrates this: HTTP has explicit rules about keep-alive, while our not-yet-fully-specified TCP socket protocol does not. Our time is better spent, in the short-term, ensuring interoperability than fully-specifying a TCP socket protocol. Long-term, our goal is to have a high-performance, standard wire protocol for Avro RPC, so that clients and services in different languages and from different institutions can interact. HTTP gives us a standard wire protocol, but there are concerns its performance, lack of multiplexing, and the appropriateness of its security. Until we develop a protocol that addresses these, we should only describe HTTP in the spec and we should use HTTP for interoperability testing, lest we end up with a hodge-podge of incompatible legacy protocols that folks might expect us to support forever.
        Hide
        Ryan King added a comment -

        Doug-

        I'm fine with limiting the spec and official implementations to http-only for now, but it seems likely that we'll end up building or porting one with TCP sockets (and maybe a UDP one too).

        Show
        Ryan King added a comment - Doug- I'm fine with limiting the spec and official implementations to http-only for now, but it seems likely that we'll end up building or porting one with TCP sockets (and maybe a UDP one too).
        Hide
        Chad Harrington added a comment -

        We also will only use TCP sockets, due to our performance needs. However, if it is simple and well-supported to use Avro over our own transport, that is probably best, since we are equally unlikely to use the stock Avro TCP socket implementation. We need the performance and control of our own optimized network stack. I am guessing there are lots of people like us, so perhaps the focus should just be on good documentation and testing for running Avro RPC over arbitrary transports.

        Show
        Chad Harrington added a comment - We also will only use TCP sockets, due to our performance needs. However, if it is simple and well-supported to use Avro over our own transport, that is probably best, since we are equally unlikely to use the stock Avro TCP socket implementation. We need the performance and control of our own optimized network stack. I am guessing there are lots of people like us, so perhaps the focus should just be on good documentation and testing for running Avro RPC over arbitrary transports.
        Hide
        Doug Cutting added a comment -

        > In our experience, http servers are too black-box for the kinds of things we want to do [ ... ]

        That sounds reasonable. I'd like to avoid defining more than one Avro-specific wire protocol, and hope we can devise one that is simple, permits high-performance implementations, and also permits secure implementations. In the meantime, I think we're better off using HTTP.

        If you have existing client/server stacks, it should be fairly trivial to send Avro-format requests and responses over them. Meanwhile, the Avro reference implementations and specification will only have HTTP clients and servers until we standardize on another. Is that draconian?

        Show
        Doug Cutting added a comment - > In our experience, http servers are too black-box for the kinds of things we want to do [ ... ] That sounds reasonable. I'd like to avoid defining more than one Avro-specific wire protocol, and hope we can devise one that is simple, permits high-performance implementations, and also permits secure implementations. In the meantime, I think we're better off using HTTP. If you have existing client/server stacks, it should be fairly trivial to send Avro-format requests and responses over them. Meanwhile, the Avro reference implementations and specification will only have HTTP clients and servers until we standardize on another. Is that draconian?
        Hide
        Ryan King added a comment -

        We won't be building servers in ruby, they'll mostly be in scala/java.

        In our experience, http servers are too black-box for the kinds of things we want to do (high volume, small payload RPCs). We end up needing to have more control over the low levels of the stack.

        Show
        Ryan King added a comment - We won't be building servers in ruby, they'll mostly be in scala/java. In our experience, http servers are too black-box for the kinds of things we want to do (high volume, small payload RPCs). We end up needing to have more control over the low levels of the stack.
        Hide
        Doug Cutting added a comment -

        > I suppose we could have a separate spec for socket-based RPC.

        I filed AVRO-341 for that.

        Is there a problem using HTTP? Ruby's Mongrel should be easy to use for Ruby-based servers. In Java I was able to make thousands of requests per second using HTTP. It's easy to promise long-term multi-language interoperability over HTTP today.

        Show
        Doug Cutting added a comment - > I suppose we could have a separate spec for socket-based RPC. I filed AVRO-341 for that. Is there a problem using HTTP? Ruby's Mongrel should be easy to use for Ruby-based servers. In Java I was able to make thousands of requests per second using HTTP. It's easy to promise long-term multi-language interoperability over HTTP today.
        Hide
        Ryan King added a comment -

        That's rather unfortunate. I doubt we'd use anything other than raw sockets for avro-rpc and given that we need multi-lang interop it would be nice to have a spec for it. I suppose we could have a separate spec for socket-based RPC.

        Show
        Ryan King added a comment - That's rather unfortunate. I doubt we'd use anything other than raw sockets for avro-rpc and given that we need multi-lang interop it would be nice to have a spec for it. I suppose we could have a separate spec for socket-based RPC.
        Hide
        Doug Cutting added a comment -

        As I think about it more, I'd prefer we focus on http rather than sockets. I'd like to minimise the number of transports that an Avro implementation must support. Ideally we'd have just one. It's clear that HTTP is a useful, standard transport, but Y! does not believe it's the appropriate basis for secure RPC in Hadoop. So we'll probably support one other Avro-specific transport. My current guess is that this will be SASL over TCP, so much like our current socket transports, but not identical. I'd rather not support a third, TCP w/o SASL, since that just multiplies the implementation effort and potential mismatches. So for now, until the details of the SASL over TCP transport are fleshed out, HTTP is probably a better first transport for implementations.

        Show
        Doug Cutting added a comment - As I think about it more, I'd prefer we focus on http rather than sockets. I'd like to minimise the number of transports that an Avro implementation must support. Ideally we'd have just one. It's clear that HTTP is a useful, standard transport, but Y! does not believe it's the appropriate basis for secure RPC in Hadoop. So we'll probably support one other Avro-specific transport. My current guess is that this will be SASL over TCP, so much like our current socket transports, but not identical. I'd rather not support a third, TCP w/o SASL, since that just multiplies the implementation effort and potential mismatches. So for now, until the details of the SASL over TCP transport are fleshed out, HTTP is probably a better first transport for implementations.

          People

          • Assignee:
            Unassigned
            Reporter:
            Jeff Hammerbacher
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development