多线程优化方案，主线程监听在一个端口，并使用前面提到方案在服务器将用户的数据包进行识别和区分。
首先我们服务器端主线程会创建一个UDP的socket，绑定到7000端口，并注册监听可读事件，WebRTC客户端会给服务端7000端口发数据包。当然在之前SDP和ICE Candidate的协商流程已经做完了，我们从stun的第一个数据包（stun binding request）中就可以拿到这个WebRTC的web address(IP+端口)以及区分会议的RoomID和区分与会者的UserID。
拿到RoomID以后，我们可以把客户端的web address和RoomID绑定，建立一个映射关系。为什么要做这个绑定关系？
这是为了后续我们可以把同一个会议的用户全部投递到一个业务逻辑处理线程来处理。如果用户的数据是在不同逻辑处理线程上处理，我们在做数据处理的时候就要做跨线程的处理，跨线程处理就一定要加锁，这是我们不太愿意看到的。
如果同一会议的用户数据都在一个逻辑线程里面处理，其实它是在一个单线程里面的顺序处理，没有并发的问题，也不需要加锁，所以它的性能会比较高。
有了刚刚我们建立的映射关系，后续处理同一个会议的用户上行的stun包、dtls、SRTP、SRTCP，我们都根据RoomID做同样的Hash算法，Hash到我们后面的业务主线程里面，这样每一次主线程把I/O做完后，一次性将主线程收到的各个数据包按照Hash算法投递给对应的后端的逻辑处理多线程，这样同一个会议的SFU逻辑都在同一个线程里面处理完了。
这个是我们一开始使用的方案，但是大家也能看到，这个方案还有一个缺陷，就是I/O都是在主线程做的，后续的数据都需要通过跨线程的投递方式让后续的逻辑处理现场来做，那么有没有办法不要做跨线程的投递，让用户的数据包可以直接在对应的逻辑处理多线程里面处理。
其实传统的TCP服务器是比较容易做到的，它可以在主线程上Accept后为每个客户端创建一些新的fd，并分配一个子线程处理这个新fd的读写。那UDP能不能这么做？UDP在常规的编程方法是无法做到的，针对这个问题，我们设计了一个进阶方案。