I shall start a RPC project based on PB

[一首诗]

http://code.google.com/p/pbrpc/

I've been studying python for years but I have never built any serious
project on Python. So the main purpose of this project will be
practice my Python skills.

Other technique targets:

1. Using only 1 TCP connection between client and server.

2. Could run on top twisted framework but could also work with out
twisted.

I shall spend about 2 to 4 weeks working on this to provide the first
release. Hope I could finish it on time :)

==================================

Some technical problems:

1. How to match request with its response?

For example, client called method A twice before server reply because
the process of method A is very time consuming on server. So when
server finished both of the calls, and sent them back to client, how
could client match these requests to their initial requests?

2. How to support synchronous calls?

The underling socket layer must be no-blocking. But sometimes it's
very convenient to program on a synchronous model.

3. Could sharing the same TCP connection cause any problem?

Could this be possible : Thread A just finishes part of sending
request, context change happens, Thread B begins to send it's
request. The server would be unable to split the bit stream into
requests!

[Dave Spencer]

On Jul 11, 4:17 am, 一首诗 <newpt...@gmail.com> wrote:
> http://code.google.com/p/pbrpc/
>
> I've been studying python for years but I have never built any serious
> project on Python. So the main purpose of this project will be
> practice my Python skills.
>
> Other technique targets:
>
> 1. Using only 1 TCP connection between client and server.
>
> 2. Could run on top twisted framework but could also work with out
> twisted.
>
> I shall spend about 2 to 4 weeks working on this to provide the first
> release. Hope I could finish it on time :)
>
> ==================================
>
> Some technical problems:
>
> 1. How to match request with its response?
>
> For example, client called method A twice before server reply because
> the process of method A is very time consuming on server. So when
> server finished both of the calls, and sent them back to client, how
> could client match these requests to their initial requests?

I've been playing around in this same general area of writing a simple
python RPC mechanism on top of TCP.

You might need to define a protocol buffer to hold the information
about the request:

message CallInfo {
required string name = 1; // method name
required string req = 2; // serialized argument
}

And you may need to add some kind of a sequence number of you allow
out of order responses.
Initially it's probably easiest to ignore this and just allow single
TCP conn, single thread, blocking semantics, and then
handle the general case of multiple ourstanding requests with out of
order responses.

In a simple case I think things fit together like this.
The user writes a proto file:

message MyReq {
required string my_req_name = 1;
optional string my_req_id = 2;
}

message MyResp {
required string my_msg = 1;
}

service MySearchService {
rpc DoSomething (MyReq) returns (MyResp);
}

The user writes server code that extends MySearchService:

class MyServiceImpl(MySearchService):
def __init__(self):
msgs_pb2.SearchService.__init__(self)

def DoSomething(self, rpc_controller, request, done):
done()


You, or someone, writes a PB/TCP/RPC layer - and there is a
TcpServerChannel that extends the Google-defined service.RpcChannel.
The user's server code initializaes things like this:

rpc_channel = TcpServerChannel(('localhost', 12341))
ss = MyServiceImpl()
rpc_channel.Run(ss)

Now the rpc channel knows that *all* calls it receives are for
MyServiceImpl (is-a MyService), thus the only issue
is to take whatever comes over the wire, decode it, and (dynamically)
create and then populate the request arg (MyReq here).
This last thing, which sounds trivial, is what I'm caught up on, esp
getting it right wrt python package refs.
The server code needs to new a MyReq() and then call ParseFromString()
to populate it, and then I think it can call the users server impl...

Hope this helps - I know it's incomplete - it's just a rough overview
of my understanding and thrashing in this area.

- Dave

[Kenton Varda]

2008/7/11 Dave Spencer <david.sp...@gmail.com>:

message CallInfo {

       required string name = 1; // method name
       required string req = 2;  // serialized argument

Make sure to use the "bytes" type here, not "string".

[Kenton Varda]

Sounds interesting!

On Fri, Jul 11, 2008 at 4:17 AM, 一首诗 <newp...@gmail.com> wrote:

1. How to match request with its response?

The client can attach an id number to each message, and the server attaches the same id to the corresponding response.

 

2. How to support synchronous calls?

The underling socket layer must be no-blocking.  But sometimes it's
very convenient to program on a synchronous model.

You could have your RpcController implementation have a method called Wait(), which waits for the call to complete.

 

3. Could sharing the same TCP connection cause any problem?

Could this be possible : Thread A just finishes part of sending
request, context change happens, Thread B begins to send it's
request.   The server would be unable to split the bit stream into
requests!

You'd need to use some sort of locking to prevent this.

[Blair Zajac]

On Jul 11, 4:17 am, 一首诗 <newpt...@gmail.com> wrote:

> http://code.google.com/p/pbrpc/
>
> I've been studying python for years but I have never built any serious
> project on Python. So the main purpose of this project will be
> practice my Python skills.

This sounds like a fun project, but if you're going to seriously use
your code, before writing it, I suggest looking at Ice from www.zeroc.com.
They provide an RPC framework using an IDL type system that works in
Python, C++ and Java, you can have clients and servers in any
language. It supports asynchronous and synchronous calls. What they
are missing is the nice way to version the structs over the network
that protocol buffers provides.

A cool project would be to mix Ice for the RPC portion with PB for the
message contents.

Regards,
Blair

[Glenn H Tarbox, PhD]

On Fri, 2008-07-11 at 04:17 -0700, 一首诗 wrote:
> http://code.google.com/p/pbrpc/
>
> I've been studying python for years but I have never built any serious
> project on Python. So the main purpose of this project will be
> practice my Python skills.
>
> Other technique targets:
>
> 1. Using only 1 TCP connection between client and server.

if that isn't a core element of the system, you're doing something very
wrong

>
> 2. Could run on top twisted framework but could also work with out
> twisted.

not using twisted will mean reinventing a very complicated wheel and
almost certainly doing it wrong. The only argument for not using
twisted is because people can't figure out asynchronous processing... in
which case, they should find another line of work.

>
> I shall spend about 2 to 4 weeks working on this to provide the first
> release. Hope I could finish it on time :)

this should take about 2 days to come up with a pre alpha version. But
before you start, you should look at foolscap which is the follow-on
twisted distributed object protocol.

>
> ==================================
>
> Some technical problems:
>
> 1. How to match request with its response?

This is what foolscap and deferreds are for

>
> For example, client called method A twice before server reply because
> the process of method A is very time consuming on server. So when
> server finished both of the calls, and sent them back to client, how
> could client match these requests to their initial requests?

that's what deferreds are for

>
> 2. How to support synchronous calls?

you shouldn't. if the client wants to block, that's their problem. you
return a value when you do... if they're blocking on the socket it's
independent of the server issue.

>
> The underling socket layer must be no-blocking. But sometimes it's
> very convenient to program on a synchronous model.

and wrong. and leads threads... which is always the path first taken by
those without any understanding of asynchronous programming... which
leads to non-deterministic bugs, synchronization issues etc.

unless its a really simple call on the client side and they don't care
about blocking... in which case you simply write a simple method which
ships the arguments across and blocks. if they need something fancier
they should be using twisted on the client. If they can't get it, they
should move on.

>
> 3. Could sharing the same TCP connection cause any problem?

i don't really understand what you're asking here... but there should be
only one connection between a client and server unless you're doing
specific things regarding control channels etc.

>
> Could this be possible : Thread A just finishes part of sending
> request, context change happens, Thread B begins to send it's
> request. The server would be unable to split the bit stream into
> requests!

if this is your understanding of the issues going in, I suggest stopping
now. its very clear you've done virtually no research and have no
understanding of the issues.

at best, somebody will pay attention and use what you write.

> >
--
Glenn H. Tarbox, PhD || gl...@tarbox.org
"Don't worry about people stealing your ideas. If your ideas are any
good you'll have to ram them down peoples throats" -- Howard Aiken

[Kenton Varda]

On Fri, Jul 11, 2008 at 2:42 PM, Glenn H Tarbox, PhD <gl...@tarbox.org> wrote:

if this is your understanding of the issues going in, I suggest stopping

now.  its very clear you've done virtually no research and have no
understanding of the issues.

Writing a system like this is a great way to learn.  It seemed pretty clear that this was intended to be an educational project, so I say go for it.

[Glenn H Tarbox, PhD]

2 years in the lab can save 2 hours in the library.

[一首诗]

Thanks for your detailed reply :) I didn't expect to get so much
attentions!

> > 1. Using only 1 TCP connection between client and server.
>
> if that isn't a core element of the system, you're doing something very
> wrong

In my opinion, setting up a TCP connection for each thread or even for
each RPC call might save some time on coding,
but it seems to be a little clumsy, especially when the client needs
make RPC for many times.

>
> > 2. Could run on top twisted framework but could also work with out
> > twisted.
>
> not using twisted will mean reinventing a very complicated wheel and
> almost certainly doing it wrong.  The only argument for not using
> twisted is because people can't figure out asynchronous processing... in
> which case, they should find another line of work.
>

OK, I will consider first make it work on twisted.

>
> > I shall spend about 2 to 4 weeks working on this to provide the first
> > release. Hope I could finish it on time :)
>
> this should take about 2 days to come up with a pre alpha version.  But
> before you start, you should look at foolscap which is the follow-on
> twisted distributed object protocol.
>

I will have a look and I promise I will release a pre alpha version as
soon as possible.
No matter how bad it is, I think your suggestions might help me a
lot.

>
> > ==================================
>
> > Some technical problems:
>
> > 1. How to match request with its response?
>
> This is what foolscap and deferreds are for
>
>
>
> > For example, client called method A twice before server reply because
> > the process of method A is very time consuming on server.  So when
> > server finished both of the calls, and sent them back to client,  how
> > could client match these requests to their initial requests?
>
> that's what deferreds are for
>
>
>
> > 2. How to support synchronous calls?
>
> you shouldn't.  if the client wants to block, that's their problem.  you
> return a value when you do... if they're blocking on the socket it's
> independent of the server issue.
>
>
>
> > The underling socket layer must be no-blocking.  But sometimes it's
> > very convenient to program on a synchronous model.
>
> and wrong. and leads threads... which is always the path first taken by
> those without any understanding of asynchronous programming... which
> leads to non-deterministic bugs, synchronization issues etc.
>
> unless its a really simple call on the client side and they don't care
> about blocking... in which case you simply write a simple method which
> ships the arguments across and blocks.  if they need something fancier
> they should be using twisted on the client.  If they can't get it, they
> should move on.

xmlrpclib in Python standard libraries provide synchronous API, there
is reason why this kind of IO interface exist on this world.

>
> > 3. Could sharing the same TCP connection cause any problem?
>
> i don't really understand what you're asking here... but there should be
> only one connection between a client and server unless you're doing
> specific things regarding control channels etc.
>
>
>
> > Could this be possible : Thread A just finishes part of sending
> > request, context change happens, Thread B begins to send it's
> > request.   The server would be unable to split the bit stream into
> > requests!
>
> if this is your understanding of the issues going in, I suggest stopping
> now.  its very clear you've done virtually no research and have no
> understanding of the issues.
>
> at best, somebody will pay attention and use what you write.
>
>

But, what I have read about computer networks, operating system,
system API manual, doesn't prohibit, in princle, what I described to
happen. So maybe you could provide some library books that would ease
my worries?

[一首诗]

Thanks for your encouragement!
I shall make it!