[WIP] Introduce RPC subsystem. #26
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
iivanou
suggested changes
Sep 5, 2017
.travis.yml
Outdated
| install: | ||
| - pip install 'tox>=2.4.1,<3' | ||
| script: | ||
| - cd rpc/pyton && tox |
There was a problem hiding this comment.
Probably "python" instead of "pyton"?
| ) | ||
| self.__closed = False | ||
|
|
||
| @property |
|
|
||
| while True: | ||
| message = self.__extract_message(buffer) | ||
| if message is not None: |
rpc/python/tests/utils/gevent.py
Outdated
| @@ -0,0 +1,16 @@ | |||
| import gevent | |||
|
@Almost1990
Sure. |
AndreiPashkin
force-pushed
the
rpc
branch
2 times, most recently
from
a31b48c to
1332a9b
Compare
added 14 commits
December 8, 2017 19:46
Because it thinks that this is badly formatted:
if (condition() or
timeout is not None and
(time.time() - timestamp) > timeout):
return
And that the second line must be indented.
The value is increased up to 15.
Because it treats this formatting as invalid:
if (condition() or
timeout is not None and
(time.time() - timestamp) > timeout):
return
It says that the second line is underindented.
AndreiPashkin
force-pushed
the
rpc
branch
5 times, most recently
from
276892c to
140fca3
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
OneDrive Client - RPC
The project's RPC system is defined in this place.
Motivation
This sub-project is created as a consequence of dissatisfaction with ZeroMQ and other RPC systems. The purpose of it is to build a reliable RPC system, which would handle peers disconnects reliably and provide message-delivery guarantees.
Another reason is desire to have freedom in choosing the technology-stack.
Features
Reliability. Particularly - reliable handling of peers disconnects
using heartbeats.
High-level interface for common communication patterns:
Basic validation of messages.
Pluggable transports.
Language-independent contracts.
Automatic generation of clients and servers for the services.
Architecture
The architecture consists of three layers:
Transport layer
Responsible for consistent and guaranteed delivery of messages as byte sequences.
Transport layer abstracts concrete method of message-passing which could be TCP, UDP, ZeroMQ, D-Bus, HTTP, etc.
RPC layer
Responsible for:
RPC Layer is dependent on transport layer. At the same it should not depend on any implementation details of particular transport implementation.
User-defined client/server layer.
Responsible for providing stubs for servers and client for concrete services of the application. Both are supposed to be thin wrappers around RPC layer that route calls of concrete methods ("get_item()", "put()", etc) to correct RPC calls made by methods implemented in RPC layer.
Generated clients are fully-functional accessors for associated services. Server-stubs are server implementations that only lack business logic and otherwise are fully-functional servers that can accept connections. Business logic for server-stubs are supposed to be provided via call-backs by users of the stub-classes.
Client and server-stub generation is supposed to be made based on language-independent interface declarations (or
contracts).
Technology stack
TCP - primary transport protocol. Protobuf - as an interface declaration language, a tool for code-generation and serialization.