一个负责中转数据和视频流的服务器架构应该是怎样的？

[loving_you2000]

可以用QQ来理解，一边通过远程控制操纵对方的电脑，一边通过摄像头进行视频聊天。

位于两端的两台终端分别连接到中转服务器，进行配对。A端通过一条连接（也许是 TCP）向服务器发送自己的显示器实况，通过另外一条连接（也许是流媒体UDP）向服务器发送摄像头视频，服务器将数据转发给B端，B端发送实时的操作数据到服务器，服务器转发到A端，A端执行操作。

由于所有的活动都会在服务器监控和保存（视频录像和数据的存储），因此只能采取中转的方法，而不考虑P2P。另外，中间发送的数据会进行加密（也许用SSL）。

平台是Windows，配置就是一般的服务器。至于用户量这些，没有太高要求，百十个配对的样子。

请各位前辈给些意见，
这样的架构应该怎么设计，采用何种协议，何种IO模型，有哪些需要注意的，或者说有哪些坑，等等。

因为题主过去没有碰过网络编程，所有的东西都是未知的。希望大家不吝赐教！

[baddy1211]

QQ以前是点对点的模式 点对点不会对服务器造成压力，特别是视频聊天的流媒体数据 好像后来QQ应该有好多种模式，比如跟竞技平台的那种把玩家拉到一个局域网的模式，还有就是代理中转模式 这个没研究过QQ 如果你这个项目不是庞大 是可以用你现在的服务器做中转模式 服务端使用IOCP模型（人数不多，也非必须，用IOCP比较高大上而已） 通信部分：视频+桌面控制用 UDP；命令发送用TCP 前提：客户端A跟客户端B或者客户端C都已经连接上了中转服务器，并保持KEEP_LIVE，方便服务器能知道对方是否在线 每个客户端在开了一个TCP端口用来消息接收发送外，再开几个UDP端口用来接收流媒体数据 比如客户端A发送TCP消息到中转服务器，中转服务器接收到命令，比如跟客户端B视频 中转服务器先读取下本地的一张维护列表，看看他们2个是否是第一次匹配 如果第一次的话，中转服务器从SOCKET列表里找到客户端B的SOCKETID，发送TCP消息告诉客户端B 有人要跟你视频 你是否同意 如果客户端B接收到消息，客户端B发送同意或者不同意的消息给服务端 中转服务端接收到后，如果是客户端B同意，那么更新下本地维护列表，这样方便下次客户端A发送命令，省的再去问客户端B你是否同意 然后中转服务器再发送消息给客户端B，可以传输数据了，客户端B就把自己视频打开，把数据压缩后给服务端 服务端接收到数据后，再转发给客户端A的某个UDP端口 客户端A在本地一个Dialog显示对方的视频 差不多就是这种思路吧 当然涉及到的技术问题就比较难的 比如视频聊天简单（找个视频的开原类就可以实现了），而桌面控制则有点难度

[loving_you2000]

感谢你的回复！ 两边的客户端倒是没什么问题。我主要是不熟悉服务器开发，以前没做过网络的。 我之前考虑的是服务器为每一对用户都开一个进程，因为多对用户之间也不涉及数据交换同步的问题。但是看了些资料好像说Windows系统下这种多进程的套路一般不怎么用。 您怎么看？ 另外，由于实时桌面和视频都是源源不断的数据进出服务器，在性能方面最需要注意的是什么？哪里有坑？ 您可以给些意见么？不需要细节

引用 1 楼 baddy1211 的回复:

QQ以前是点对点的模式 点对点不会对服务器造成压力，特别是视频聊天的流媒体数据 好像后来QQ应该有好多种模式，比如跟竞技平台的那种把玩家拉到一个局域网的模式，还有就是代理中转模式 这个没研究过QQ 如果你这个项目不是庞大 是可以用你现在的服务器做中转模式 服务端使用IOCP模型（人数不多，也非必须，用IOCP比较高大上而已） 通信部分：视频+桌面控制用 UDP；命令发送用TCP ......