Grid Ops专为分布式系统体系结构实验而设计。分布式系统的核心是网络上节点之间的通信。因此，Grid Ops旨在简化此通信。

基本上，Grid Ops旨在以各种配置实现客户端/服务器通信，无论是作为纯客户端，纯服务器，P2P节点(客户端和服务器)。此外，Grid Ops旨在在被动和主动模式，阻止和非阻止模式以及推和拉模式下支持客户端和服务器。我们将在本文档中看到所有这些外观和工作方式。

被动模式与主动模式

如前所述，Grid Ops支持被动和主动操作模式。

在被动模式下，在使用Grid Ops的应用程序调用Grid Ops API之前，Grid Ops不会执行任何操作。被动模式在桌面应用程序中非常有用，在桌面应用程序中，内部使用Grid Ops来实现连接到某个地方Grid Ops服务器的客户端，但仅当应用程序的用户采取行动时才如此。

在活动模式下，Grid Ops通常由一个或者多个独立线程"管理"，每个线程执行一个线程循环。线程循环保持迭代，直到请求关闭线程循环为止。线程循环对于实现需要连续检查传入消息的服务器很有用。

阻止与非阻止模式

Grid Ops的客户端和服务器可以在阻止和非阻止模式下运行。在阻止模式下，API会调用阻止，直到IO操作完成为止。例如，直到消息被完全接收或者消息被完全发送为止。

阻塞模式通常在被动模式下工作得最好，在被动模式下，从另一个线程(不是特定于线程循环的线程)调用Grid Ops API。特别是在调用线程除了等待IO API调用完成之外不能真正做其他有意义的事情的情况下。

在非阻塞模式下，IO API调用立即返回。如果部分收到了一条消息，则我们稍后必须再次致电，以检查是否收到了完整的消息。如果部分发送了一条消息，则我们稍后必须再次致电，以确保发送其余消息。

非阻塞模式通常在活动模式下效果最好，在活动模式下，线程循环不断检查新的传入消息，并连续检查是否已发送所有出站消息。

推与拉模式

Grid Ops旨在使我们可以在推或者拉模式下使用Grid Ops。

推送模式是我们习惯于从Java Servlet API或者其他反应性框架(如Netty，Vert.x等)使用的模式。收到消息后，将其推送到注册的组件中以处理此消息。这就是Servlet的工作方式。 HTTP请求到达时，将其推送到注册的Servlet中，以处理与给定URL匹配的请求。

拉模式是Grid Ops直到我们告知之前都不读取传入消息或者写入传出消息的时间。准备处理它们时，可以从Grid Ops API中提取新消息。

我们可能已经知道，推模式通常与主动模式配对，而拉模式通常与被动模式配对。但是，在表面之下，即使活动/推送模式也使用拉模式，先将消息从核心API中拉出，然后再将其推入已注册以处理它们的组件中。

线程循环

在活动模式下，Grid Ops组件由一个或者多个执行每个线程循环的线程管理。 Grid Ops带有不同的线程循环实现，每种实现都是针对特定情况或者用例而设计的。我们也可以实现自己的线程循环，但是必须进行大量内部Grid Ops组件维护才能使线程循环正确运行。

线程循环通常用于管理服务器。线程循环不断进行迭代，并且对于每次迭代，它都会寻找新的入站消息，如果有的话将对其进行处理，并检查未完全发送的出站消息。

线程循环演员

除了实现自己的线程循环，我们还可以实现线程循环参与者，然后将其插入线程循环。线程循环参与者通常在线程循环的每次迭代中被调用一次。

一些线程循环使线程循环参与者可以暂停一下。线程循环参与者仅告诉它应该暂停多长时间，直到下次调用它为止。如果所有线程循环参与者都要求暂停，则线程循环可以休眠，直到需要下一个第一个线程循环参与者为止。这将CPU释放给计算机上的其他任务，而不是无所事事地不断在线程循环中进行迭代。