2WCF蒋金楠概念.docVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
2WCF蒋金楠概念

【概念篇】 WCF的可靠会话这涉及到WS中一个重要的概念——可靠消息传输(RM:Reliable Messaging)。如果想对可靠会话有一个深入的认识,对可靠消息传输的了解是必须的。我们可以将一个通过WCF构建的分布式应用划分为两个部分,即客户端应用和服务端应用,它们之间的交互方式即采用某种MEP的消息交换。在这里,我们需要通过可靠消息传输机制确保从客户端应用(或者服务端应用)发送的消息能够成功地被服务端应用(或者客户端应用)接收。也就是说,可靠消息传输提供的是一种端到端的消息传输确保机制,而不管两个终端之间是否具有相应的中间结点(Intermediary),比如路由器、防火墙和代理之类… 如果想对可靠会话有一个深入的认识,对可靠消息传输的了解是必须的。 一、可靠消息传输(Reliable Messaging) 我们可以将一个通过WCF构建的分布式应用划分为两个部分,即客户端应用和服务端应用,它们之间的交互方式即采用某种MEP的消息交换。在这里,我们需要通过可靠消息传输机制确保从客户端应用(或者服务端应用)发送的消息能够成功地被服务端应用(或者客户端应用)接收。也就是说,可靠消息传输提供的是一种端到端的消息传输确保机制,而不管两个终端之间是否具有相应的中间结点(Intermediary),比如路由器、防火墙和代理之类。除了确保对消息的可靠交付,可靠消息传输还需要解决以下两个问题: 重复消息(Duplicate Message):对于某一个客户端发出的消息,服务端接收到两个以上相同的副本。可靠消息传输机制需要具有对重复消息的识别能力; 无序交付(Disordered Delivery):服务端接收到的消息序列与消息发送序列不一致。在某些情况下,我们要求WCF服务端框架严格按照消息在客户端应用中被发送的顺序交付给服务端应用,这需要消息传输机制提供有序消息交付(Ordered Message Delivery)的功能。 说道这里,可能有的读者对可靠消息传输机制有一种是曾相识之感,是不是觉得这个TCP协议对于TCP报文段(TCP Segment)的可靠交付机制有点类似。 二、TCP对报文段(Segment)的可靠交付机制 稍微有点网络知识的读者应该都知道,IP协议是TCP/IP协议簇中最为核心的协议。对于协议分层(链路层、网络层、传输层和应用层)体系中,属于网络层协议。所有的TCP、UPD、ICMP以及IGMP协议均是建立在IP协议之上。 IP协议传输的数据单位是数据报(Datagram),数据报的首部(一般20个字节)包含有源和目标的IP地址以及其他的相应的寻址和控制信息。IP协议具有以下两个显著的特点: 不可靠(Unreliable): IP协议只能尽可能提供最好的传输服务,但不能保证数据报能够成功地抵达目的地。如果发生某种错误,它有一个简单的错误处理算法:丢弃数据报,然后发送通知信息给发送端; 无连接(Connectionless):IP协议并不维护任何关于后续数据报的状态信息,每一个数据报都是被独立处理的。 而作为传输层的TCP协议,众所周知,这是一个可靠的、基于连接的协议。TCP协议传输的数据单位被称为报文段(Segment),可靠的TCP协议能够确保发出的报文段能够成功地抵达目的地。那么,建立在不可靠的IP协议上的TCP协议是如何实现报文段的可靠交付的呢?大体上说,下面两种机制取保了TCP协议对“使命必达”的承诺: 消息确认(Message Acknowledgement):当接收端TCP成功接收到TCP报文段之后,会在一个短暂的时间间隔内(并不是在成功接收到报文的那一刻),向发送端发送一个表明该报文段已经被成功接收确认消息(Acknowledgement); 超时重传:发送端具有一个存储报文段的缓冲区(Buffer),我们一般称为发送端窗口(Sender Window),用于存放已经发送但是尚未接受到确认的报文段。如果接收到确认,会将相应的报文段从发送端窗口中移除。如果在一定的超时时限内没有接收到确认消息,会认为相应的报文段发送失败,此时发送端TCP会从发送端窗口中提取相应的报文段进行重新发送。 对于上述的消息确认和超时重传的机制,细心的读者会发现这会出现两个问题:如果接收端TCP成功接收到某个报文段,并且成功发送了确认。但是,如果确认消息丢失,发送端TCP会对相应的报文段进行重传,就意味着接收端有可能接收到两份重复的报文段。很显然,接收端TCP不能将重复的报文段向上层交付,那么如何解决重复报文段的问题呢? 第二个问题,报文段在发送端TCP发送的节奏和在接收端TCP被接收的节奏是不同的,所以不可能保证报文段完全以发送的顺序被接收。但是,接收端TCP必须保证交付给上层的报文段的顺序必须是报文段被发送的顺

文档评论(0)

xcs88858 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

版权声明书
用户编号:8130065136000003

1亿VIP精品文档

相关文档