上图就是多台电脑上的xdisp_virt展现出来的AirPlay接收端，
iPhone手机中没有安装任何第三方App，但是却能找到一堆的AirPlay接收端信息，
这看起来很神秘，其实搞清楚了来龙去脉，也没啥神秘的，
在AirPlay接收端的实现中，利用mDNS协议来把自己的信息发布出去，
同样到了iPhone手机端，因为是iOS系统自己集成了AirPlay，
它同样使用mDNS协议查询这些信息，从而查询到了这些AirPlay接收端。
具体其实就是大家都注册到一个组播地址中，组播地址固定为224.0.0.251，固定的端口是 5353，一般使用UDP 协议；
而DNS的端口是53，mDNS端口是5353，这不是巧合，实际上，mDNS协议的格式基本与DNS一样，
所以如果理解了DNS协议，对mDNS的理解就不会差太多，只不过mDNS一般用于局域网的信息发布，发现搜索等。
举个简单例子，A设备进入局域网，加入 mDNS 服务，并向mDNS服务注册一些自己的信息：我是谁，我在干嘛。
B设备同样进入了局域网，也加入了mDNS服务，并且向mDNS服务请求查询在线所有满足一定条件的设备，
于是mDNS服务开始在局域网内查询，最终把查询到的结果告诉B设备。

题外话：组播这玩意不一定都十分靠谱，在理想的局域网环境到没啥问题，
在有些复杂的网络环境就比较难说了，有可能会偶尔出现一些问题。
比如我这网络环境，多个交换机组合，
多个vmware虚拟出来的IP地址，以及VPN软件模拟出来的IP地址，
以及三个多网段组合在一起，至少两个无线路由器凑合在一起。。。
如果突然出现iOS设备搜索不到AirPlay接收端也算正常，
多试几次，把AirPlay功能打开关闭多试几次，
或者把AirPlay的侦听地址固定到某个IP地址，反正我是多次尝试了之后才发现这些。

对于airplay接收端来说，需要向mDNS注册两类服务，
一类airtunes，标记为 _raop._tcp 用于协商音频和视频的传输，
一类airplay，标记为 _airplay._tcp 用于处理传统的流服务。
至于这两类服务的的具体协议格式，可以通过抓包软件来分析。

当iOS,macOS等系统发现了AirPlay接收端，并且主动连上
（比如上图中，iOS手机连上了名为 “xdisp_virt [ mini-PC ]” 的AirPlay接收端）
它使用TCP连接到Airplay接收端，并且使用RTSP协议进行交互，
但是这个RTSP协议，经过苹果公司多次的升级修改，虽然表面上还是RTSP协议格式，
但是实际内容却是改变了很多，因此并不符合RTSP协议标准规范。
但他的协议格式还是尽量保持着RTSP的协议格式，这对于破解分析AirPlay的协议带来了十分的便利。
传输音频采用的基于UDP的RTP协议，编码方式是 AAC-ELD或ALAC，
而传输视频的则是基于TCP，并且固定H264编码。

本文并不打算研究这些协议格式，
因为网上文章有阐述，如果还不明白，
可以使用网络抓包软件分析它的协议格式，或者可以进一步去阅读源码，
比如其中UxPlay的开源代码，等等。

前面说了，xdisp_virt程序集成了UxPlay开源代码，但是还缺少mDNS的实现，
因此xdisp_virt同时也集成了 苹果的 mDNSResponder 开源代码。
当然也有其他mDNS开源可选，比如linux下的avahi 。

这俩货都不是省油的灯，因为我要把他们编译进xdisp_virt程序中，需要做成静态lib库（或者a库）
而 mDNSResponder 项目给出的目录结构确实头大，里边有生成多个项目，
而我却只需要里边的dnssd接口和mDNS服务端，
于是干脆直接另起一个项目工程，把需要的源文件直接加进去，重新生成一个新的静态lib工程，
这是在windows的VS下的做法，到了linux平台，则是自己重新制作Makefile文件，
这个Makefile看起来像下面这样：
## by fanxiushu 2024-04-18

vpath %.c ./mDNSCore
vpath %.h ./mDNSCore
vpath %.c ./mDNSShared
vpath %.h ./mDNSShared
vpath %.c ./mDNSPosix
vpath %.h ./mDNSPosix
vpath %.c ./mDNSMacOSX
vpath %.h ./mDNSMacOSX

C=gcc
CC=g++

LIB_AR = ar cr

objs = \
    DebugServices.o dnssd_clientlib.o dnssd_clientstub.o \
    dnssd_ipc.o GenLinkedList.o \
    ClientRequests.o DNSCommon.o DNSDigest.o dnssd_ipc.o LegacyNATTraversal.o \
    mDNS.o mDNSDebug.o uDNS.o uds_daemon.o mDNSPosix.o PosixDaemon.o PlatformCommon.o mDNSUNP.o

CF = -std=c99 -I./mDNSCore -I./mDNSShared -I./mDNSShared/utilities -I./ -D_GNU_SOURCE \
    -DMDNS_DEBUGMSGS=0 -DNOT_HAVE_SA_LEN -DPEDANTIC -DUSES_NETLINK -DHAVE_LINUX -DTARGET_OS_LINUX \
    -DUSE_TCP_LOOPBACK -DNO_PID_FILE

LF =

############################################
###################################

dnssd:$(objs)
    $(LIB_AR) libdnssd.a  $(objs) $(LF)

%.o:%.c
    $(C)   $(CF) -c $< -o $@

clean:
    -rm *.o
    -rm libdnssd.a

当然还需要修改一些代码，同时增加几个导出函数，主要是mDNS服务端的导出函数。
经过一通折腾之后， mDNSResponder才能以静态库的方式编译进xdisp_virt程序中。

再接下来就是集成UxPlay的问题。
UxPlay 最终编译之后其实是一个程序，显然不能直接用。
UxPlay工程目录的render渲染图像部分，gstreamer解码部分都用不上，
只需要使用UxPlay工程里边的lib目录。
同时另外还需要 libplist 工程，
与mDNSResponder的做法类似，只需要他们的c，cpp等源文件，自己制作工程项目或者Makefile编译成静态库。
同时对UxPlay的代码改的也较多，主要是为了适合xdisp_virt以及兼容Windows，不过本质还是使用的UxPlay开源代码。

做好了AirPlay屏幕镜像，但是却无法使用鼠标键盘控制，感觉是很不爽的。
因此得把蓝牙驱动集成进去，通过蓝牙来控制苹果设备。
这是没办法的选择，因为目前来看，
iOS，iPad这些设备的系统（macOS除外）压根就找不到接口API来进行鼠标键盘的远程控制。
这也是前面三篇文章阐述的内容：把电脑模拟成蓝牙鼠标和蓝牙键盘。

xdisp_virt本身就支持鼠标键盘控制的，只需要把Web端传递来的鼠标键盘信息，
传递给蓝牙驱动，从而让他控制苹果设备。
同时xdisp_virt本身就是跨越局域网限制的，
只要保持苹果设备和xdisp_virt在同一个局域网，
然后运行xdisp_virt的电脑具有公网地址，或者xdisp_virt连接到具有公网地址的xdisp_server，
都可以把苹果设备的屏幕传输到任何地方。

其中macOS平台因为目前并不熟悉蓝牙的开发，所以没有实现电脑模拟蓝牙鼠标键盘的功能。

windows平台则是需要单独安装驱动，
而且正如以前文章阐述的，这个驱动需要做破解，这会造成一些未知的麻烦，
尤其有些windows系统版本可能直接蓝屏死机，虽然我目前测试64位的 win10, 11，win7都运行良好。
但无法百分之百的保证一定不出问题，
因此这次发布新版本的xdisp_virt的时候，并不会公布windows下的蓝牙驱动。

linux下的蓝牙鼠标键盘，则是直接集成到了xdisp_virt程序中，
但是需要自己去配置蓝牙服务，具体需要满足以下一些条件：
1，当然需要有蓝牙设备这个实物。
2，需要安装blueZ，linux系统默认都会安装的。
3，需要xdisp_virt以 root 超级用户方式运行。
4，bluetoothd 以带参数方式运行： bluetoothd -C -P input

下面是xdisp_virt的AirPlay的演示视频，有兴趣可以去github下载新版本自己尝试：
更多的关于xdisp_virt使用和演示，请去github查阅。