80 likes | 276 Views
QTP as Transaction Transport Layer. High-capacity, connection-oriented transaction transport Cameron_Young@inetco.com (604) 451-1567. Who is INETCO? Software vendor linking institutions with terminals See www.inetco.com Our perspective Financial/retail vertical market
E N D
QTP as Transaction Transport Layer High-capacity, connection-oriented transaction transport Cameron_Young@inetco.com (604) 451-1567
Who is INETCO? Software vendor linking institutions with terminals See www.inetco.com Our perspective Financial/retail vertical market Financial TP is often “Most mission critical application” We make new elements evolving into a system communicate with what is already there. Normally we work in all layers below ISO8583 or equivalent message. Why are we here? Joint authors of QTP - transport protocol for POS transactions over IP. SOAP/HTTP emphasizes client-web-server interaction. QTP addresses concentration points (back-end). Scope Deal with communication issues, not use of RPC vs. Message API. Introduction
Typical POS Architecture POS Terminals (1000s to 100ks) Network Access Controllers or FEP Institutions EFT TPs X.25/Dial Access Network SNA/X.25/FR Access Network Message (ISO8583 or other) Message Visa, TPDU, CLNP, None Visa, TPDU, CLNP, TPDU HDLC, X.25, Async X.25, FR, IP
Performance Fast connection processing High availability Security Restrict by source access network address Restrict by source transport-layer address Restrict RAS - INAC communication Provide legal intercept Transaction delivery Either non-reliable delivery, or Reliable delivery with end-to-end data acknowledgements Access Network independence X.25, FR, Dialup, ... Transport layer independence TCP or UDP, FR, other Scaling >100k transaction terminals >100 financial institutions Initial peak ~500 TPS with scalable growth Transport Layer Requirements
IP-oriented Architecture INAC clusters POS Terminals Remote Access Servers Institution EFT TPs X.25/Dial Access Network IP Network SNA/X.25/FR Access Network Message (ISO8583 or other) Message (as is) Message (as is) Visa, TPDU, CLNP, None Transport (as is) Host transport QTP X.25, SNA, FR HDLC, X.25, Async UDP/IP
Status Released as Internet Draft: draft-cornish-qtp-01.txt First applications in production Incorporated by other vendors. Opensource version available for draft-cornish-qtp-00.txt Characteristics Lightweight connection multiplexing Symmetric Individual message acks Status for source routing decisions. Independent of lower-level transport Attribute/Value based Extensible Header Version Msg ID, Msg ID Ack, Priority flags Length Src / Dest Logical Channel Number Optional Msg ID, Msg ID Ack values Attributes for Session establishment Data transfer Session management Element status Statistical information Vendor extensions QTP Overview
Session Establishment Called / Calling party addresses Called / Calling party subaddresses Address family (E.164, X.121, …) Profile, speed, idle timeout Max message Protocol identifier Customer group identifier Data Transfer Data / Block data Management info Q Data / Call Data Session Management Cause (Normal, various QTP causes) Remote cause (Normal, various Access causes) Element Status Flow control state (Available, Congested) Station status (Primary, Secondary, …) Ping Call state Statistical Information Messages received / sent Unacked messages Time since last restart QTP Attributes
Closing Comments • QTP not a fit for client side, unless client is really a gateway / proxy for many transaction generators. • Primary incentive for choosing QTP today is scaling beyond TCP session limits. QTP addresses concentrated connection-oriented transactions. • May be future interest in SOAP over QTP. • Would require split into SOAP encapsulation and SOAP over HTTP specs. • As transaction concentration increases, so does emphasis on security, reliability, and performance.