DLNA的一个场景的工作过程

场景：用户将手机A中的媒体内容播放到电视B上。（DMC+DMR） 
在这个场景中，前提是，A和B必须连接到同一个局域网中。假定电视B先接入局域网，手机A后接入局域网，然后再进行播放操作，那么该场景大概是这样的： 
B接入局域网以后，B需要建立多播socket，然后加入DLNA这个多播组（譬如说是239.255.255.250，数据端口是1900），同时不断监听1900端口发送过来的报文数据。 
如果报文以M-SEARCH开头，那么就说明，局域网内有设备正在进行查找。B现在扮演DMR的角色，那么它就应该处理所有Renderer的M-SEARCH报文，接收到相应报文之后，需要给查询方发送一个回复报文，回复报文中包含了当前DMR的基本信息。 
A现在加入局域网，它也建立多播socket，也加入到多播组中，然后根据A上用户选择进行DMR搜索之后，A发出M-SEARCH报文，局域网多播机制会将该报文发送给DLNA多播组中所有监听者，于是B也收到了该报文。B开始解析报文，它知道对方搜索的正式DMR，于是它立刻给多播组内发一条回复报文，告诉搜索方自己就是DMR。于是A又收到了该回复报文，A解析了该回复，得到了DMR的基本信息，它接着把这些基本信息装载到UI上，于是用户看到了该DMR的信息。 
如果用户已经选择了某个媒体资源，那么就可以直接进行具体的流媒体push操作了。 
关于push操作，其实是这样的。无论对于DMR+DMC的push场景，或者DMS+DMR的pull场景，媒体提供方其实也要提供一个服务就是流媒体服务器（就是NanoHTTPD或者netty等去实现的）。所以在A和B这个场景中，A是DMC，所以它提供了一个媒体服务器。当报文发出并得到回复之后，事实上这一步只是确定了DMR有谁，接着用户选择了某个DMR，这就确定了要与之通信的DMR是谁，然后，A和B其实就已经建立了一种端对端的关系，A会先发起一个HTTP请求，告诉B，我要播放什么格式的内容，它的URL地址是什么，然后B接收到请求之后，解析到要播放的地址文件格式及其地址等信息之后，先会判断它支持不支持这个媒体内容，如果不知吃，那么就需要返回一个400或者什么错误码给A（错误码，DLNA spec里都有详细介绍），如果它支持，那么就开始建立与该流媒体的连接，通过HTTP去拿数据，然后根据媒体类型再在本地进行解码，然后进行播放。 
在刚才的过程中，如果媒体文件是视频或者音频，那就更复杂一些，一是B要进行实时解码播放，二是还需要把播放的进度不断返回给A，因为对于A来讲，它需要把播放进度条展示给用户去看。同时A一般还会提供一些更具体的视频、音频操作，例如暂停、恢复、跳转等。这些都是协议里面规定的，具体如何去通信，还要仔细的阅读spec