Patterns in network system design (3)
作者 kernelchina | 2011-01-05 07:07 | 类型 行业动感 | 6条用户评论 »
系列目录 网络系统设计模型概论
8 unreliable message Pattern Name and Classification: unreliable message 通过网络,或者通过某种通道传递消息时,需要考虑消息传递是否是可靠的。可靠的消息可以这样定义: a: 消息是完整,正确的。这个一般用校验和来保证消息在传递过程中没有改变。 b: 接收方一定能够收到消息。接收方收到消息后,先检查校验和,然后给发送方一个应答。发送方在收到应答后,可以确认消息已经送达。如果发送方没有收到应答,需要定时重传消息,直到收到应答为止。如果消息之间需要保证顺序,那么在前一个消息没有发送完成之前,后续的消息不能发送。 c: 发送方的消息不能丢失。当发送方的应用把消息传递给消息发送模块后,如果它假设这个消息是可靠的,那么在消息模块里面要保证这个消息不能丢失。也就是说,如果应用模块把消息传递给消息模块并且返回成功,那么这个消息一定能到达接收方,或者消息模块需要返回错误给应用模块。 可以看到,为保证消息的可靠性,需要大量的额外工作,这将会严重影响系统的性能,特别是在高速通道上 更是如此。所以,如果少量的消息丢失是可以容忍的,那么建议使用unreliable message。但是应用程序需要 考虑消息丢失的情况,并为此做相应的处理。 1: http://en.wikipedia.org/wiki/User_Datagram_Protocol 9) reliable message Pattern Name and Classification: reliable message 可靠的消息通道可以简化上层应用的处理流程,上层应用不需要为消息丢失或者重复做额外处理。可靠性一般通过两种手段来保证: a: 确认。收到消息需要确认。 b: 重传。消息和确认都有可能重传,重传需要定时器,也需要队列。 可靠还意味着消息是按顺序送给上层应用的,并且已经去掉了重复的消息。 为了使消息传递得更快,需要使用滑动窗口;为了避免消息通道拥塞,需要采用拥塞控制手段;为保证消息不会使发送和接收双方的缓冲区溢出,需要控制发送和接收的消息数量。所以,可靠消息通道的实现非常复杂,面临的难题也很多。如果上层应用普遍要求使用reliable message,那么使用reliable message可以简化应用的设计,否则,可以使用unreliabe message,而由应用来处理丢包和重复的问题。 1: http://en.wikipedia.org/wiki/Transmission_Control_Protocol 2: http://en.wikipedia.org/wiki/Reliable_messaging 10) synchronous message Pattern Name and Classification: synchronous message 同步消息的涵义是:在发送请求之后,当前的操作必须等待应答消息返回以后,才能继续后面的流程。这个等待可以忙等待,也可以是睡眠。使用这个模式的前提是:后续操作依赖于当前操作的执行结果,也就是说,这些操作是序列化的。 由于这些操作是序列化的,所以很难并行化,而且不管是忙等待还是睡眠都会耗费一定的资源。所以,除非必要,最好不要用同步消息。 1: http://en.wikipedia.org/wiki/Message_passing 11) asynchronous message Pattern Name and Classification: asynchronous message 如果一系列操作之间并没有依赖关系,那么消息发送和应答处理可以由不同的线程处理。这样做的好处是:消息发送和应答处理可以并行执行。一般来说,异步消息并不需要序列化。但是如果有序列化的需求,就需要给消息分配序号,并且使用锁来保证每个消息和应答都是按顺序处理的。在实现时,需要权衡序列化带来的复杂性,可能用同步消息会有更好的结果。 有个同事把同步消息比做打电话,把异步消息比做电子邮件。打电话需要同步等待,而看邮件就不需要即时响应,也不需要按顺序看。这个类比很形象。 1: http://en.wikipedia.org/wiki/Message_passing 2: http://en.wikipedia.org/wiki/Messaging_pattern 12) piggyback message Pattern Name and Classification: piggyback message piggyback,意思是捎带,也就是搭顺风车的意思。捎带的好处是可以节省一个或多个消息,对性能有好处。捎带的这个消息可以与当前的消息相关,也可以无关。当然,前提是通信双方有多个消息需要交换,如果只有一个,就没有什么可以捎带的了。 1: http://en.wikipedia.org/wiki/Piggybacking_(data_transmission) 13) single message Pattern Name and Classification: single message 每次只发送或接收一个消息。这样做的好处是简单,不需要花费很多时间在message parsing上面。由于只有一个消息,消息长度和结构的验证都很容易,编程也容易。但一个消息的坏处是:双方交换的消息数量可能会很多,也可能会有其他开销。以http 1.0为例,每个URL都是独立的,所以需要为每个URL创建一个connection,系统资源消耗较大。 1: http://en.wikipedia.org/wiki/Http 14) bundle message Pattern Name and Classification: bundle message 如果多个消息可以放在一起发送,显然可以减少消息的数目。以http 1.1 tunnel mode为例,一个connection上可以发送多个消息,减少了创建connection的时间,减少了资源消耗。但它会增加message parsing的难度,因为需要它需要确定消息的边界也类型。如果是同一类型消息的bundle还好处理一点,因为长度和类型都是一样的;如果是多种消息的bundle,就需要使用TLV来定义消息,这更增加了消息处理的难度。 | |
雁过留声
“Patterns in network system design (3)”有6个回复
droplet,能否加入一些简单的case studay当你谈一下算法模型的prons, cons的时候?
droplet现在是不是在写提纲啊?等凑够23个再来写细节?呵呵
我的想法是如果能够配上图和相应的代码就更好了,但是画图需要时间,而开源代码要找到对应的东西还是比较困难(如果panaos开源了,可能好一点:)),我现在列出了30个左右的pattern,等写完了,再精简整理。有些东西只要说一下,懂行的人一看就明白是干什么的,太详细了反而是罗唆。
我个人认为droplet的这个工作有开创性的意义。。。写完后,我要弯曲评论荣誉出品推出。。。
发现很多模式真的是通用的,这里面列出的模式,其实在TCP/UDP协议上很多都有体现。可以见一通百通,诚不欺我。
高!实在是高!
5楼说的对。
其实,不论是在学的,还是在干的,玩味一下就能体会到。
这个是模型。
虽然我不变成,只动嘴,但是看完了想想,觉得透了(又想起了让子弹飞)。
再写别的东西,创造别的应用的时候,借鉴一下,删减一下,体系结构上至少不出大错!
好文,继续看。