RpcController objects are per-request, not per-server or per-service. For every RPC request you make, you should have another RpcController object (though you can reuse an object by calling Clear() as long as you aren't making two requests at once). RpcChannel objects are per-service. Is that what you were thinking of? A single RpcChannel represents a connection to a single Service. However, there's nothing stopping you from multiplexing multiple RpcChannels across a single TCP connection, or creating a protocol that allows you to choose between multiple services exported by a server when constructing an RpcChannel.
On Wed, Nov 19, 2008 at 5:06 PM, codeazure <[EMAIL PROTECTED]> wrote: > > On Nov 20, 7:58 am, Kenton Varda <[EMAIL PROTECTED]> wrote: > > I'm not sure I understand. There's nothing stopping you from spreading > your > > definitions out among multiple .proto files which import each other, and > > there's nothing stopping you from exporting multiple services from a > single > > server. You'll need to design a protocol that allows it, but protocol > > buffers doesn't do anything to prevent it. Can you be more specific > about > > the problem you're facing, maybe giving an example? > > I can have multiple services per server? That's what I wanted to know. > I could not any place in the documentation where it talked about > whether Service has a 1:1 or Many:1 relationship with RpcController. > It seemed like it was 1:1 from all the examples I had seen, hence my > confusion. Next time you're updating the docs in this area, it might > be worth changing the example to show 2 Services so it's clear to > others. > > I was also thinking of services running on ports on Linux systems. In > this situation, it is a 1:1 relationship between services and ports. I > know it's a different situation, but my thinking got stuck on the term > service. > > If I can define as many services as I like and attach them all to the > same RPC Controller, then that will answer my question & give me the > extensible modular design I want. I had thought there had to be an > answer like this because I couldn't imagine Google's internal > applications would want to be bound by such a serious limitation. > > Thanks! > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
