当今的应用系统，不管是c/s模式还是b/s模式。以及多层的分布式系统都是采用内容面向中心的。也就是说应用所要处理的数据都是在数据服务器上的，整个系统都是采用层状结构每一个终端用户都是孤立的，应用采用这种模式的优点和缺点分析：
优点：数据的来源集中存放在一个数据服务器上，也就是说数据源只有一个，在数据同步方面容易控制。2，数据安全性容易得到保证。3，终端用户的请求处理算法简单。（就是典型的请求/应答模式）。
缺点：服务器和主机的压力过大（它既要负责业务处理又要负责数据处理）。导致在大型的应用中，服务器的配置要求太高，提高了部署的成本。2，对终端用户资源的利用率不高，在瘦客户机模式下，客户机的资源利用率就更加低下。
在客户终端配置不断提升（一般现在的客户终端处理都具有3-4应用请求能力）和p2p技术迅速发展的今天。我们能不能采用新系统架构模式，
系统结构分析：
数据服务器：只是一个存储设备，不参加业务逻辑处理。这样做的原因是减低了系统对服务器的压力，也就服务器的配置要求降低了很多。降低了系统部署成本。
控制服务器：作为客户终端协同工作的控制器，就像马车有5-6匹马在跑的时候，马夫的作用。
在这个模型中，我们利用p2p技术，使每个终端客户都建立连接。使每个客户终端相对于整个系统来说都不再孤立。这样传统的客户中断将扮演双重角色，它既是是服务器（应答请求）又是客户端（也可以发出请求）。这样做的目的是：把原来服务器的任务，分配给多个客户，充分利用终端客户机的资源。提高整个系统的资源利用率。
这种模式的需要解决的几个问题：1。如何保证数据的同步2。数据安全性问题（因为在这个模式中每个客户断都有数据服务器一部分数据的备份）。3，终端客户连接算法的问题。
优点：数据的来源集中存放在一个数据服务器上，也就是说数据源只有一个，在数据同步方面容易控制。2，数据安全性容易得到保证。3，终端用户的请求处理算法简单。（就是典型的请求/应答模式）。
缺点：服务器和主机的压力过大（它既要负责业务处理又要负责数据处理）。导致在大型的应用中，服务器的配置要求太高，提高了部署的成本。2，对终端用户资源的利用率不高，在瘦客户机模式下，客户机的资源利用率就更加低下。
在客户终端配置不断提升（一般现在的客户终端处理都具有3-4应用请求能力）和p2p技术迅速发展的今天。我们能不能采用新系统架构模式，
系统结构分析：
数据服务器：只是一个存储设备，不参加业务逻辑处理。这样做的原因是减低了系统对服务器的压力，也就服务器的配置要求降低了很多。降低了系统部署成本。
控制服务器：作为客户终端协同工作的控制器，就像马车有5-6匹马在跑的时候，马夫的作用。
在这个模型中，我们利用p2p技术，使每个终端客户都建立连接。使每个客户终端相对于整个系统来说都不再孤立。这样传统的客户中断将扮演双重角色，它既是是服务器（应答请求）又是客户端（也可以发出请求）。这样做的目的是：把原来服务器的任务，分配给多个客户，充分利用终端客户机的资源。提高整个系统的资源利用率。
这种模式的需要解决的几个问题：1。如何保证数据的同步2。数据安全性问题（因为在这个模式中每个客户断都有数据服务器一部分数据的备份）。3，终端客户连接算法的问题。
>>这样传统的客户中断将扮演双重角色，它既是是服务器（应答请求）又是客户端（也可以发出请求）。这样做的目的是：把原来服务器的任务，分配给多个客户，充分利用终端客户机的资源。提高整个系统的资源利用率。你的意思是由控制服务器来在各个客户端之间协调（分配）原来应用服务器的工作是吗？先不说安全问题先，既然要分配，那么请求客户端就必须等待，然后控制服务器轮询（或者其他方法）客户端，找到空闲的客户端来执行这个原来应用服务器的工作，，，如果任务不是可以分割的，那么最终只能找到一个客户端来执行，如果是这样，是否有点骑牛找牛，海底掘渠？请求的客户端本身执行这个任务不就行了？如果任务是可以分割的并且任务的计算复杂度足以抵消分配任务和执行端同步的开销，这个方案才有价值，但是任务分割，首先要求任务有分割的可能性和必要性，要么负责分配任务的控制器分割这些任务，要么客户端的请求描述本身支持任务分割（显然客户端的就很复杂了），那到底我们通常应用服务器处理的是什么任务?像这样一个任务：select * from t1;这就没什么好分割的，update from t1 set ..也没什么好分割的，如果是一组sql语句或者其他计算任务，限于上下文的关联性，也不能分割(不是不能分割，是没有可行性），，，
去看看吧，我认为最好的办公软件
应该就是这种思想