Transports are somewhat low level interface concerned with transporting messages across through different means. “Messages” in this case are simple strings. All transports need to support two different interfaces:
Base class for all server transports.
Receive a message from the transport.
Blocks until another message has been received. May return a context opaque to clients that should be passed on send_reply() to identify the client later on.
Returns: | A tuple consisting of (context, message). |
---|
Sends a reply to a client.
The client is usually identified by passing context as returned from the original receive_message() call.
Messages must be strings, it is up to the sender to convert the beforehand. A non-string value raises a TypeError.
Parameters: |
|
---|
Base class for all client transports.
Send a message to the server and possibly receive a reply.
Sends a message to the connected server.
Messages must be strings, it is up to the sender to convert the beforehand. A non-string value raises a TypeError.
This function will block until one reply has been received.
Parameters: | message – A string to send. |
---|---|
Returns: | A string containing the server reply. |
Note that these transports are of relevance when using tinyrpc-built in facilities. They can be coopted for any other purpose, if you simply need reliable server-client message passing as well.
A few transport implementations are included with tinyrpc:
Based on zmq, supports 0mq based sockets. Highly recommended:
Server transport based on a zmq.ROUTER socket.
Parameters: | socket – A zmq.ROUTER socket instance, bound to an endpoint. |
---|
Create new server transport.
Instead of creating the socket yourself, you can call this function and merely pass the zmq.core.context.Context instance.
By passing a context imported from zmq.green, you can use green (gevent) 0mq sockets as well.
Parameters: |
|
---|
Client transport based on a zmq.REQ socket.
Parameters: | socket – A zmq.REQ socket instance, connected to the server socket. |
---|
Create new client transport.
Instead of creating the socket yourself, you can call this function and merely pass the zmq.core.context.Context instance.
By passing a context imported from zmq.green, you can use green (gevent) 0mq sockets as well.
Parameters: |
|
---|
There is only an HTTP client, no server (use WSGI instead).
HTTP POST based client transport.
Requires requests. Submits messages to a server using the body of an HTTP POST request. Replies are taken from the responses body.
Parameters: |
|
---|
WSGI transport.
Requires werkzeug.
Due to the nature of WSGI, this transport has a few pecularities: It must be run in a thread, greenlet or some other form of concurrent execution primitive.
This is due to handle() blocking while waiting for a call to send_reply().
The parameter queue_class must be used to supply a proper queue class for the chosen concurrency mechanism (i.e. when using gevent, set it to gevent.queue.Queue).
Parameters: |
|
---|
WSGI handler function.
The transport will serve a request by reading the message and putting it into an internal buffer. It will then block until another concurrently running function sends a reply using send_reply().
The reply will then be sent to the client being handled and handle will return.