0

我在服务器和客户端之间建立了一对一的连接。服务器正在流式传输实时音频/视频数据。

我的问题可能听起来很奇怪，但我应该使用多个端口/套接字还是只使用一个？使用多个端口更快还是使用单个端口提供更好的性能？我应该有一个端口只用于消息，一个用于视频，一个用于音频，还是将整个东西打包在一个端口中更简单？

我当前的一个问题是我需要首先发送当前帧的大小，因为大小（以字节为单位）可能会从一帧变为下一帧。我对网络相当陌生，但我还没有找到任何机制可以自动检测正在传输的特定对象的正确范围。例如，如果我发送一个 2934 字节长的数据包，我真的需要告诉接收者该数据包的大小吗？

我首先尝试在帧进入时尽可能快地打包帧，但我发现接收端有时无法获得适当的字节数。大多数时候，它的读取速度比我发送它们的速度要快，只得到部分帧。什么是尽快获得适当数量的字节的最佳方法？

还是我看起来太低了，并且有一个更高级别的类/框架用于处理对象传输？

4

2 回答 2

1

我认为最好使用对象机制并以交错方式发送数据。这种机制可能比多端口机制工作得更快。

例如：

class Data { DataType, - (Adio/Video) Size, - (Size of the Data buffer) Data Buffer - (Data 取决于类型) }

'DataType' 和 'Size' 总是大小不变。在客户端获取“DataType”和“Size”，然后读取相应发送数据（Adio/Video）的指定大小。

于 2013-07-11T06:11:06.983 回答
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]
...

但为什么要重新发明轮子呢？已经有协议可以做这些事情。

于 2013-07-11T06:14:56.877 回答