Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Example of an Async API compatible protocol #21

Open
lvh opened this issue Jun 23, 2011 · 6 comments
Open

Example of an Async API compatible protocol #21

lvh opened this issue Jun 23, 2011 · 6 comments

Comments

@lvh
Copy link
Owner

lvh commented Jun 23, 2011

Needs to use:

  • two-way communication
  • consumers and producers
  • nothing outside the stdlib

This should then ideally work on the stdlib implementation of the Async API backend, of course.

@lvh
Copy link
Owner Author

lvh commented Jun 24, 2011

I'm thinking about using JSONRPC as the reference protocol here. Motivation:

  • It's fairly simple
  • You can speak it over raw TCP
  • It can be composed with a decent HTTP protocol implementation later
  • It has two-way communication
  • It's easy to do using the tools that are available in the standard library anyway (mostly the json module)
  • It's actually useful and not in the standard library already
  • XMLRPC is in the standard library already

@jerub
Copy link
Collaborator

jerub commented Jun 24, 2011

I like a line based (\r\n terminated) chat server better because you can quite easily demonstrate essential facets:

  • communication between protocol objects.
  • connection made and connection lost events are needed in chat server (unlike in jsonrpc)
  • can be interfaced with from 'telnet' to localhost - no one has a jsonrpc client with which to exercise their server.
  • is actually a generalisation of an echo server, which is the basic starting point of most socket examples.

Examples used in core python socket module is here: https://babbledrive.appspot.com/static/doc/python-2.7.1/library/socket.html#example

@lvh
Copy link
Owner Author

lvh commented Jun 24, 2011

Okay. That's a good argument. I like the idea of having LineReceiver in the stdlib because it's so useful.

@glyph
Copy link

glyph commented Oct 13, 2012

NetstringReceiver in the stdlib would be even better.

@nikipore
Copy link

I'd vote for ChunkReceiver which is already in the PEP (and covers LineReceiver) plus Twisted's ProcessProtocol. I am not 100% sure whether I've got the user story in #25 right, but it seems to me that ProcessProtocol would cover it.

@nikipore
Copy link

I actually prefer a generic FrameProtocol over ChunkReceiver (which is a special case of it). I more or less use it in a Twisted context as follows (I show both Twisted-style protocol interface methods and callbacks to ease comparison; personally, I prefer handing over callbacks to subclassing):

class FrameProtocol(Protocol):
    def __init__(self, parser, onFrame, onConnectionLost):
        self._parser = parser
        self._onFrame = onFrame
        self._onConnectionLost = onConnectionLost

    def connectionLost(self, reason):
        self._onConnectionLost(reason)

    def dataReceived(self, data):
        self._parser.add(data)
        for frame in iter(self._parser.get, self._parser.sentinel):
            self.frameReceived(frame)

    def frameReceived(self, frame):
        self._onFrame(frame)

    def send(self, frame):
        self.transport.write(frame.compile())

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants