search

MashaTelyatnikova / protobuf-socket-rpc

Automatically exported from code.google.com/p/protobuf-socket-rpc
MIT License
0 stars 0 forks source link

Keep a persistent socket open for multiple RPC requests. #5

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
Description of feature:

Add support for keeping the socket open for multiple rpcs to be made
through it.

Why do you think this feature/enhancement is needed:

Better performance and efficiency of socket use if there is a high volume
of rpcs between the same client and server.

Implementation suggestions (optional):

Either add an option to SocketRpcChannel to keep persistent connection
until told explicitly to disconnect or create a new type of channel.

Original issue reported on code.google.com by sdeo.code@gmail.com on 4 Oct 2009 at 6:28

GoogleCodeExporter commented 8 years ago 
I've actually modified a copy of your code to do just this, except that I don't 
provide an option to the channel, I just maintain an open socket by default 
until told 
to disconnect. This could easily be moved over to a different type.

Original comment by btri...@gmail.com on 21 Dec 2009 at 9:42

GoogleCodeExporter commented 8 years ago 
Can you either upload a diff of your changes or paste it here? I am working on 
some 
new features and I can add it in.

Original comment by sdeo.code@gmail.com on 22 Dec 2009 at 4:20

GoogleCodeExporter commented 8 years ago 
Yeah... as soon as I get the okay from the legal department here at my job. :( 
I did 
the work on their time. They're always okay with giving back to the open source 
community as long as no intellectual property is given away. Obviously that 
won't be 
the case here, but I have to have them clear it anyway. Not sure how long it 
will 
take.

By the way, I modified the Java code but not the Python code. The way I handled 
the 
persistent socket was by appending the size of the message as an array of bits 
(length of 4) to the beginning of the message. The other end knows to take the 
first 
4 bits and convert it to an integer to know how many more bits to read to get 
the 
next message.

Original comment by btri...@gmail.com on 22 Dec 2009 at 1:59

GoogleCodeExporter commented 8 years ago 
Ok, so here's the diffs per your revision 48. I made changes against revision 
46 I 
think, but that should be okay since it looks like most of the recent changes 
have 
been to the python code. Let me know if you have questions. All your existing 
tests 
still pass and I added a few new ones to test multiple messages via the same 
socket 
connection.

Original comment by btri...@gmail.com on 22 Dec 2009 at 7:40

Attachments:

GoogleCodeExporter commented 8 years ago 
Huge improvement, guys. Has this been integrated? The other place this is 
extremely
useful: using PB to create signaling protocols that can cross firewalls (a la 
SIP and
XMPP). The only problem there is you'd need to be able to send messages in both
directions. Is there any way to do that? To send a message to a client from a 
server
down an existing connection? Maybe I'll ask on the forum if this is not the 
proper place.

Original comment by adamf...@gmail.com on 24 Jan 2010 at 5:05

GoogleCodeExporter commented 8 years ago 
Sorry this is not yet integrated. I'll probably create a new channel called 
PersistentSocketRpcChannel or something like that. I plan to get this done in 
the 
next couple of weeks.

There are two ways I can see being able to send messages from server to client.

1) The client makes a true async rpc using the PersistentSocketRpcChannel. The 
server then can use a delayed callback at any time in the future to send a 
message 
using the persistent connection. This should be possible once 
PersistentSocketRpcChannel is ready.

2) Creating a persistent socket connection is totally decoupled from making 
rpcs and 
once the connection is made, rpcs can be initiated in either direction. This is 
a little 
more tricky and requires some thinking. For instance, How will server code get 
hold 
of the persistent connection? There will have to be some global registry of all 
persistent connections and server code finds the one it is interested in.

I suspect 1) should be sufficient for most use cases.

Original comment by sdeo.code@gmail.com on 25 Jan 2010 at 1:24

GoogleCodeExporter commented 8 years ago 
I think #1 should work, yeah. I agree ideally all the logic for determining 
which socket to send a message to 
should be handled outside of Protocol Buffers.

There might be some interface tweaks necessary to effectively tell a server 
socket to send a message to a 
client at any time, as I don't believe there's a way to access those sockets 
now, correct? The classic SIP 
trapezoid is the scenario I'm thinking of -- see 
http://www.iptel.org/sip_trapezoid if not familiar.

This change would be huge, honestly. Anyone would be able to write a far more 
efficient version of both SIP 
and XMPP in about 1 day, and you could re-use all the ICE, STUN, TURN, SDP etc 
stuff for crossing firewalls. 
Opens up a lot of possibilities.

Original comment by adamf...@gmail.com on 25 Jan 2010 at 1:42

GoogleCodeExporter commented 8 years ago 
This is now done in the Java implementation. Google's python protobuf library 
does not yet support delimited reading/writing, so python support for 
persistent connection will have to wait.

See http://code.google.com/p/protobuf/issues/detail?id=226

Original comment by sdeo.code@gmail.com on 5 Nov 2010 at 1:37