Part 12th improving Poetry download server

Author: [Email protected]http://krondo.com/?p=2101 Translator: Yang Xiaowei (with free translation)

You can read this series from scratch here.

The new server implementation

Here we are going to write a new Twisted version of the server. Then, let's discuss some new features of Deferred .

In the Nineth to tenth part, we propose the concept of poetry conversion engine. Because the implementation is too simple, we use random selection to simulate scenarios where conversion failures can occur. However, if the conversion engine is located on the server side, the actual conversion failure scenario will occur when the server goes down.

So in this part we're going to implement a verse-style conversion server, and then in a section, we'll rewrite our poetry download client to use this service and learn the new features of Deferred .

Design protocol

So far, the interaction between the server side and the client is one-way. But the style transformation service requires two-way interaction - The client sends the original style's poem to the milk server, and the server converts the format and sends it to the corresponding client. Therefore, we need to use or implement a protocol ourselves to achieve this interaction.

We design the server side to provide several kinds of transformation services, and let the client to choose. Therefore, the client needs to send two pieces of information to the server side: The transformation mode name and the original poem content. The server simply sends the poem after the converted format to the client. A simple call to the operation is used here.

Twisted supports the need for a protocol to solve this problem:xml-rpc,perspective broker,amp.

But it takes a lot of time to introduce any one of them, so we use our own implementation protocol. We agreed that the client send content format is as follows:

Conversion name . Poetry Content

We encode it in netstring format, and of course the information for the server postback is encoded in netstring format. Because netstring uses length-encoding, the client can recognize the fact that the server does not have a full poem postback. If you try the previous protocol, it will not detect the interruption of transmission in the middle of the situation.

Code

The new server implementation code is in twisted-server-1/transformedpoetry.py . First, we define a Transformservice class:

Class Transformservice (object):    def cummingsify (self, poem):        return Poem.lower ()

Here we only implement a conversion method, we can not return to the new format conversion method. There is an important place to note: The Format conversion service is completely separated from the implementation of the specific protocol. Separating the protocol logic from the service logic is a common pattern in Twisted programming. This allows the same service to be implemented through a variety of protocols to increase the reusability of the code.

Here's a look at the implementation code for factory :

Class Transformfactory (Serverfactory):    protocol = Transformprotocol    def __init__ (self, Service):        Self.service = Service    def transform (self, Xform_name, poem):        thunk = GetAttr (self, ' xform_%s '% (Xform_name,), N One)        if thunk is none: # No such transform            return none        try:            return thunk (poem)        except:            return None # Transform failed    def xform_cummingsify (self, poem):        return self.service.cummingsify (poem)

Factory provides a transform function,protocol is used to represent the client connection request for poetic format conversion.

Returns Noneif no conversion method or conversion failure was found for the client request. Like Transformservice ,factory and concrete protocol logic implementations are independent of each other.

There is one place to draw attention to: we use the xfomr_ prefix method to get the service method. This approach is common in Twisted , although prefixes are often changed, and they are often dependent on an object independent of factory ( transformservice This is a way to prevent clients from using deliberately malicious code to make the server execute. This approach also provides a mechanism for implementing a service-specific protocol proxy.

Here is the Protocol implementation code:

class Transformprotocol (netstringreceiver): Def stringreceived (self,        Request): if '. ' Not in Request: # Bad Request self.transport.loseConnection () return Xform_name, poem = Request.split ('. ', 1) self.xformrequestreceived (Xform_name, poem) def xformrequestreceived (SE            LF, Xform_name, poem): New_poem = Self.factory.transform (xform_name, poem) If New_poem is not None: Self.sendstring (New_poem) self.transport.loseConnection () 

In the implementation of this Protocol, we take advantage of the implementation of Twisted to netstrings by inheriting Netstringreceiver . The base class handles the encoding and decoding functions well, and all we need to do is implement the stringreceived method. In other words,stringreceived receives a parameter that is the client-encoded verse, without having to add additional coding information. And the base class also manages the buffer, that is, when a poem is fully received and then decoded.

If all goes well, we will use Netstringreceiver 's sendstring method to send the poem to the client after the successful format conversion.

Notice how we implemented the Twisted pattern by defining the xformrequestreceived method to push the received information step-by-step to a higher abstraction layer.

A simple client

We will implement the corresponding client in the next section, where a simple script is used to implement the client, and the code is in twisted-server-1/transform-test . If you are running server-side on 11000 Port:

Python twisted-server-1/transformedpoetry.py--port 11000

The corresponding run script is:

./twisted-server-1/transform-test 11000

then you will see the following output (after netstring code):

15:here is my poem,

Discuss

The following aspects are described in this section:

1. bidirectional Communication

2. Implementing a new protocol based on Twisted existing protocols

3. separate the protocol implementation from the service function implementation

The basic mechanism of two-way communication is very simple. We use the same technology as the client used in front of the server to write and read the data, the only difference is that we both use (Read and write). Of course, a complex protocol requires complex code to handle the information received by the data stream and formatted output. This is why you use an already existing protocol.

If you start to feel that writing simple protocols is a good idea, then it's best to start looking at Twisted 's implementation of different protocols. Although writing simple protocols helps to understand Twisted 's programming style, in a real-world program, it is best to reuse protocols that have been implemented and proven to be well-performing.

The last point is to separate the protocol parsing logic from the service implementation logic, which is a very important pattern in Twisted programming. Our server program is just a demo, you can imagine the real network service is quite complex. By separating the service from the protocol logic, you can run the other protocol implementations by reusing the existing service code.

The diagram shows a format conversion server that provides a format conversion service through two protocols (of course, our server only provides a protocol):

Figure Two a format conversion server supported by the Protocol

Although there are two protocols used in the diagram, they may be only a few of the protocol properties are different. factory share the same service. This enables the reuse of code.

Part 12th improving Poetry download server