⭐ 欢迎来到虫虫下载站！ | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站
📤 上传资源

📄 2-2.htm

📁 WinSock编程规范及应用
💻 HTM
字号:
🔍 
<html>
<head>
<title>2-2</title>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
</head>

<body bgcolor="#FFFFFF">
<table width="100%" border="0">
  <tr> 
    <td height="29"> 
      <div align="center"><b><font color="#000066">2.2 套接口</font></b></div>
    </td>
  </tr>
  <tr> 
    <td height="32">2.2.1 基本概念</td>
  </tr>
  <tr> 
    <td height="122">通讯的基石是套接口，一个套接口是通讯的一端。在这一端上你可以找到与其对应的一个名字。一个正在被使用的套接口都有它的类型和与其相关的进程。套接口存在于通讯域中。通讯域是为了处理一般的线程通过套接口通讯而引进的一种抽象概念。套接口通常和同一个域中的套接口交换数据（数据交换也可能穿越域的界限，但这时一定要执行某种解释程序）。Windows 
      Sockets规范支持单一的通讯域，即Internet域。各种进程使用这个域互相之间用Internet协议族来进行通讯（Windows Sockets 
      1.1以上的版本支持其他的域，例如Windows Sockets 2）。 </td>
  </tr>
  <tr> 
    <td height="47">套接口可以根据通讯性质分类；这种性质对于用户是可见的。应用程序一般仅在同一类的套接口间通讯。不过只要底层的通讯协议允许，不同类型的套接口间也照样可以通讯。</td>
  </tr>
  <tr> 
    <td height="95">用户目前可以使用两种套接口，即流套接口和数据报套接口。流套接口提供了双向的，有序的，无重复并且无记录边界的数据流服务。数据报套接口支持双向的数据流，但并不保证是可靠，有序，无重复的。也就是说，一个从数据报套接口接收信息的进程有可能发现信息重复了，或者和发出时的顺序不同。数据报套接口的一个重要特点是它保留了记录边界。对于这一特点，数据报套接口采用了与现在许多包交换网络（例如以太网）非常类似的模型。 
    </td>
  </tr>
  <tr> 
    <td height="47">2.2.2 客户机/服务器模型</td>
  </tr>
  <tr> 
    <td>一个在建立分布式应用时最常用的范例便是客户机/服务器模型。在这种方案中客户应用程序向服务器程序请求服务。这种方式隐含了在建立客户机/服务器间通讯时的非对称性。客户机/服务器模型工作时要求有一套为客户机和服务器所共识的惯例来保证服务能够被提供（或被接受）。这一套惯例包含了一套协议。它必须在通讯的两头都被实现。根据不同的实际情况，协议可能是对称的或是非对称的。在对称的协议中，每一方都有可能扮演主从角色；在非对称协议中，一方被不可改变地认为是主机，而另一方则是从机。一个对称协议的例子是Internet中用于终端仿真的TELNET。而非对称协议的例子是Internet中的FTP。无论具体的协议是对称的或是非对称的，当服务被提供时必然存在"客户进程"和"服务进程"。</td>
  </tr>
  <tr> 
    <td>一个服务程序通常在一个众所周知的地址监听对服务的请求，也就是说，服务进程一直处于休眠状态，直到一个客户对这个服务的地址提出了连接请求。在这个时刻，服务程序被"惊醒"并且为客户提供服务－对客户的请求作出适当的反应。这一请求/相应的过程可以简单的用图2-1表示。虽然基于连接的服务是设计客户机/服务器应用程序时的标准，但有些服务也是可以通过数据报套接口提供的。 
    </td>
  </tr>
  <tr> 
    <td> 
      <div align="center"><img src="Image3.gif" width="454" height="370"></div>
    </td>
  </tr>
  <tr> 
    <td height="31">2.2.3 带外数据</td>
  </tr>
  <tr> 
    <td height="111">注意：以下对于带外数据（也称为TCP紧急数据）的讨论，都是基于BSD模型而言的。用户和实现者必须注意，目前有两种互相矛盾的关于RFC 
      793的解释，也就是在这基础上，带外数据这一概念才被引入的。而且BSD对于带外数据的实现并没有符合RFC 1122定下的主机的要求，为了避免互操作时的问题，应用程序开发者最好不要使用带外数据，除非是与某一既成事实的服务互操作时所必须的。Windows 
      Sockets提供者也必须提供他们的产品对于带外数据实现的语义的文挡（采用BSD方式或者是RFC 1122方式）。规定一个特殊的带外数据语义集已经超出了Windows 
      Sockets规范的讨论范围。</td>
  </tr>
  <tr> 
    <td height="126">流套接口的抽象中包括了带外数据这一概念，带外数据是相连的每一对流套接口间一个逻辑上独立的传输通道。带外数据是独立于普通数据传送给用户的，这一抽象要求带外数据设备必须支持每一时刻至少一个带外数据消息被可靠地传送。这一消息可能包含至少一个字节；并且在任何时刻仅有一个带外数据信息等候发送。对于仅支持带内数据的通讯协议来说（例如紧急数据是与普通数据在同一序列中发送的），系统通常把紧急数据从普通数据中分离出来单独存放。这就允许用户可以在顺序接收紧急数据和非顺序接收紧急数据之间作出选择（非顺序接收时可以省去缓存重叠数据的麻烦）。在这种情况下，用户也可以"偷看一眼"紧急数据。</td>
  </tr>
  <tr> 
    <td height="112">某一个应用程序也可能喜欢线内处理紧急数据，即把其作为普通数据流的一部分。这可以靠设置套接口选项中的SO_OOBINLINE来实现（参见5.1.21节，setsockopt()）。在这种情况下，应用程序可能希望确定未读数据中的哪一些是"紧急"的（"紧急"这一术语通常应用于线内带外数据）。为了达到这个目的，在Windows 
      Sockets的实现中就要在数据流保留一个逻辑记号来指出带外数据从哪一点开始发送，一个应用程序可以使用SIOCATMARK ioctlsocket()命令（参见5.1.12节）来确定在记号之前是否还有未读入的数据。应用程序可以使用这一记号与其对方进行重新同步。</td>
  </tr>
  <tr> 
    <td height="27">WSAAsyncSelect()函数可以用于处理对带外数据到来的通知。</td>
  </tr>
  <tr> 
    <td height="35">2.2.4 广播</td>
  </tr>
  <tr> 
    <td height="114">数据报套接口可以用来向许多系统支持的网络发送广播数据包。要实现这种功能，网络本身必须支持广播功能，因为系统软件并不提供对广播功能的任何模拟。广播信息将会给网络造成极重的负担，因为它们要求网络上的每台主机都为它们服务，所以发送广播数据包的能力被限制于那些用显式标记了允许广播的套接口中。广播通常是为了如下两个原因而使用的：1. 
      一个应用程序希望在本地网络中找到一个资源，而应用程序对该资源的地址又没有任何先验的知识。2. 一些重要的功能，例如路由要求把它们的信息发送给所有可以找到的邻机。</td>
  </tr>
  <tr> 
    <td height="61">被广播信息的目的地址取决于这一信息将在何种网络上广播。Internet域中支持一个速记地址用于广播－INADDR_BROADCAST。由于使用广播以前必须捆绑一个数据报套接口，所以所有收到的广播消息都带有发送者的地址和端口。</td>
  </tr>
  <tr> 
    <td>某些类型的网络支持多种广播的概念。例如IEEE802.5令牌环结构便支持链接层广播指示，它用来控制广播数据是否通过桥接器发送。Windows 
      Sockets规范没有提供任何机制用来判断某个应用程序是基于何种网络之上的，而且也没有任何办法来控制广播的语义。 </td>
  </tr>
</table>
<p>&nbsp; </p>
</body>
</html>

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -