DSS流媒体IPv6方案：修改socket函数升级IPv4地址到IPv6

Mac OS X IPv6 support and development environment Mac OS X IPv6支持和开发环境

The original intent of the developer grant project had been to use Mac’s for all work. Unfortunately that was overly ambitious, as the OS X 10.1.x system did not have sufficient support for IPv6 work. The IPv6 stack within the operating system was based on a very old Kame[11] port, and there were no IPv6 developer tools. Time was spent updating the kernel to support IPv6, before realising that the developer tools did not have the libraries required for IPv6 program development. There were workarounds available by installing part of the Kame developer libraries and source, but eventually it was decided to do the development and testing work on Linux instead due to its up to date IPv6 stack and developer tools.

开发人员资助项目的初衷要使用Mac的开发基础。不幸的是，这过于有野心了，OS X 10.1.x系统对IPv6的工作没有足够的支持。在操作系统中的IPv6协议栈是基于一个非常古老的游戏[11]端口上，没有IPv6开发工具。意识到开发工具之前没有所需的IPv6库，时间就花在了更新内核支持IPv6上了。Kame开发包中的一部分和IPV6相关，但最终决定在Linux上做开发和测试工作而不是用其最新的IPv6堆栈和开发工具。

Mac OS X 10.2 Jaguar brought good IPv6 support and developer tools. Unfortunately it came out too late for my use, although I did investigate the beta version.

Mac OS X 10.2 Jaguar带来了对IPv6良好的支持和开发工具。不幸的是,它出现的太晚了，虽然我调查研究了测试版。

For the IPv6 Streaming Proxy a class library for IPv6 networking called SocketCC[12] was used and this now has Mac OS X 10.2 Jaguar support. This means the proxy is usable on Mac OS X as well as Linux and Solaris systems.

IPv6的流媒体代理类库为IPv6网络称为SocketCC[12]使用，现在有Mac OS X 10.2 Jaguar的支持。这意味着在Mac上代理使用OS X和Linux和Solaris系统。

Client Development: QuickTime API - NO IPv6 support, No access to RTSP messages. 客户开发:QuickTime API——没有IPv6支持,没有访问RTSP消息权。

The QuickTime API (QuickTime 6 SDK) allows applications to be built that support QuickTime. There is a whole section of the API to support streaming media, and it was believed that a client application could be built that would support IPv6. Unfortunately, the RTSP protocol is not exposed by the API, so modification to support IPv6 addresses in the messages was unable to be done. Instead a client was created that generated its own IPv6 RTSP messages and bypassed the QuickTime API for RTSP. See below.

QuickTime API(QuickTime 6 SDK)允许将应用程序支持QuickTime。有一个整体的API支持流媒体,它是相信客户端应用程序可以建立支持IPv6。不幸的是,RTSP协议是不公开的API,所以修改支持IPv6地址信息无法完成。而不是创建一个客户端,生成自己的IPv6 RTSP消息和绕过RTSP的QuickTime API。见下文。

IPv4 - IPv6 transition programming issues IPv4-IPv6过渡编程问题

The DSS and DSS-proxy code had been written in a typical IPv4 specific way — using Integer or 32bit numbers to represent the IP address. Manipulation of addresses by associating or copying binary values over integer values and relying on bits being in the correct order were used. This is considered to be poor programming technique now that IPv6 is becoming common. The most obvious reason for this is that IPv6 addresses require 128 bits.

DSS和DSS-proxy代码写在一个典型的特定方式——使用IPv4整数或32位数字代表的IP地址。通过关联或以上整数复制二进制值，并依靠正确的顺序使用来操作地址。这被认为是编程差技术，现在的IPv6变得普遍。最明显的原因是IPv6地址需要128位。

It was decided to use a derivative of the IPAddress class from the SocketCC library to replace the integer IP addresses used throughout DSS source code. This turned out to be a much larger task than expected, with large chunks of code that I had not investigated when submitting the developer grant needing changes. Some parts of the code are so heavily dependent on integer representation of the IP address that they require a complete rewrite (eg: socket pool hashing function used the binary representation of the IP address integer as its hash value). Due to the complexity of some of this code, the porting to IPv6 of the DSS server was delayed, and extra effort was put into updating the proxy code.

这是决定使用的IP地址类的衍生物，从Socket C库替换整个DSS源代码中使用的整数IP地址。事实证明，这是比预期更大的任务，提交开发补助需要更改时，我没有调查大量代码。代码的某些部分是如此严重依赖IP地址的整数表示,他们需要一个完整的重写(例如:套接字池哈希函数使用的二进制表示整数作为其IP地址散列值)。由于这些代码的复杂性,移植到IPv6的DSS服务器被推迟,额外的努力投入更新代理代码。

The RTSP[6]specification supports IPv6 URL’s and IP numbers, but does not explicitly describe how to represent them. The programming was done based on the descriptions in the RFC for SDP[7], IPv6 support for SDP[13] and the ongoing work towards SDPng. In addition, text representation of IPv6 addresses followed the appropriate IPv6 URL addressing RFC[14]. Eg: 2001:0db8::12:12bc is a Global scope IPv6 address.

RTSP[6]规范支持IPv6地址和IP数字,但不明确描述如何表示他们。编程是基于描述完成的RFC的SDP[7],IPv6支持SDP[13]对SDPng和正在进行的工作。在此外,文本表示IPv6地址遵循适当的IPv6 URL寻址RFC[14]。如:2001:0db8::12:12bc全球IPv6地址范围。

One major issue showed up, in that it is difficult to program for, and ensure, that global IPv6 addresses are used for both text representation and UDP/IPv6 packet addressing (in the actual IP on Ethernet frame). As RTSP is text based, it is essential that a consistent global IPv6 address is used for both the source IP in the RTSP Setup response messages and also in the actual RTP/UDP/IPv6 streams.

出现的一个主要问题,很难计划,并确保全球IPv6地址是用于文本表示和UDP / IPv6数据包处理(在实际的IP以太网帧)。因为RTSP是基于文本的,至关重要的是一个一致的全球IPv6的源IP地址是用于RTSP响应消息和设置实际RTP / UDP / IPv6流。

The SocketCC library was updated during this project to ensure that the correct addresses (either as ASCII strings or within TCP or UDP packets) are used. SocketCC库在这个项目中进行了更新，以确保正确的地址（无论是作为ASCII字符串或在TCP或UDP数据包）使用。

QuickTime/Darwin Streaming Server (DSS) Porting to IPv6 QuickTime /达尔文流媒体服务器(DSS)移植到IPv6

The AUDF grant request had as its main aim to port the DSS code to natively support IPv6. The grant was put in based on a quick look at the source code, identifying six main socket related files that would need modifying. The DSS source repository is large (approximately 70,000 lines of code). As it turned out, although the DSS source is portable (can be compiled on many systems), modifying the socket related files was not sufficient. The expected propagation of small changes into other files turned into large changes in lots of files. This was mainly due to the use of 32bit integers to represent IP addresses.

AUDF授权请求是移植的的主要工作，将DSS的代码移植到本地支持IPv6要关注它。授权是基于快速浏览源代码,确定6个主要的套接字相关文件需要修改。DSS源库很大(约70000行代码)。事实证明,尽管DSS来源是可移植(可以在许多系统中被编译),修改相关的套接字文件是不够的。预期的微小变化传播到其他文件，很多文件发生了大的变化。这主要是由于使用32位整数来表示IP地址。

Changing from an integer to an IPAddress class object led to the discovery of many initialisation and parameter passing issues that are still to be fully resolved. Similarly the differences between IPv4 and IPv6 multicast programming have to be implemented. Due to the timing of this project (pre-Jaguar) the bulk of the work was carried out on Linux systems. There has been interest in the project from all around the world — mainly in University and IPv6 research consortiums. One consortium (6Net.org) has an IPv6 native DSS ‘hack’ (to use their terminology) based on a different set of network libraries.

改变从一个整数IP地址类对象发现了很多初始化和参数传递问题已经完全解决。类似IPv4和IPv6组播节目之间的差异必须实施。由于这个项目的时间(pre-Jaguar)的大部分工作是在Linux系统上进行。有兴趣的项目来自世界各地,主要是在大学和IPv6研究财团。一个财团(6net.org)有IPv6本机DSS“黑客”(使用他们的术语)，是基于一组不同的网络库来实现。

Darwin Streaming Proxy - port to IPv6 达尔文流媒体代理——IPv6端口

Requirements of a Streaming Proxy 流媒体代理的要求

To act as an Application Layer Gateway to provide RTSP and RTP Streaming media to an IPv6 client, a Streaming Proxy needs to translate the RTSP protocol and copy RTP packets from UDP on IPv4 to UDP on IPv6.

作为一个应用程序层网关提供RTSP和RTP流媒体到IPv6客户端,流媒体代理需要翻译RTSP协议并且从IPv4 UDP复制RTP数据包到IPv6 UDP。

The RTSP protocol consists of a set of relatively straightforward text (readable) messages. Of primary interest to a proxy are the DESCRIBE and SETUP messages and their OK responses from the server.

RTSP协议由一组相对简单的文本(可读)消息组成。代理主要兴趣是描述和设置消息，从服务器的响应OK。

The DESCRIBE message response contains the IP address of the owner of the media stream, and the track information, including who to send control messages to. For streaming video on demand from a QuickTime/Darwin Streaming Server the owner IP address is the IP address of the server contained in the request URL. This remains unchanged in the proxy.

描述消息响应包含流媒体所有者的IP地址，和轨道信息,包括发送控制信息。对视频需求从QuickTime /达尔文流媒体服务器IP地址的IP地址服务器包含在请求URL。这在代理保持不变。

The SETUP messages contain the source IP address of the RTP stream for each track — the proxy needs to replace this IPv4 address string with its own IPv6 global address.

设置消息包含RTP流的源IP地址的每个轨道- 代理需要把这个IPv4地址字符串替换为自己的全球IPv6地址。

For example:

 RTSP SETUP OK message

 Transport:client_port=6970;server_port=10000;source_ip=10.1.252.63

 Changes to

 Transport:

 client_port=6970;server_port=10000;source_ip=2001:0db8::12:fe80:ab12

The streaming video and audio RTP on UDP streams need to be received by the proxy and then forwarded to the IPv6 client in IPv6 UDP packets. There is no need to alter the RTP payload, so effectively the proxy receives UDP packets, reads the payload into a buffer and forwards it out to an IPv6 UDP socket.

流媒体视频和音频RTP在UDP流需要通过代理在IPv6中UDP数据包接收，然后转发到IPv6客户端。没有必要改变RTP有效载荷,所以代理接收UDP数据包,读取有效载荷送入一个缓冲区将它转发到IPv6 UDP套接字。