Protocol RPC for Go and C++

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

ChaiShushan

unread,

Jul 21, 2013, 10:20:51 AM7/21/13

to prot...@googlegroups.com, chai2010

Hi Feng Xiao,

I changed the url to https://code.google.com/p/protorpc/

Now, go version can use `go get code.google.com/p/protorpc` install pkg.

C++ version also need `hg clone https://code.google.com/p/protorpc.cxx/` first.

Please update the protorpc URL.

Thanks!

在 2013年5月9日星期四UTC+8上午1时56分44秒，Feng Xiao写道：

Feng Xiao

unread,

Jul 22, 2013, 2:03:13 PM7/22/13

to ChaiShushan, Protocol Buffers

Done.

Visit this group at http://groups.google.com/group/protobuf.

Jens Munk Hansen

unread,

Dec 8, 2013, 7:01:55 AM12/8/13

to prot...@googlegroups.com

Hi ChaiShushan

I have looked into your c++ implementation and I really like the fact that it is portable. The POSIX components do not compile, but it was easy to fix, some names were wrong in rpc_posix_conn.cc.

The software boss in our company likes standards and is trying to make a crew of software engineers with limited experience go from an almost monolithic structure into implementing their own services using DDS. We use Windows for a near real-time application (oh no).

I am working on a project in my spare time, where I have used a simple C protocol allowing me set set remote parameters and execute remote functions. I wan't to use Kenton Vardas capnproto, but I would also like it to be cross-platform and cannot wait for this to be started.

I really like your solution, except for the fact, that I would like not to change protoc (introduce return arguments for Services, remove the Closure concept, etc.) and be in sync with the main protocol buffers development. Another thing that I would to have is that all threads are outside the library and I can use a shared thread pool. I have sort of stolen some of your ideas and some ideas from Kenson Varda.

Some questions:

1) Are you still developing on this branch and do you think there is a possibility that you work will be part of the official protocol buffers?

2) If you want to shutdown a server using a remote procedure you somehow need to exit the loop. I have implemented this in a command protocol, where a new callback is registered using the Closure concept. It is sort of hack, because one service is the able to shutdown others. Do you have any good ideas on how to implement this?

3) What is your opinion about Captain Proto. Do you think it will become a standard for RPC?

The reason for I would like to be in sync with protocol buffers is that we use for other stuff.

Message has been deleted

chai2010

unread,

Dec 10, 2013, 9:07:00 PM12/10/13

to Jens Munk Hansen, Protobuf

2013/12/8 Jens Munk Hansen <jens.mun...@gmail.com>

Hi ChaiShushan

I have looked into your c++ implementation and I really like the fact that it is portable. The POSIX components do not compile, but it was easy to fix, some names were wrong in rpc_posix_conn.cc.

Thanks for your feedback :)

I am a windows user, i have not do the test on posix system.

Can you submit some patch for POSIX compile issue?

The software boss in our company likes standards and is trying to make a crew of software engineers with limited experience go from an almost monolithic structure into implementing their own services using DDS. We use Windows for a near real-time application (oh no).

For my protorpc, i just use golang protorpc server.

And my golang protorpc server run on windows right now,

but i don't care the OS(it is easy to switch to Linux with golang).

My rpc client run on the windows with C++ language.

I am working on a project in my spare time, where I have used a simple C protocol allowing me set set remote parameters and execute remote functions. I wan't to use Kenton Vardas capnproto, but I would also like it to be cross-platform and cannot wait for this to be started.

I hear about the capnproto.

But i don't worry about the performance right now :)

I really like your solution, except for the fact, that I would like not to change protoc (introduce return arguments for Services, remove the Closure concept, etc.) and be in sync with the main protocol buffers development. Another thing that I would to have is that all threads are outside the library and I can use a shared thread pool. I have sort of stolen some of your ideas and some ideas from Kenson Varda.

This solution is very like the Go standard RPC framwork.

And i implement the Go's protorpc first, and then implement the C++'s version.

I am a newbie with C++ network pramgram.

So the C++'s protorpc server is just a toy for me.

And the C++'s protorpc client don't support asynchronous RPC call.

If need implement the asynchronous RPC call, we need use Closure for the delayed replay.

Some questions:
1) Are you still developing on this branch and do you think there is a possibility that you work will be part of the official protocol buffers?

There is no new feature in developing.

I use the C++ client now, and i will fix the bugs.

I don't think the official protocol buffers will accept my RPC solution(C++ and Go).

2) If you want to shutdown a server using a remote procedure you somehow need to exit the loop. I have implemented this in a command protocol, where a new callback is registered using the Closure concept. It is sort of hack, because one service is the able to shutdown others. Do you have any good ideas on how to implement this?

I don't think it is a really requirement for RPC.

We can shutdown the server in other way, eg: ssh.

3) What is your opinion about Captain Proto. Do you think it will become a standard for RPC?

I don't think there is a standard RPC!

As Gopher, i like Protobuf, because it is a standard package(Go team created it).

Visit this group at http://groups.google.com/group/protobuf.

For more options, visit https://groups.google.com/groups/opt_out.

--
chaishushan
http://my.oschina.net/chai2010

https://bitbucket.org/chai2010

abcbe...@gmail.com

unread,

Aug 23, 2018, 10:04:37 PM8/23/18

to Protocol Buffers

Hello, your project cannot find in "code.google.com", please tell me how to get it, thanks a lot!

在 2013年5月8日星期三 UTC+8下午9:33:48，chai2010写道：

Reply all

Reply to author

Forward