分布式操作系统2.3-2.5.pptVIP

2.3 命名服务 2.3.1 概述（名字、属性、名字服务系统、名字服务的要求） 2.3.2 一般的命名方式 2.3.3 分布式系统中的命名方式 2.3.4 名字服务器的设计 2.3命名服务2.3.1概述 在一个分布式系统中，名字可用于指称或索引各种类型的资源，包括计算机、 服务、端口、个体对象以及用户。 分布式系统中资源的共享与通信需要名字； 用户(客户) 请求计算机操作诸多资源中的某特定的对象时需要使用名字； 进程之间不能共享由计算机系统管理的资源，除非它们能协调一致地对资源进行命名； 用户之间也不能通过分布式系统相互通信，除非他们能对其他用户进行命名。 一、名字与属性 名字，统称为名称(name) 人们可读的文本名，便于人们识别和记忆 系统标识符，软件用来对资源进行解释和存储的名字形式，是一个定长的位串 下面是几种名称： 物理网址和逻辑网址：这类名称可视为名字的位置或地址 端口、进程和组标识符：这类名称可视为消息的目的地 资源标识符：由服务器和内核管理的资源的低层独立定位的标识符 文件：使用人们可读的文本名字进行存取的信息集 一、名字与属性（续） 客户用文本名对资源的操作过程(Amoeda) 存取一个资源涉及到将其文件名映射成对应的资源标识符， 再将该资源标识符映射成一个端口标识符和一个特定服务的标识符； 然后将这个端口标识符映射成一个网络地址，将这个特定服务的标识符映射到相关服务器中的资源。 一、名字与属性（续）  分布式系统中使用的许多名称都是有特定含义的，客户(用户或进程) 使用这样的名称请求服务系统对它管辖的命名对象和资源进行操作。 若系统管理很多对象，那么每个对象都得命名，考虑到效率，这个名称应能直接映射它所代表的对象。 例如，当要求删除一个文件时，该文件的名称就被传递给文件服务系统；请求向一个进程发信号时，该进程的标识符被提供给进程管理系统。 这样一些名称仅用在管理这些命名对象的服务系统的上下文(共享对象除外) 中。 一、名字与属性（续）  引用超出任何单一服务系统范围的实体时，也要命名。典型例子包括： 用户(带有专用名、逻辑名、用户标识符和电子邮件地址等) 计算机(带有名字—宿主名，如mac41) 服务系统本身(如文件服务、打印服务等)。 所有这些名称必须是有意义的、可读的 因为用户和系统管理员需要通过这些名称访问分布式系统的主要组件和配置，程序员在编程过程中需要这些名称去访问相应的服务(系统) ，用户借助它们进行通信。 考虑到 Internet 提供的连接能力，这些命名要求在范围上应该是全球的。 一、名字与属性（续）  名称和对象之间的联结称为联编(binding)。 特定服务名被服务系统联编到相关对象或资源的实际表示上 用户名、计算机名和服务(系统)名被联编到命名对象的属性上，所有这些对象都把地址作为属性之一。 一般而言，属性值 或是基本值，如整数； 或是自身的名称，如 Internet 地址230.1 32.123.112等。 最终，所有的名称被简化成基本值或不能再进一步“查找”的基本名。与名称相关的属性不仅对用户而且对其他服务都是有用的。 例如，在电子邮件系统中，Internet域名系统(DNS)用来从电子邮件地址中查找邮件主机地址，但由另外的软件来传递和存储邮件消息。 二、名字服务系统 名字服务系统管理着一个联编数据库，其中存储着文本名(可读的)及其相关的属性。其支持的操作有： 解析一个名字——在该数据库中查找给定名字的相关属性； 为新名字生成新的联编； 删除联编； 列出已联编的名字等操作。 注意：虽然把联编集看作一个数据库，但一般说来名字不是简单键，常常由若干部分组成(例如，he@ncepu.edu.cn)，这些部分需在数据库的不同区域中分别查找，这些不同区域即上下文 (context)。 二、名字服务系统（续）  名字管理从其他服务中独立出来的原因： 很大程度上是因为分布式系统的开放性； 一致性 (unification) ：让不同的服务器或服务系统管理的资源出现在同一命名方案中似乎比较方便的。 例如在UNlX中的NFS中，一些文件在本地磁盘上管理，而另一些则在远程服务器上，所有的文件出现在单一的名字空间层次结构中。此外，一些“文件”的名字涉及到本地设备或命名过的管道。 …… 二、名字服务系统（续）  …… 集成(integration)：在分布式系统中，不一定总能预测共享的范围。有时候，需要共享和命名在不同管理域中创建的资源，这可能会引起问题， 例如，合并两个用户集，分配给每个用户的登录名可能会发生冲突。更坏的情况是，这两组用户可能有完全不同的命名规则。 三、名字服务的一般要求 名字服务越来越复杂。 几个例子： Grapevine：最早的可扩充多域名字