Bi-Directional protocol buffers

[Adam Fisk]

Is there any way to make protocol buffers bi-directional? I'm very
excited about the addition of persistent connections:

http://code.google.com/p/protobuf-socket-rpc/issues/detail?id=5

The killer additional feature, though, would be if the server could
also send a message to the client at any time, with the client
implementing its own interface. That's not supported in any way right?
This would be particularly useful for creating signaling protocols, a
la SIP and XMPP.

Thanks.

-Adam

[Kenton Varda]

Hi,

This is the discussion group for protocol buffers itself, not any particular RPC system based on them.  It looks like protobuf-socket-rpc has its own discussion group which may be the right place for your question.

Incidentally, what you described is fully supported in an RPC system I'm (occasionally) working on in my spare time:

  http://capnproto.googlecode.com

However, it's still in the pretty early stages of development.

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To post to this group, send email to prot...@googlegroups.com.
To unsubscribe from this group, send email to protobuf+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.

[Adam Fisk]

My question is about protocol buffers themselves. Put simply, is there any way to do bi-directional messaging on a single TCP connection running protocol buffers? Put another way, can both sides be a client and server on the same conection?

My point about how you might use that in a larger RPC system was just an example.

-Adam

Sent from my iPhone

[Adam Fisk]

Or are you saying any networking questions at all are out of bounds for this group? Really?

Sent from my iPhone

On Jan 24, 2010, at 8:00 PM, Kenton Varda <ken...@google.com> wrote:

[Evan Jones]

On Jan 24, 2010, at 23:44 , Adam Fisk wrote:
> My question is about protocol buffers themselves. Put simply, is
> there any way to do bi-directional messaging on a single TCP
> connection running protocol buffers? Put another way, can both sides
> be a client and server on the same conection?

Sure, why not? Protocol buffers are just a protocol/library for
encoding messages. There is no reason you can't use it to decode
messages anyway you like. The library itself provides little to no
support for this, but there is no reason you can't use a single TCP
connection to send protocol buffer messages in both directions. In
fact, if you want to write an RPC implementation, you'll have to do
exactly that: send request messages one way, and reply messages the
other.

Evan

--
Evan Jones
http://evanjones.ca/

[Александр Мельников]

Dear Adam,

I suggest to use for bi-directional RPC in one TCP channel "packet encoding".

This is not so fast, as if it be in two channel, but useful when need economy of TCP.

"packet encoding" I mean, like X25 protocol: channel on standby state exchanges FLAG messages (may be use some  timeout), and if

one of peer required to call RPC procedure in  other side, it acknowledge by special ASK message, so instruct

other side act as server. And wise versa.

 

Hope this help,

Alexander

[Kenton Varda]

On Sun, Jan 24, 2010 at 8:45 PM, Adam Fisk <adam...@gmail.com> wrote:

Or are you saying any networking questions at all are out of bounds for this group? Really?

Networking questions in general are not "out of bounds", but questions asking what protocol buffers support don't really make sense as protobufs do not have built-in support for any networking at all.  You must support this with your own code or by using another library on top of protocol buffers.  Protobufs simply provide a way to convert structured data into bytes, which you can then pass over the network however you want.

[Adam Fisk]

Thanks everyone -- all makes sense. Sorry for the misplaced question.
I've done much more work with Thrift and didn't quite realize the
degree of separation of the RPC stuff in PB - I thought it had been
merged in somewhat.

Stepping back, though, your separation makes a lot of sense. With
Thrift, the type of change I'm proposing would be a significant change
to the core code. With PB, the building blocks are a little more
flexible.

Thanks again.

-Adam

--
Adam Fisk
http://www.littleshoot.org | http://adamfisk.wordpress.com |
http://twitter.com/adamfisk