linux中什么是ptlib

ptlib 就是指pwlib

PWLib是Portable Windows

Library的缩写,翻译为轻便的Windows类库.PWLib采用C++编写,设计初衷是为了能让Openh323在Windows和Unix的

X-Windows下运行,

不过随着一步步的完善PWLib已经被跨平台的程序所广泛采用.在最新的Pandora版本中,Equivalence已经停止了PWLib中GUI部分

的开发,全面转向了更能为Openh323所利用的PTLib,GUI部分交给了wxWindows来完成.PWLib主要功能侧向网络,I/O和多线

程,主要用在高性能的可移植网络程序.

PWLib分为两部分:基类部分和控制台部分.基类部分主要包括网络,多线程,ASN等...,所有使用PWLib的应用程序必然用到基类部分.而控制台部分则定义了一些基本的数据和设备类型,它是可选的,不过要方便移植的话还是要用到它.

下面从Hello World开始说PWLib框架:

#include //所用使用PWLib都用包含的头文件

class Hello : public PProcess //继承主线程类PProcess

{

PCLASSINFO(Hello, PProcess) //连接PProcess的运行时函数

public:

void Main() //主线程是从PProcess的Main()开始的

}

PCREATE_PROCESS(Hello) //定义Main()函数和初始化Hello类

void Hello::Main()

{

cout <<"Hello world!\n"

}

下面详细介绍各个类:

基本对象类:

PObject - PWLib中的根类,所有的类都派生于此

PContainer - 抽象容器类

PAbstractArray - 所有数组对象的基类

PAbstractList - 所有列表对象的基类

PAbstractDictionary - 字典对象的基类

PString - 字符类,在Openh323中随处可见

I/O通道类

PChannel - I/O通道的基类,下面类都派生于此

PIndirectChannel - 可以交换的 *** 作不同的I/O通道

PConsoleChannel - 进入系统命令行的通道

PPipeChannel - 在当前进程和子进程剪建立管道

PSerialChannel - 串口通信通道

PFile - 文件 *** 作类.

PTextFile - 文本文件 *** 作类

PStructuredFile - 结构文件 *** 作类,不同 *** 作文件类型都不尽相同

PFilePath -对文件的路径描述的类

PVideoChannel - 视频的输入,输出通道,采用YUV格式

PSoundChannel - 音频的输入,输出通道,使用线性的PCM通道

套接字类:

PSocket - 套接字的基类,所有网络 *** 作类派生于此

PIPSocket - IP协议层的描述类

PUDPSocket - IP协议中UDP描述类

PTCPSocket - IP协议中TCP/IP描述类

PICMPSocket - IP协议中ICMP描述类

PIPXSocket - IPX协议的基类

PEthSocket - 底层的以为网接口类,可以直接 *** 作底层数据包

进程和线程类:

PProcess - 实现程序的主线程控制类

PServiceProcess - 后台程序或系统进程使用的类

PThread - 普通线程的控制类

PSemaphore - 使用信号量的线程同步类

PMutex - 使用互斥对象的线程同步类

PCriticalSection - 使用临界区的线程同步类

PSyncPoint - 使用事件的线程同步类

PAtomicInteger - 描述了信号量及PV *** 作

其他杂类:

PArgList - 命令行参数类

PConfig - 存储应用程序的配置内容

PTime - 时间和日期的抽象类

PTimeInterval - 以毫秒为单位的记时类

PDynaLink - 动态连接类

PRemoteConnection - 网络连接控制类

PMail - 调用系统默认程序发邮件

PPluginManager - 插件管理模块

PSmartPointer - 智能指令类

PNotifier - 通告类,可以调用任何类的任何函数

PSmartNotifierFunction - 智能的通告函数类,使用对象ID

控制台部分:

HTTP协议类:

PHTTP - HTTP协议基类

PURL - URL的具体描述

PHTML - HTML的具体描述

PHTTPServiceProcess - 后台的HTTP服务程序类

其他协议类

PInternetProtocol - Interner文本协议基类

PPOP3 - POP3协议的基类

PSMTMP - SMTP协议的基类

PFTP - FTP协议的基类

PMIMEInfo - 描述MIME信息

PTelnetSocket - 描述TELNET协议

PSocksProtocol - Socks协议的基类

PSTUNClient - 实现STUN登陆 *** 作

PSNMP - SNMP协议的基类

PSSLChannel - 在OpenSSL基础上建立的SSL协议类

PSASL - 在Cyrus SASL基础上建立的SAS协议L类

PXMLRPC - 在XML和HTTP基础上建立的XMLRPC协议描述

PSOAPClient - 实现SOAP登陆

PLDAPSession - 使用OpenLDAP进行LDAP登陆

PILSSession - 使用OpenLDAP进行ILS登陆

XMPP::Stream - 实现XMPP(Jabber)流

其他杂类:

PModem - *** 作Modem,使用AT命令和Modem串口通信

PIpAccessControlList - 子网掩码的描述

PRandom - 产生随机数类

PCypher - 不同编码的解码和编码

PWAVFile - AIFF格式的WAV文件 *** 作类

PDTMFDecoder - 对PCM流进行DTMF解码

PMemoryFile - 让数据存储在内存中

PSDLVideoDevice - 使用SDL库实现视频设备

PXML - XML的解析器

PVXMLChannel - VXML的解析器

PTextToSpeech - 实现文本到语音的语音合成转换

1  tcpmux  TCP 端口服务多路复用

2  rje  远程作业入口

3  echo  Echo 服务

4  discard  用于连接测试的空服务

5  systat  用于列举连接了的端口的系统状态

6  daytime  给请求主机发送日期和时间

7  qotd  给连接了的主机发送每日格言

8  msp  消息发送协议

9 chargen  字符生成服务；发送无止境的字符流

10  ftp-data  FTP 数据端口

11  ftp  文件传输协议（FTP）端口；有时被文件服务协议（FSP）使用

12  ssh  安全 Shell（SSH）服务

13  telnet  Telnet 服务

14  smtp  简单邮件传输协议（SMTP）

15  time  时间协议

16  rlp  资源定位协议

17  nameserver  互联网名称服务

18  nicname  WHOIS 目录服务

19  tacacs  用于基于 TCP/IP 验证和访问的终端访问控制器访问控制系统

20  re-mail-ck  远程邮件检查协议

21  domain  域名服务（如 BIND）

22  whois++  WHOIS++，被扩展了的 WHOIS 服务

23  bootps  引导协议（BOOTP）服务；还被动态主机配置协议（DHCP）服务使用

24  bootpc  Bootstrap（BOOTP）客户；还被动态主机配置协议（DHCP）客户使用

25  tftp  小文件传输协议（TFTP）

26  gopher  Gopher 互联网文档搜寻和检索  

NAT有两大类，基本NAT和NAPT。

静态NAT：一个公网IP对应一个内部IP，一对一转换

动态NAT：N个公网IP对应M个内部IP，不固定的一对一转换关系

现在基本使用这种，又分为对称和锥型NAT。

锥型NAT ，有完全锥型、受限制锥型、端口受限制锥型三种：

对称NAT ：

把所有来自相同内部IP地址和端口号，到特定目的IP地址和端口号的请求映射到相同的外部IP地址和端口。如果同一主机使用不同的源地址和端口对，发送的目的地址不同，则使用不同的映射。只有收到了一个IP包的外部主机才能够向该内部主机发送回一个UDP包。对称的NAT不保证所有会话中的(私有地址，私有端口)和(公开IP，公开端口)之间绑定的一致性。相反，它为每个新的会话分配一个新的端口号。

对称NAT是一个请求对应一个端口，非对称NAT是多个请求对应一个端口(象锥形，所以叫Cone NAT)。

连接服务器为A，NAT检测服务器为B。

第一步：当一个接收客户端(Endpoint-Receiver ,简称 EP-R)需要接收文件信息时，在其向连接服务器发送文件请求的同时紧接着向检测服务器发送NAT检测请求。此处再次强调是“紧接着”，因为对于对称型NAT来说，这个 *** 作可以直接算出其地址分配的增量(⊿p)。

第二步：当EP-R收到A或B的反馈信息时发现其外部地址与自身地址不同时就可以确定自己在NAT后面；否则，就是公网IP。

第三步：由服务器A向B发送其获得的EP-R的外部映射地址(IPa/Porta)，服务器B获得后进行比较，如果端口不同，则说明这是对称型NAT，同时可以直接计算出其分配增量：

⊿p=Portb-Porta

第四步：如果端口号相同，则由B向EP-R的Porta发送连接请求，如果EP-R有响应，则说明EP-R没有IP和Port的限制，属于全ConeNAT类型。

第五步：如果没有响应，则由服务器B使用其新端口b’向EP-R的Portb端口发送连接请求，如果有响应，则说明EP-R只对IP限制，属于限制性ConeNAT类型；否则就是对IP和port都限制，属于端口限制性ConeNAT类型。

通过上述五步基本可以全部检测出EP-R是否在公网，还是在某种NAT后面。

这也是一项可选配置任务，可根据需要为NAT 地址映射表配置老化时间，以控制用户对NAT 配置的使用，确保内、外网的通信安全。

配置NAT 地址映射表项老化时间的方法也很简单，只须在系统视图下使用firewall-nat session { dns | ftp | ftp-data | http | icmp | tcp | tcp-proxy | udp | sip | sip-media | rtsp |rtsp-media }aging-time time-value 命令配置即可。参数 time-value的取值范围为1～65 535的整数秒。如果要配置多个会话表项的超时时间需要分别用本命令配置。

缺省情况下，各协议的老化时间为：DNS（120 s）、ftp（120 s）、ftp-data（120 s）、HTTP（120 s）、icmp（20 s）、tcp（600 s）、tcp-proxy（10 s）、udp（120 s）、sip（1 800 s）、sip-media （ 120 s ）、rtsp （ 60 s ）、rtsp-media （ 120 s ）， 可用undo firewall-natsession { all | dns | ftp | ftp-data | http | icmp | tcp | tcp-proxy | udp | sip | sip-media | rtsp |rtsp-media } aging-time 命令恢复对应会话表项的超时时间为缺省值。

1、 中间服务器保存信息、并能发出建立UDP隧道的命令

2、 网关均要求为Cone NAT类型。Symmetric NAT不适合。

3、 完全圆锥型网关可以无需建立udp隧道，但这种情况非常少，要求双方均为这种类型网关的更少。

4、 假如X1网关为Symmetric NAT， Y1为Address Restricted Cone NAT 或Full Cone NAT型网关，各自建立隧道后，A1可通过X1发送数据报给Y1到B1(因为Y1最多只进行IP级别的甄别)，但B2发送给X1的将会被丢弃（因为发送来的数据报中端口与X1上存在会话的端口不一致，虽然IP地址一致），所以同样没有什么意义。

5、 假如双方均为Symmetric NAT的情形，新开了端口，对方可以在不知道的情况下尝试猜解，也可以达到目的，但这种情形成功率很低，且带来额外的系统开支，不是个好的解决办法。

6、 不同网关型设置的差异在于，对内会采用替换IP的方式、使用不同端口不同会话的方式，使用相同端口不同会话的方式；对外会采用什么都不限制、限制IP地址、限制IP地址及端口。

7、 这里还没有考虑同一内网不同用户同时访问同一服务器的情形，如果此时网关采用AddressRestricted Cone NAT 或Full Cone NAT型，有可能导致不同用户客户端可收到别人的数据包，这显然是不合适的。

为什么网上讲到的P2P打洞基本上都是基于UDP协议的打洞？难道TCP不可能打洞？还是TCP打洞难于实现？

假设现在有内网客户端A和内网客户端B，有公网服务端S。

如果A和B想要进行UDP通信，则必须穿透双方的NAT路由。假设为NAT-A和NAT-B。

S也和A B 分别建立了会话，由S发到NAT-A的数据包会被NAT-A直接转发给A，

由S发到NAT-B的数据包会被NAT-B直接转发给B，除了S发出的数据包之外的则会被丢弃。

所以：现在A B 都能分别和S进行全双工通讯了，但是A B之间还不能直接通讯。

并转发给A了（即B现在能访问A了）；再由S命令B向A的公网IP发送一个数据包，则

NAT-B能接收来自NAT-A的数据包并转发给B了（即A现在能访问B了）。

以上就是“打洞”的原理。

<pre style="margin: 0pxpadding: 0pxwhite-space: pre-wrapoverflow-wrap: break-word">为了保证A的路由器有与B的session，A要定时与B做心跳包，同样，B也要定时与A做心跳，这样，双方的通信通道都是通的，就可以进行任意的通信了。</pre>

API造成的。

UDP的socket允许多个socket绑定到同一个本地端口，而TCP的socket则不允许。

这是这样一个意思：A B要连接到S，肯定首先A B双方都会在本地创建一个socket，

去连接S上的socket。创建一个socket必然会绑定一个本地端口（就算应用程序里面没写

端口，实际上也是绑定了的，至少java确实如此），假设为8888，这样A和B才分别建立了到

S的通信信道。接下来就需要打洞了，打洞则需要A和B分别发送数据包到对方的公网IP。但是

问题就在这里：因为NAT设备是根据端口号来确定session，如果是UDP的socket，A B可以

分别再创建socket，然后将socket绑定到8888，这样打洞就成功了。但是如果是TCP的

socket，则不能再创建socket并绑定到8888了，这样打洞就无法成功。

**UDP打洞**的过程大致如此：

1、双方都通过UDP与服务器通讯后，网关默认就是做了一个外网IP和端口号 与你内网IP与端口号的映射，这个无需设置的，服务器也不需要知道客户的真正内网IP

2、用户A先通过服务器知道用户B的外网地址与端口

3、用户A向用户B的外网地址与端口发送消息，

4、在这一次发送中，用户B的网关会拒收这条消息，因为它的映射中并没有这条规则。

5、但是用户A的网关就会增加了一条允许规则，允许接收从B发送过来的消息

6、服务器要求用户B发送一个消息到用户A的外网IP与端口号

7、用户B发送一条消息，这时用户A就可以接收到B的消息，而且网关B也增加了允许规则

8、之后，由于网关A与网关B都增加了允许规则，所以A与B都可以向对方的外网IP和端口号发送消息。

TCP打洞 技术：

tcp打洞也需要NAT设备支持才行。

tcp的打洞流程和udp的基本一样，但tcp的api决定了tcp打洞的实现过程和udp不一样。

tcp按cs方式工作，一个端口只能用来connect或listen，所以需要使用端口重用，才能利用本地nat的端口映射关系。（设置SO_REUSEADDR，在支持SO_REUSEPORT的系统上，要设置这两个参数。）

连接过程：（以udp打洞的第2种情况为例（典型情况））

nat后的两个peer，A和B，A和B都bind自己listen的端口，向对方发起连接（connect），即使用相同的端口同时连接和等待连接。因为A和B发出连接的顺序有时间差，假设A的syn包到达B的nat时，B的syn包还没有发出，那么B的nat映射还没有建立，会导致A的连接请求失败（连接失败或无法连接，如果nat返回RST或者icmp差错，api上可能表现为被RST；有些nat不返回信息直接丢弃syn包（反而更好）），（应用程序发现失败时，不能关闭socket，closesocket（）可能会导致NAT删除端口映射；隔一段时间（1-2s）后未连接还要继续尝试）；但后发B的syn包在到达A的nat时，由于A的nat已经建立的映射关系，B的syn包会通过A的nat，被nat转给A的listen端口，从而进去三次握手，完成tcp连接。

从应用程序角度看，连接成功的过程可能有两种不同表现：（以上述假设过程为例）

1、连接建立成功表现为A的connect返回成功。即A端以TCP的同时打开流程完成连接。

2、A端通过listen的端口完成和B的握手，而connect尝试持续失败，应用程序通过accept获取到连接，最终放弃connect（这时可closesocket(conn_fd)）。

多数Linux和Windows的协议栈表现为第2种。

但有一个问题是，建立连接的client端，其connect绑定的端口号就是主机listen的端口号，或许这个peer后续还会有更多的这种socket。虽然理论上说，socket是一个五元组，端口号是一个逻辑数字，传输层能够因为五元组的不同而区分开这些socket，但是是否存在实际上的异常，还有待更多观察。

1、Windows XP SP2 *** 作系统之前的主机，这些主机不能正确处理TCP同时开启，或者TCP套接字不支持SO_REUSEADDR的参数。需要让AB有序的发起连接才可能完成。

上述tcp连接过程，仅对NAT1、2、3有效，对NAT4（对称型）无效。

由于对称型nat通常采用规律的外部端口分配方法，对于nat4的打洞，可以采用端口预测的方式进行尝试。

ALG（应用层网关） ：它可以是一个设备或插件，用于支持SIP协议，主要类似与在网关上专门开辟一个通道，用于建立内网与外网的连接，也就是说，这是一种定制的网关。更多只适用于使用他们的应用群体内部之间。

UpnP ：它是让网关设备在进行工作时寻找一个全球共享的可路由IP来作为通道，这样避免端口造成的影响。要求设备支持且开启upnp功能，但大部分时候，这些功能处于安全考虑，是被关闭的。即时开启，实际应用效果还没经过测试。

STUN（Simple Traversalof UDP Through Network）： 这种方式即是类似于我们上面举例中服务器C的处理方式。也是目前普遍采用的方式。但具体实现要比我们描述的复杂许多，光是做网关Nat类型判断就由许多工作，RFC3489中详细描述了。

TURN(Traveral Using Relay NAT)： 该方式是将所有的数据交换都经由服务器来完成，这样NAT将没有障碍，但服务器的负载、丢包、延迟性就是很大的问题。目前很多游戏均采用该方式避开NAT的问题。这种方式不叫p2p。

ICE(Interactive Connectivity Establishment)： 是对上述各种技术的综合，但明显带来了复杂性。

---