Twisted 입문 강좌(12)

새로운 서버 구현
여기에 Twisted 버전의 서버를 새로 쓰려고 합니다.그런 다음 Deferred의 새로운 기능에 대해 살펴보겠습니다.
9, 10부분에서 우리는 시가 전환 엔진이라는 개념을 제기했다.그 실현이 너무 간단하기 때문에 우리는 무작위 선택으로 전환에 실패할 수 있는 상황을 모의했다.그러나 변환 엔진이 서버 측에 있다면 서버가 다운되면 실제 변환에 실패하는 상황이 발생할 것이다.
따라서 이 부분에서 우리는 시 스타일 변환 서버를 실현하고 한 부분에서 우리의 시 다운로드 클라이언트를 다시 써서 이 서비스를 사용하고 Deferred의 새로운 기능을 배울 것이다.
설계 프로토콜
지금까지 서버 측과 클라이언트 간의 상호작용은 모두 단방향이다.그러나 스타일 변환 서비스는 양방향 상호작용을 해야 한다. 클라이언트는 원시 스타일의 시를 유서버에 보내고 서버는 형식을 변환하여 대응하는 클라이언트에게 보낸다.따라서 우리는 이러한 상호작용을 실현하기 위해 프로토콜을 사용하거나 스스로 실현해야 한다.
우리는 서버 측이 클라이언트가 선택할 수 있도록 몇 가지 전환 서비스를 제공할 수 있도록 설계했다.따라서 클라이언트는 서버 측에 두 부분의 정보를 보내야 한다. 전환 방식 이름과 시 원시 내용이다.서버는 형식을 바꾼 시가를 클라이언트에게 보낼 뿐입니다.이곳은 간단한 운행 호출에 사용되었다.
Twisted 지원은 XML-RPC, Perspective Broker, AMP를 위한 프로토콜이 필요합니다.
그러나 그 중 하나를 사용하는 데는 많은 시간이 필요하기 때문에 우리는 자신이 실현한 협의를 사용한다.클라이언트가 다음 형식으로 보내기로 약속했습니다.
이름을 변환합니다.시가 내용
우리는 이것을 넷string 형식으로 인코딩할 것입니다. 물론 서버에서 보낸 정보도 넷string 형식으로 인코딩됩니다.netstring은length-encoding을 사용하기 때문에 클라이언트는 서버가 전체 시를 돌려보내지 않은 상황을 식별할 수 있습니다.만약 당신이 앞의 프로토콜을 시도해 본다면, 중간에 전송이 중단되는 상황을 감지할 수 없습니다.
코드
새 서버 구현 코드는twisted-server-1/transformedpoetry입니다.py 중.먼저 Transform Service 클래스를 정의했습니다.
class TransformService(object):
    def cummingsify(self, poem):
        return poem.lower()
여기서 우리는 단지 하나의 변환 방법을 실현했을 뿐, 우리는 새로운 형식의 변환 방법을 되돌리지 않을 수 있다.중요한 점은 포맷 전환 서비스와 구체적인 협의의 실현은 완전히 분리된 것이다.프로토콜 논리와 서비스 논리를 분리하는 것은 Twisted 프로그래밍에서 흔히 볼 수 있는 모델이다.이렇게 하면 여러 가지 협의를 통해 같은 서비스를 실현하여 코드의 중용성을 증가시킬 수 있다.
다음은 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,), None)
        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는transform의 함수를 제공합니다. 프로토콜은 클라이언트의 연결 요청을 대표하여 시 형식을 변환하는 것입니다.
클라이언트가 요청한 변환 방법이 없거나 실패한 경우 None으로 돌아갑니다.Transform 서비스와 마찬가지로factory와 구체적인 프로토콜 논리의 실현도 서로 독립적이다.
주의해야 할 점이 하나 있다. 우리는 xfomr_를 통해접두사 방법으로 서비스 방법을 얻습니다.이런 방법은 트위터에서 흔히 볼 수 있다. 접두사가 자주 바뀌고 factory에 독립된 대상 (이러한 Transform 서비스) 에 의존하는 것은 클라이언트가 의도적인 악성 코드를 사용하여 서버를 실행하는 것을 방지하는 방법이다.이런 방법도 서비스가 구체적인 협의 대리를 제공하는 메커니즘을 제공했다.
다음은 프로토콜 구현 코드입니다.
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(self, xform_name, poem):
        new_poem = self.factory.transform(xform_name, poem)
        if new_poem is not None:
            self.sendString(new_poem)
        self.transport.loseConnection()
이 프로토콜의 실현에서 우리는 NetstringReceiver를 계승함으로써 Twisted가 netstrings에 대한 실현을 이용했다.기본 클래스는 인코딩과 디코딩 기능을 잘 처리합니다. 우리가 해야 할 일은stringReceived 방법을 실현하는 것입니다.다시 말하면stringReceived가 수신하는 매개 변수는 클라이언트가 인코딩한 시가이며, 우리가 추가 인코딩 정보를 추가할 필요가 없다.그리고 기류 역시 버퍼 구역을 관리하고 있다. 즉, 시가 온전하게 수신된 후에 디코딩을 하는 것이다.
만약 모든 것이 정상적으로 진행된다면, 우리는 NetstringReceiver의sendString 방법을 사용하여 형식 변환에 성공한 시를 클라이언트에게 보낼 것입니다.
xformRequestReceived 방법을 정의하여 받은 정보를 한 걸음 한 걸음 더 높은 추상층으로 끌어올려 Twisted 모델을 실현하는 방법을 주의하십시오.
간단한 클라이언트
우리는 다음 부분에서 상응하는 클라이언트를 실현할 것이다. 여기에 간단한 스크립트를 사용하여 클라이언트를 실현할 것이다. 코드는 twisted-server-1/transform-test에 있다.11000 포트에서 서버를 실행하는 경우:

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

실행 스크립트는 다음과 같습니다.

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

그러면 다음과 같은 출력을 볼 수 있습니다. (netstring 인코딩을 통해)

15:here is my poem,

토론
이 부분에서 다음과 같은 몇 가지 측면을 소개했다.
1. 양방향 통신
2. Twisted의 기존 프로토콜을 바탕으로 새로운 프로토콜 구현
3. 프로토콜 구현과 서비스 기능 구현을 독립적으로 분리
양방향 통신의 기본 메커니즘은 매우 간단하다.우리는 앞의 서버 측과 클라이언트가 사용하는 같은 기술을 사용하여 데이터를 쓰고 읽는 것이다. 유일하게 다른 것은 우리가 이번에 둘 다 사용했다는 것이다.물론 복잡한 프로토콜은 수신된 데이터 흐름과 포맷된 출력 정보를 처리하기 위해 복잡한 코드를 필요로 한다.이것도 이미 존재하는 협의를 사용하는 이유다.
간단한 프로토콜을 쓰는 것이 익숙해지기 시작했다면 트위터가 서로 다른 프로토콜에 대한 실현을 살펴보는 것이 좋다.간단한 프로토콜을 쓰면 트위터의 프로그래밍 스타일을 이해하는 데 도움이 되지만, 실제 프로그램에서는 이미 실현되고 성능이 좋은 프로토콜을 복용하는 것이 가장 좋다.
마지막으로 프로토콜 해석 논리와 서비스 실현 논리를 분리하는 것은 Twisted 프로그래밍에서 매우 중요한 모델이다.우리의 이 서버 프로그램은 단지 하나의 시범일 뿐인데, 너는 실제 인터넷 서비스가 상당히 복잡하다고 상상할 수 있다.서비스와 프로토콜 논리를 분리함으로써 당신은 기존의 서비스 코드를 복용하여 다른 프로토콜 실현에 실행할 수 있습니다.
그림 27은 포맷 변환 서버가 두 가지 프로토콜을 통해 포맷 변환 서비스를 제공하는 것을 보여 줍니다. (물론 저희 서버는 하나의 프로토콜만 제공합니다.)
그림 27은 두 가지 프로토콜이 지원하는 형식 변환 서버를 제공한다
그림27에서 두 가지 프로토콜을 사용했지만 몇 가지 프로토콜만 다를 수도 있다.factory는 같은 서비스를 공유합니다.이렇게 해서 코드의 복용을 실현하였다.