è可以选择采用单播、广播或组播发送协议报文
因为分布式系统使用分布式算法，所以它的同步机制比集中式系统更为复杂。在集中式系统中能够做到的，在某一位置上能集收到系统的所有信息，然后由某些进程检测这些信息，再做出同步决策，而这在分布式系统中常常是不可能做到的。分布式算法一般有以下特点：
1)相关信息分布在多台机器上。
2)进程只根据本地可用的信息做出决策。
3)应避免系统中单机失效。
4)没有公共时钟或其他**的全局时间源。
前面三点都是说在处理过程中的单个点上无法收集到系统的所有信息。例如，在做资源分配(以不会出现死锁的方式分配I／O设备)时，通常不应将所有的UO请求发送给一个管理进程.管理进程检查所有的I/O请求，根据其设备表中的信息决定满足请求或拒绝请求。在大系统中，将所有的请求发送给单个管理进程，会使这个进程的负担过重。而且象这样的单机失效会使整个系统变得不可靠。理想情况下，分布式系统应该比单机更可靠。如果分布式系统中某台机器停止工作，剩余的机器应该能够继续完成系统功能。*不希望看到的是，由于某台机器的失败(如资源分配器)导致许多其他机器(如它的客户)终止工作。为了在没有集中控制的情况下实现同步，需要采取与传统操作系统不同的方式。
上面列出的第4点也很重要。在集中式系统中，时间是很明确的。每个进程要知道当前时间，只要执行一个系统调用，操作系统内核就会返回当前系统时间给进程。如果进程A查询了系统时间，稍后进程B也去查询系统时间，那么进程B得到的时间将在进程A得到的时间值之后(也可能相等)，肯定不会在此之前。分布式系统中，要达到这种时间的一致性不是件简单的事。
作为一个简单例子，考虑一下缺乏全局一致的时间对UNIX中make程序的意义。在UNIX中，大型程序通常分割成多个源文件，这样在修改某个文件时只要编译这一个文件，而不是编译所有的文件。如果程序有一百个文件，则不需因为有一个文件发生了较大的变化而重新编译所有文件，从而大大加快了程序员工作的速度。
通常，make程序的工作方式很简单。程序员在修改源文件后，启动nla~e。Make程序检查源文件及与它相应的目标文件的*后修改时间。如果源文件input．C的*后修改时间为2151，而相应目标程minput．o的*后修改时间为2150，make程序就可以确定在创建input．o后，修改了源文件input．C，因此要重新编译源文件input．C。相反，如果output．c的*后修改时间为2144，而output,o的*后改时间为2145，就不需要重新编译output，c了。Make程序遍历所有的源文件，找
出需要重新编译的文件，调用编译器编译这些文件。
现在，想象在没有全局—致时间的分布式系���中执行make程序。假设ouput．o的*后修改时间还是2144，随即修改了源文件output．c，但是由于编辑output．c的机器的时钟慢，所以修改后output．c的*后时间被指定为2143，如图11-1所示．这时，make程序就不会重新编译output.c结果，生成的可执行文件就包括由旧的源文件生成的目标文件和新的源文件产生的目标文件。这样，程序的运行就会存在问题，而程序员要在代码中找到问题的出处，也是大伤脑筋的事。
上面我们看到，时间是人们考虑问题的基础，时钟之间的不同步会产生戏剧性的结果。因此，以“分布系统中的所有时钟可能同步吗?”这样一个简单问题开始研究同步是比较合适的。