초록
본 논문에서는 프로토콜 개발 도구를 이용하여 Wireless Application Protocol (WAP) 포럼에서 제안하는 무선 트랜잭션 프로토콜(Wireless Transaction Protocol: WTP)을 구현하였다. 또한, 서버모델, coroutine 모델 및 activity-thread 모델에 따라 개발도구의 지원없이 직접 개발된 WTP 구현물들과 그 성능을 비교 분석하였다. 우선 Unified Modeling Language (UML)을 사용하여 프로토콜의 요구사항을 분석함과 동시에 프로토콜 엔진의 구조를 정의하였으며, 이를 기반으로 Specification and Description Language (SDL)을 사용하여 프로토콜 엔진을 상세 설계한 후, 코드 자동 생성기를 이용하여 WTP 구현물을 생성하였다. 구현물의 성능을 분석한 결과, 3,000개 이하의 클라이언트가 동시에 접속할 경우에는 트랜잭션 처리율(throughput)과 트랜잭션 처리 지연시간(system response time) 측면에서 기존의 세 가지 모델을 이용하여 직접 개발한 프로토콜 엔진과 그 성능이 대등함을 알 수 있었다. 그러나, 5,000개 이상의 클라이언트가 동시에 접속할 경우 트랜잭션 성공률은 약 10%까지 급격히 감소하고 트랜잭션 처리 지연시간은 1,500㎳까지 증가하였는데, 이는 프로토콜 개발도구를 사용한 경우에 구현물의 크기가 약 62% 증가하면서 프로토콜 처리시간 증가로 인한 것이다. 그러나, 이러한 실험 결과는 실험에 사용된 PC 서버의 사양을 고려할 때 호스트의 과부하로 인한 것이며, 부하분산 기능이 제공되는 실제 환경에서는 프로토콜 개발 도구를 사용하지 않고 직접 개발한 프로토콜 엔진과 거의 대등한 성능을 보였다.
In this paper, we design and implement the Wireless Transaction Protocol (WTP) proposed by the Wireless Application Protocol (WAP) forum using a protocol development tool, SDL Development Tool (SDT). And we conduct a comparative performance evaluation of the WTP implementation with other three implementations that are based on different implementation models respectively: the server model, the coroutine model, and the activity-thread model. To implement WTP, we first use Unified Modeling Language (UML) for analyzing the protocol requirement and defining the protocol engine architecture. Next, we use Software Development Language (SDL) to design the protocol engine in details and then generate the WTP implementation automatically with the aid of SDT The code size of the WTP implementation generated by SDT is 62% larger than the other three implementations. However, its throughput and system response time for transaction processing is almost equal to the other three implementations when the number of concurrent clients is less than 3,000. If more than 5,000 concurrent clients tries, the transaction success rate abruptly decreases to 10% and system response time increases to 1,500㎳, due to the increased protocol processing time. But, it comes from the fact that the load overwhelms the capacity of the PC resource used in this experimentation.
