我在服务器和客户端之间建立了一对一的连接。服务器正在传输实时音频/视频数据。
我的问题可能听起来很奇怪，但是我应该使用多个端口/套接字还是只使用一个？使用多个端口或单个端口提供更好的性能是否更快？我应该只为消息设置一个端口，一个用于视频，一个用于音频，还是将整个事件打包到一个端口更简单？
我当前的一个问题是我需要先发送当前帧的大小，因为大小（以字节为单位）可能会从一帧变为另一帧。我是网络新手，但我没有找到任何能够自动检测正在传输的特定对象的正确范围的机制。例如，如果我发送一个2934字节长的数据包，我真的需要告诉接收者该数据包的大小吗？
我首先尝试以它们进入的速度打包帧，但我发现接收端有时候不会得到适当的字节数。大多数时候，它的读取速度比我发送的速度快，只能获得部分帧。什么是尽可能快地获得适当的字节数的最佳方法？
或者我看起来太低了，还有一个用于处理对象传输的更高级别的类/框架？
答案 0 :(得分：1)
我认为最好使用对象机制并以交错方式发送数据。这种机制可能比多端口机制更快。
例如：
class Data { 数据类型， - （Adio /视频） 大小， - （数据缓冲区的大小） 数据缓冲区 - （数据取决于类型） }
'DataType'和'Size'始终是恒定大小。在客户端获取'DataType'和'Size'，然后读取相应发送数据的指定大小（Adio / Video）。
答案 1 :(得分：0)
只是在我的头顶上做些什么。沿着电线推“这样的包”：
1 byte - packet type (audio or video)
2 bytes - data length
(whatever else you need)
|
| (raw data)
|
因此，无论何时在另一端获得其中一个数据包，您都要确切地知道要读取多少数据，以及下一个数据包的开始应该从哪里开始。
[430 byte audio L packet]
[430 byte audio R packet]
[1000 byte video packet]
[20 byte control packet]
[2000 byte video packet]
...
但为什么要重新发明轮子呢？有protocols来做这些事情。