TCPIP应用程序的通信连接模式

上传人:lis****211 文档编号:58826493 上传时间:2022-03-01 格式:DOC 页数:19 大小:105KB
返回 下载 相关 举报
TCPIP应用程序的通信连接模式_第1页
第1页 / 共19页
TCPIP应用程序的通信连接模式_第2页
第2页 / 共19页
TCPIP应用程序的通信连接模式_第3页
第3页 / 共19页
亲,该文档总共19页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
TCPIP 应用程序的通信连接模式TCP/IP 应用层与应用程序 TCP/IP 起源于二十世纪 60 年代末美国政府资助的一个分组交换网络研究项目,它是一个真正的开放协议,很多不同厂家生产各种型号的计算机,它们运行完全不同的操作系统,但 TCP/IP 协议组件允许它们互相进行通信。现在 TCP/IP 已经从一个只供一些科学家使用的小实验网成长为一个由成千上万的计算机和用户构成的全球化网络, TCP/IP 也已成为全球因特网( Internet)的基础,越来越多的 TCP/IP 互联网应用和企业商业应用正在改变着世界。 TCP/IP 通讯协议采用了四层的层级模型结构(注:这与 OSI 七层模型不相同) ,每一层都调用它的下一层所提供的网络任务来完成自己的需求。TCP/IP 的每一层都是由一系列协议来定义的。这 4 层分别为: 应用层 (Application) :应用层是个很广泛的概念, 有一些基本相同的系统级 TCP/IP 应用以及应用协议,也有许多的企业商业应用和互联网应用。传输层(Transport) :传输层包括UDP 和TCP,UDP 几乎不对报文进行检查,而 TCP 提供传输保证。网络层(Network) :网络层协议由一系列协议组成,包括ICMP 、IGMP 、RIP 、OSPF、 IP(v4,v6)等。链路层(Link) :又称为物理数据网络接口层,负责报文传输。图显示了TCP/IP 层级模型结构,应用层之间的协议通过逐级调用传输层( Transport layer)、网络层( Network Layer )和物理数据链路层( Physical Data Link )而可以实现应用层的应用程序通信互联。应用层需要关心应用程序的逻辑细节,而不是数据在网络中的传输活动。应用层其下三层则处理真正的通信细节。 在 Internet 整个发展过程中的所有思想和着重点都以一种称为RFC( Request For Comments)的文档格式存在。针对每一种特定的TCP/IP 应用,有相应的RFC 文档。一些典型的TCP/IP 应用有FTP、 Telnet、 SMTP 、SNTP 、REXEC 、 TFTP 、 LPD 、 SNMP 、 NFS、 INETD等。RFC使一些基本相同的TCP/IP 应用程序实现了标准化,从而使得不同厂家开发的应用程序可以互相通信。图 TCP/IP 层级模型结构然而除了这些已经实现标准化的系统级TCP/IP应用程序外,在企业商业应用和互联网应用开发中,存在着大量的商业应用程序通信互联问题。如图 显示,其中的应用层所包含应用程序主要可以分成两类,即系统级应用和商业应用,互联网商业应用是商业应用中的主要形式之一。不同开发商和用户在开发各自商业应用通信程序时也存在有许多不同的设计方式。关于TCP/IP 应用层以下的技术文献与书籍早已是汗牛充栋,但是关于TCP/IP 应用本身,尤其是关于商业应用的通信设计模式技术讨论方面的文章还是比较少的。 TCP/IP 应用通信设计模式实际上是在 TCP/IP 基础编程之上的一种应用编程设计方式,也属于一种应用层协议范畴,其可以包含有 TCP/IP 地址族模式设计、 I/O 模式设计、通信连接模式设计以及通信数据格式设计等。鉴于目前讨论 TCP/IP 商业应用程序设计模式问题这方面的文章还很少见,本文尝试给出一些通信连接模式设计中共同的概念与一些典型的设计模式,在以后的文章中将继续讨论地址族模式设计、 I/O 模式设计、以及通信数据格式设计等方面的模式设计实现话题。通信连接模式设计主要考虑内容有:通信两端程序建立通信方式通信连接方式通信报文发送与接收方式以下内容将介绍建立通信的 Client/Server 模型,然后逐一介绍通信连接模式设计所需要考虑的这些内容。回页首传输层接口 APIs 与 TCP/IP 应用程序 C/S 模型传输层接口 APIsTCP/IP 应用层位于传输层之上, TCP/IP 应用程序需要调用传输层的接口才能实现应用程序之间通信。目前使用最广泛的传输层的应用编程接口是套接字接口( Socket)。Socket APIs 是于 1983 年在 Berkeley SocketDistribution (BSD) Unix中引进的。1986年AT&T公司引进了另一种不同的网络层编程接口TLI( Transport LayerInterface ),1988年AT&T发布了一种修改版的TLI,叫做XTI( X/open Transport interface )。XTI/TLI和Socket是用来处理相同任务的不同方法。关于TCP/IP APIs使用文章与书籍已相当多,本文则是侧重于如何组合使用这些APIs 来进行TCP/IP 应用程序连接模式设计,并归纳出几种基本应用连接模式。如图 显示,应用层是通过调用传输层接口APIs( Socket 或 XTI/TLI )来与传输层和网络层进行通信的。图 传输层接口不管是使用何种编程接口,要在两个机器或两个程序之间建立通信,通信双方必须建立互相一致的通信模式。如果双方的通信设计模式不一致就无法建立有效的通信连接。以下是经常使用的socket APIs,是建立TCP/IP应用程序的标准接口,也是影响TCP/IP 应用程序通信方式的几个主要APIs ,不同APIs 组合再结合系统调用可以实现不同方式的应用。Sockets 支持多种传输层和网络层协议,支持面向连接和无连接的数据传输,允许应用分布式工作。socket():是用来创建一个socket,socket 表示通信中的一个节点,其可以在一个网络中被命名,用socket描述符表示,socket描述符类似于Unix中的文件描述符。bind() :是用来把本地IP层地址和TCP层端口赋予socket。listen():把未连接的socket转化成一个等待可连接的socket,允许该 socket 可以被请求连接, 并指定该 socket 允许的最大连接数。 accept():是等待一个连接的进入,连接成功后,产生一个新的 socket 描述符,这个新的描述符用来建立与客户端的连接。 connect():用来建立一个与服务端的连接。 send():发送一个数据缓冲区, 类似 Unix 的文件函数 write() 。另外sendto() 是用在无连接的UDP 程序中,用来发送自带寻址信息的数据包。 recv():接收一个数据缓冲区,类似Unix的文件函数readI() 。另外recvfrom()是用在无连接的UDP程序中,用来接收自带寻址信息的数据包。close():关闭一个连接 Client/Server 模型 Sockets 是以Client 和 Server 交互通信方式来使用的。典型的系统配置是把Server放在一台机器中,而把Client放在另一台机器中,Client连接到Server 交换信息。一个socket 有一系列典型的事件流。例如,在面向连接的Client/Server 模型中, Server 端的socket总是等待一个Client 端的请求。 要实现这个请求, Server 端首先需要建立能够被Client 使用的地址,当地址建立后,Server 等待Client 请求服务。当一个Client 通过socket连接到Server 后,Client 与 Server 之间就可以进行信息交换。 Client/Server 是通信程序设计的基本模式。从软件开发的角度讲, TCP/IP 应用程序都是基于Client/Server方式的。注意本篇文章以下Client/Server概念是针对程序内部调用Socket API 所讲的概念,与针对整个程序甚至针对机器而讲的客户端/ 服务器概念有所不同。用 Server APIs 建立的程序可以被当作客户端使用,用Client APIs建立的程序也可以被用作服务器端使用。建立Server需要的APIs有socket(), bind(), listen(), accept() ,建立Client 需要的APIs有 Socket(), Connect() 。在实际应用开发中, 同一个程序里往往同时可以有 Client 和 Server 的代码,或者多种形式的组合。在实际应用编程中,针对Socket APIs 不同有效组合,结合系统调用可以有多种复杂的设计变化。面向连接的应用编程存在三类基本的不同级别的设计方式范畴,根据SocketAPIs 从上到下顺序依次是:Client/Server通信建立方式Client/Server 通信连接方式Client/Server通信发送与接收方式下面内容以面向连接的 Socket 应用编程为例来说明这几种不同通信范畴的设计实现。 回页首 Client/Server 建立方式设计概述一个 Client 连接一个 Server 如果只有两台机器之间连接,那么一个是 Client ,另一个是 Server,如下面图 3 所示。这是最简单的 TCP/IP 的应用,也是 TCP/IP 应用早期的 Peer to Peer (P2P) 概念。其流程基本如图 所示。图 TCP/IP 应用单点 Client/Server 图 4 显示了 TCP/IP 应用编程最基本的 Client/Server 模式,显示了基本的Client/Server 通信所需要调用的Socket APIs 以及顺序。图 TCP/IP 应用编程基本 Client/Server 模式多个 Client 连接一个 Server 多个 Client同时连接一个 Server是 TCP/IP应用的主流形式, 如图 所示,其中 Client 连接数可以从几个到成千上万。图 TCP/IP 应用多 Client 端的Client/Server 由于 socket APIs缺省方式下都是阻塞方式的,实现多个 Client 同时连接一个Server 就需要特别的设计。其实现方式可以有多种不同的设计, 这其中也涉及I/O 模式设计。下面将展开介绍其中几种设计形式。利用一个Client连接一个 Server 形式实现多Client 连接从程序设计角度讲,只要Client 和 Server 端口是一对一形式,那么就属于一个 Client 连接一个Server 形式。在处理多个Client 端连接时, Server 端轮流使用多个端口建立多个Client-Server连接,连接关闭后,被释放端口可以被循环使用。在这种多连接形式中需要谨慎处理Client 端如何获取使用Server端的可用端口。比如图 显示 Server 有一个服务于所有进程的进程可以先把Server 端的可用端口发送给Client端, Client 端再使用该端口建立连接来处理业务。Server 针对每一个 Client 连接用一个专门的进程来处理。由于可用端口数有限, Server 用一个有限循环来处理每一个可用的端口连接。由于新端口需要用bind() 来绑定, 所以需要从bind()开始到 close() 结束都需要包含在循环体内。图利用一对一 Client-Server模式实现多 Client 连接使用多个accept() 实现多 Client连接多进程 Server一般有一个专注进程是服务于每一个连接的。 当 Client 端完成连接后, 专注进程可以循环被另外的连接使用。 使用多个 accept() 也可以实现处理多 Client 连接。多 accept() 的 Server 也只有一个socket(),一个 bind() ,一个 listen() ,这与通常情况一样。但是它建立许多工作子进程,每一个工作子进程都有accept(),这样可以为每一个Client 建立socket 描述符。 如图 所示,由于accept() 连接成功后,会产生一个新的socket 描述符,这样通过循环多进程利用accept() 产生的多socket 描述符就可以与多个Client 进行连接通信。循环体是从 accept() 开始到 close() 结束的。图 使用多 accept() 实现多 Client 连接使用并发 Server 模式实现多 Client 连接并发服务器模式曾经是 TCP/IP 的主流应用程序设计模式,得到广泛使用,目前互联网上仍有相当多的应用使用此种模式。其设计思路是在accept 之后fork出一个子进程。因为socket 会产生监听socket 描述符listenfd , accept 会产生连接socket 描述符connfd。连接建立后,子进程继承连接描述符服务于Client ,父进程则继续使用监听描述符等待另外一个Client 的连接请求,以产生另外一个连接socket 描述符和子进程。如图 所示, accept() 接收到一个 Client 连接后,产生一个新的 socket 描述符,通过 fork()系统调用,用一个子进程来处理该socket 描述符的连接服务。而父进程可以立即返回到accept(),等待一个新的Client请求,这就是典型的并发服务器模式。并发服务器模式同时处理的最大并发Client 连接数由listen() 的第二个参数来指定。图 TCP/IP应用并发Server使用I/O多路技术实现多Client连接以上三种连接设计,多Server端口、多accept()和并发服务器模式,都是通过fork()系统调用产生多进程来实现多Client连接的。使用I/O多路技术也可以同时处理多个输入与输出问题,即用一个进程同时处理多个文件描述符。 I/O 多路技术是通过select() 或 poll()系统调用实现的。 poll()与 select() 功能完全相同,但是poll()可以更少使用内存资源以及有更少的错误发生。select() 调用需要与操作文件描述符集的APIs 配合使用。select() 系统调用可以使一个进程检测多个等待的I/O 是否准备好, 当没有设备准备好时, select() 处于阻塞状态中, 其中任一设备准备好后, select() 函数返回调用。select() API 本身也有一个超时时间参数,超时时间到后,无论是否有设备准备好,都返回调用。其流程如图9 所示。在socket APIs listen()和accept()之间插入select()调用。使用这三个宏FD_ZERO()、FD_CLR()和FD_SET(),在调用select()前设置socket描述符屏蔽位,在调用select()后使用FD_ISSET来检测socket 描述符集中对应于socket 描述符的位是否被设置。FD_ISSET() 就相当通知了一个 socket 描述符是否可以被使用,如果该 socket 描述符可用,则可对该 socket 描述符进行读写通信操作。 通常,操作系统通过宏 FD_SETSIZE 来声明在一个进程中 select() 所能操作的文件或 socket 描述符的最大数目。 更详细的 I/O 多路技术实现, 可以参考其他相关文献。图I/O 多路技术实现多连接的Server 一个Client 连接多个Server 一个 Client 连接多个Server 这种方式很少见,主要用于一个客户需要向多个服务器发送请求情况,比如一个Client 端扫描连接多个Server 端情况。如图 所示。此种方式设计主要是Client 端应用程序的逻辑设计,通常需要在Client 端设计逻辑循环来连接多个Server,在此不做更多描述。图单 Client 对多Server复杂Client/Server 设计与现代P2P 最近几年,对等网络技术 ( Peer-to-Peer,简称 P2P) 迅速成为计算机界关注的热门话题之一,以及影响 Internet 未来的科技之一。与早期点对点 (Peer to Peer) 的 Client/Server 模式不同,现在的 P2P 模式是指每个结点既可充当服务器,为其他结点提供服务,同时也可作为客户端享用其他结点提供的服务。实际上P2P模式仍然是基于Client/Server 模式的,每个通信节点都既是Server,又是Client , P2P 是基于复杂Client/Server 设计的TCP/IP应用。图 显示P2P模式下两个用户PC之间的对等连接。图P2P模式在技术上,P2P本身是基于TCP/IP Client/Server技术的一种设计模式思想,P2P也属于网络应用层技术,与Web 和 FTP 等应用是并列的。只是 P2P 应用在设计实现上更要复杂的多。P2P 技术实现的协同工作是无需专门的服务器支持的(Serverless),这里的服务器概念与Client/Server中的 Server 概念是不一样的。在传统意义上中心服务器机器上往往运行的是TCP/IP 应用的 Server端程序,所以传统意义上的Server 概念在机器与应用上是重合的。如果更改TCP/IP的应用设计,使应用程序既可做Server 又可做Client ,就可以实现无中心服务器的 P2P 模式。在设计模式上,P2P 模式实现了网络终端用户不依赖中心服务器或者服务商而直接进行信息和数据交换的可能,因此 P2P 正在改变着整个互联网的一些基础应用,从而极大地增加了用户之间的信息沟通和交流能力。目前互联网的 P2P 应用与网络都正在飞速发展,一些典型的P2P 应用程序比如有 BitTorrent, eDonkey 等,另外一些即时通信( IM )类软件比如 MSN 、 QQ 等也正在向无中心服务器模式转变。 无中心服务器的Internet 应用程序大大降低应用提供商的运营成本,而且减少人们对于Server 稳定性的依赖。回页首 Client/Server 通信连接方式设计 Client/Server 通信方式建立后,下一步就需要考虑通信连接的方式,主要有两种方式的连接,即长连接通信与短连接通信。通信连接方式涉及到的 APIs 主要是 connect() 和 accept()。要实现某种 Client/Server 方式,就必须考虑用某种特定的连接方式。短连接通信短连接通信是指Client方与Server 方每进行一次通信报文收发交易时才进行通讯连接,交易完毕后立即断开连接。此种方式常用于多个Client连接一个Server情况,常用于机构与用户之间通信,比如OLTP(联机事务处理)类应用。在短连接情况下,Client端完成任务后,就关闭连接并退出。在 Server 端,可以通过循环accept(),使Server 不会退出,并连续处理Client 的请求。图 显示了一般情况下短连接通信模式的Socket 事件流,不同设计的连接多 Client 的 Server 有不同的循环流程。图短连接模式通信长连接通信长连接通信是指Client 方与Server 方先建立通讯连接,连接建立后不会断开,然后再进行报文发送和接收,报文发送与接收完毕后,原来连接不会断开而继续存在,因此可以连续进行交易报文的发送与接收。这种方式下由于通讯连接一直存在,其TCP/IP 状态是Established,可以用操作系统的命令netstat 查看连接是否建立。由于在长连接情况下,Client 端和Server 端一样可以固定使用一个端口,所以长连接下的Client 也需要使用bind() 来绑定 Client 的端口。在长连接方式下, 需要循环读写通信数据。为了区分每一次交易的通信数据,每一次交易数据常常需要在数据头部指定该次交易的长度,接收API需要首先读出该长度,然后再按该长度读出指定长度的字节。长连接方式常用于一个Client 端对一个 Server 端的通讯,一般常用于机构与机构之间的商业应用通信,以处理机构之间连续的大量的信息数据交换。或者说可用于两个系统之间持续的信息交流情况。通常为了加快两个系统之间的信息交流,通常还需要建立几条长连接的并行通信线路。图 显示了一般情况下长连接通信模式的socket 事件流,可见其最大特点是 Client 和 Server 都有循环体,而且循环体只包含读写 APIs 。图 长连接模式通信回页首Client/Server 通信发送与接收方式设计在通信数据发送与接收之间也存在不同的方式,即同步和异步两种方式。这里的同步和异步与I/O 层次的同异步概念不同。主要涉及socketAPIs recv()和 send() 的不同组合方式。同步发送与接收从应用程序设计的角度讲,报文发送和接收是同步进行的,既报文发送后,发送方等待接收方返回消息报文。同步方式一般需要考虑超时问题,即报文发出去后发送方不能无限等待,需要设定超时时间,超过该时间后发送方不再处于等待状态中,而直接被通知超时返回。同步发送与接收经常与短连接通信方式结合使用,称为同步短连接通信方式,其socket 事件流程可如上面的图所示。异步发送与接收从应用程序设计的角度讲,发送方只管发送数据,不需要等待接收任何返回数据,而接收方只管接收数据,这就是应用层的异步发送与接收方式。要实现异步方式,通常情况下报文发送和接收是用两个不同的进程来分别处理的,即发送与接收是分开的,相互独立的,互不影响。异步发送与接收经常与长连接通信方式结合使用,称为异步长连接通信方式。从应用逻辑角度讲,这种方式又可分双工和单工两种情况。异步双工异步双工是指应用通信的接收和发送在同一个程序中,而有两个不同的子进程分别负责发送和接收,异步双工模式是比较复杂的一种通信方式,有时候经常会出现在不同机构之间的两套系统之间的通信。比如银行与银行之间的信息交流。它也可以适用在现代 P2P 程序中。如图 所示,Server 和 Client 端分别 fork 出两个子进程, 形成两对子进程之间的连接,两个连接都是单向的,一个连接是用于发送,另一个连接用于接收,这样方式的连接就被称为异步双工方式连接。图长连接异步双工模式异步单工应用通信的接收和发送是用两个不同的程序来完成,这种异步是利用两对不同程序依靠应用逻辑来实现的。图显示了长连接方式下的异步单工模式, 在通信的 A 和 B 端,分别有两套 Server 和 Client 程序,B 端的 Client 连接 A 端的Server, A 端的 Server 只负责接收 B 端 Client 发送的报文。 A 端的 Client 连接 B 端的 Server,A 端 Client 只负责向 B 端 Server 发送报文。图 长连接异步单工模式回页首典型通信连接模式综上所述,在实际 TCP/IP 应用程序设计中, 就连接模式而言, 我们需要考虑 Client/Server 建立方式、 Client/Server 连接方式、 Client/Server 发送与接收方式这三个不同级别的设计方式。实际TCP/IP 应用程序连接模式可以是以上三类不同级别 Client/Server 方式的组合。比如一般 TCP/IP 相关书籍上提供的 TCP/IP 范例程序大都是同步短连接的 Client/Server 程序。有的组合是基本没有实用价值的,比较常用的有价值的组合是以下几种:同步短连接 Server/Client 同步长连接 Server/Client 异步短连接Server/Client 异步长连接双工Server/Client 异步长连接单工Server/Client 其中异步长连接双工是较为复杂的一种通信方式,有时候经常会出现在不同银行或不同城市之间的两套系统之间的通信,比如国家金卡工程。由于这几种通信方式比较固定,所以可以预先编制这几种通信方式的模板程序。回页首总结本文探讨了TCP/IP 应用程序中连接模式的设计。在以后的文章中还将继续讨论TCP/IP 应用程序设计中的其他方面的设计话题,包括地址族模式设计、I/O 模式设计、以及通信数据格式设计等。
展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 办公文档 > 活动策划


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!