ACE通信设计空间指导

这篇具有很好参考价值的文章主要介绍了ACE通信设计空间指导。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

ACE通信设计空间

通信是网络应用程序设计的基础。本章就通信设计空间做了领域分析，介绍了网络应用程序之间互相作用的规则、形式和抽象层次。

本章我们将讨论一下设计空间：

一、无连接协议和面向连接协议

所谓协议，就是一组规则，用来指定“控制信息”和“数据信息”如何在通信实体(譬如，在网络计算环境内部相互作用的应用程序进程)之间交换。协议一般分为无连接(connectionsless)和面向连接两种。

在这一设计空间，需要权衡的地方: 延迟、可伸缩性和可靠性。

1.1、无连接协议

无连接协议提供的是“面向消息”的服务。其中，每一条消息都可以独立寻址和发送。无连接协议一般采用“尽力”发送语义。这些语义不保证某组消息会以特定次序到达目的地，甚至根本不会到达目的地！

例如:UDP、 IP、这些协议可以直接被多媒体应用使用。这些应用允许一定程度的数据丢失。UDP/IP还支持多播和广播功能。

1.2、面向连接协议

面向连接协议提供的是可靠、有序、不重复的发送服务。对那些不允许数据丢失的应用程序来说，这种协议十分有用。

为了提高性能并保证可靠性，“面向连接”协议在发送端和接收端交换并维护状态信息。

例如：TCP协议，它被使用到很多“面向会话”的Internet应用中。如Web服务和电子邮件中。

使用面向连接协议时，应用程序和中间件开发者还必须作出以下设计选择:

1.2.1、数据成帧策略(想问问，是防止粘包吗？)

"面向连接"协议提供了不同种类的数据成帧策略。例如, “面向消息”发送策略为某些“面向连接”协议所支持，如TP4和XTP。相反，TCP是一种字节流协议，不保护应用程序消息的边界。因此，在TCP上，如果某一应用程序通过4个send()调用传输4条不同的消息，会有一个或多个TCP数据段被传输给接收端。所以，如果某一应用程序需要"面向消息"发送，发送端和接收端就必须执行额外的处理，以将4条仔TCP上交换的消息分割成帧。如果消息的长度总相同，并且永远没有网络错误发生，成帧相对来说简单：否则，这会成为一个不小的问题。譬如：粘包的处理。

1.2.2、连接多路复用策略

在“面向连接”协议上传输数据，有这样两个一般性的策略：

多路复用(multiplexed)。一个进程中的多个线程发出的所有客户请求都通过一条TCP连接传递给一个服务器进程，连接多路复用的一个优点是，节省OS的通信资源，如socket句柄和连接控制块。这个策略的缺点是，难以编程缺乏效率、缺乏确定性。这些问题源自“同步”机制和“环境切换”机制；在多路连接上，这些机制用来将"请求"和"应答"联系起来。
非多路复用(nonmultiplexed)
每一个客户都使用不同的连接和对等服务程序通信。它的主要优点是，可以更好地控制通信的优先级。在“非多路复用连接”设计中，每一个连接的优先级可以单独设定。这样一来，即使其他线程之间存在大量低优先通信任务，高优先级通信也可以快速完成。这种设计避免了优先级倒置现象————即低优先级线程占用一个单独的多路连接。此外，因为连接没有被共享，这个策略的同步开销很小，因为发送和接收双向请求时不需要额外的锁定工作(加锁操作)。和“多路复用连接”策略相比，“非多路复用”策略需要使用更多的OS资源，因而，在某些环境中其伸缩性可能不是很好。

关于连接“多路复用”策略的设计及其利弊，请参阅[SMFGG01][SSRM00]提供的其他资料。

日志服务程序===>在网络日志服务程序的实现中，我们通过“面向连接”的TCP/IP协议将日志记录从客户应用程序传输给日志服务器。我们只建立一次连接，并在客户/服务器会话期间保留它，这样使建立连接的开销最低。连接采用的是“非多路复用”方式，每个日志客户程序分别打开一个“到日志服务器”的TCP连接。

选择TCP，就需要在TCP字节流上实现“数据分帧”机制(副栏9就这一点做了演示)。但由于TCP的普及，这一工作不会白费，它会带来OS平台之间、数据链路层网络之间的互操作性和可移植性。此外，传输层( 而非应用程序)负责流量(flow)控制和拥塞控制，负责重新传输丢失的数据包，并保证数据以正确的顺序发送。（这里可以测试一个丢包的的验证程序，测试拥塞控制导致的丢包）。对那些不能丢失日志记录的应用程序来说，这些能力很重要。

二、同步和异步消息交换

在很多网络应用程序中, 客户向服务器发送一个请求，后者处理这个请求，然后返回一个应答。这种请求/应答协议既可以在无连接协议上实现，也可以在面向连接协议上实现。

管理请求/应答协议交换的可选策略有两种：同步(sync)和异步(async)。

选择同步还是异步消息交换策略，要考虑因素:

请求之间的关联性。
底层协议或传输介质的延迟。

以下，我们来看看这些因素如何影响到策略的选择。

2.1同步请求/应答协议。

这是最容易实现的形式。在这种协议中，请求和应答是以锁步次序交换的。每一个请求必须同步地接收到一个应答，然后才能发送下一个请求。这种同步请求/应答协议适用以下场合。

请求的结果决定后续的请求。例如，某一应用程序需要交换验证信息，那么，在安全认证信息成功交换之前，它不会发送机密信息请求。这里可以看看TLS/SSL的工作机制，就是请求应答协议的一个适用场合。
应用程序中交换的信息需要再低延迟网络中执行短期处理。如高速LAN中的NFS read() 和 write()操作。
较之后文介绍的异步请求/应答协议有可能获得的“性能上的提高”，“实现的简易性”或“协议交换的少量性”更为重要。

2.2异步请求/应答协议

它将请求从客户连续发送至服务器，无需同步地等待应答。多个客户请求可以在服务器应答到达之前发送。因此异步请求/应答协议往往需要一种策略，用来检查请求的丢失或失败，然后重新发送。异步请求/应答协议适用于以下场合：

无需应答就可以决定后续请求。例如，Web浏览器可以使用异步策略，用于从同一个服务器获取多个嵌入图像。因为每一个请求都是独立的，它们全都可以异步发送，不必等待应答。浏览器利用每一个应答中包含的信息，将应答匹配相应的请求————即使应答的顺序不同于请求的发送顺序。
“通信的延迟”和“请求所需的处理时间”密切相关。异步请求策略有助于有效地利用网络，减少高延迟带来的影响。较之将“应答”和“请求”关联起来并实现“重试”策略所带来的额外复杂度，它在性能上的提高更为重要。

日志服务程序===>在网络日志服务器中，我们使用的是异步请求/应答协议的单向形式，所以不需要应用程序级响应。日志记录只是从客户应用程序传给日志服务器；也就是说，不需要服务器在应用程序级作出应答。

日志服务器在接收到每一条日志记录后，都会将记录立即写入磁盘，并假设每一条发送出来的日志记录都可被可靠地记录了下来。只要客户程序不需要网络日志服务程序采取"强烈"手段来确保所有日志记录都被永久存储————即使有灾难性的故障发生————这个设计就已经足够了。如果真的有那样的需求，我们就得开发“基于事务”的日志服务；那将会更复杂，还会带来显著的时间/空间开销。

三、消息传递和共享内存

到目前为止，我们关于协议的讨论都基于一个假设：信息是在不同计算机的对等体之间传输。这类交换被称为“消息传递”。如果通信实体可以访问一块共享内存，就会导致另一种不同的信息交换方式。本节将讲述这两种机制，以及它们的利弊。

3.1 消息传递(message passing)

明确地通过IPC机制来交换字节流和“面向记录”的数据；关于IPC机制，我们将在第2章讲述。通常，应用程序开发者得定义这些信息的格式和内容，以及应用协议；

参与者必须遵守这一协议，以交换信息。这一协议还定义了每个交换中可能得参与者的数量(譬如：点对点、多播，广播)，以及参与者如何启动、管理和终止“消息传递会话”。

“消息传递”IPC机制通过IPC信道，将数据以消息的形式从一个进程或线程传输给另一个进程或线程。如果传输的数据量很大，这些数据就会被分段，以消息序列的形式发送。如果有一个以上的进程接收数据，则每一条消息会发送多次，每一次针对一个接收者。很多流行的中间件体系结构，譬如，RPC、CORBA和 “面向消息”中间件，其内部都基于“消息传递”通信模型。

3.2 共享内存

共享内存允许相同或不同主机上的多个进程访问、交换数据，就像数据位于每一个进程的本地地址空间一样。在网络应用程序中，如果数据必须被多个进程读取和处理，那么，较之“消息传递”，“共享内存”设施将是一种更有效的通信机制。如果要在应用程序中使用原始的OS“共享内存”机制，则应用程序不用定义“信息在实体间的传输方法”，它要定义如何定位(locate)和映射(map)共享内存区，还要定义“放在共享内存中”的数据结构。

共享内存有本地和分布式两种形式：

3.2.1 本地共享内存

允许同一计算机上的进程拥有一个或多个共享内存区, 这些内存区被映射为不同的虚拟地址范围。常见的共享内存机制有两种:

System V UNIX共享内存
shmget()系统函数创建一块新的共享内存区，或返回一块可用的共享内存区。进程可以通过shmat()系统函数将一块共享内存区挂接到它的虚拟地址空间上。
内存映射文件
一个文件的“全部”或“局部”可以映射到一块虚拟内存区中，此虚拟内存被多个进程共享。内存映射文件的内容可以转储到永久存储器中；因而，它提供了一条“在执行程序之间保存和恢复信息”的捷径。

这两种机制中，有了OS，多个进程可以将共享内存区映射到它们的地址空间中，所有可以映射共享内存区的进程都可以直接读写共享内存中的内容。

尽管共享内存很灵活，但是，通过共享内存进行多进程间通信，还是需要细致的编程。譬如：应用程序开发者必须保证：共享数据不能被"竞太条件"破坏。第10章，我们将讲述系统范围同步机制，这种机制可以对一块共享内存区实施串行化(serialization)控制，使得共享信息能够以一种有序的方式被访问。同样，如果应用程序需要再共享内存中存储C++对象，也得认真设计。

3.2.2 分布式共享内存(DSM)

分布式共享内存是程序设计中的一种抽象，它扩展了OS虚拟内存机制，以供应程序所需。虚拟内存提供了一组策略。用于在需要时获取、放置、替换一组内存页。从而给程序造成一种假象，认为自己拥有一块比实际物理内存大得多的地址空间。DSM在网络上扩展了虚拟内存的概念，以通过全局/共享内存中的数据进行透明的进程间通信。它体现了两种计算范式的结合：共享内存多处理器和分布式系统。

譬如：在一些硬件/软件平台上，多台计算机被集群为一套逻辑系统，系统中的内存在集群中共享。应用程序通过共享内存通信，共享内存由网络计算机共同管理。DMS系统提供了相应的机制，以配合进程和网络节点的更新。通常，这种通信模型会在底层使用"消息传递"机制，用来协调数据交换，使读取者和写入者同步。

日子服务程序===>在网络日志服务程序中，我们使用了一种实现在TCP/IP之上的“消息传递”IPC模型。一般来说，较之开发DSM机制并通过复杂的“分布式高速缓存一致性协议”来管理它，使用消息传递IPC更实际。由于DSM是一项高级研究课题，不常见于实际应用之中，关于DSM方面的研究，介绍比较好的参考文件[NL91][PIM97]文章来源地址https://www.toymoban.com/news/detail-684296.html