WebRTC候选人信息末尾的这些数据是什么? [英] What is this data at the end of WebRTC candidate info?

问题描述

我使用了Chrome中的WebRTC API和我按照W3C规范以及此处的其他问题编写的WebSocket脚本，建立了基本的视频聊天应用.

I set up a basic video chat app using the WebRTC APIs in Chrome along with a WebSocket script I wrote myself following the W3C specs and other questions here on SO.

但是，有时，当一台PC通过WebSocket连接将ICE候选信息发送到另一台PC时，一堆乱码文本会附加到JSON字符串化的候选信息的末尾.该问题仅在某些时候发生，而通过createOffer和createAnswer方法发送的SDP信息则永远不会发生.

Sometimes though, when one PC sends ICE candidate info to the other PC via the WebSocket connection, a bunch of garbled text is attached to the end of the JSON-stringified candidate info. This problem only happens sometimes though, and it never happens with the SDP info sent via the createOffer and createAnswer methods.

请参见以下链接，以获取我所谈论的内容的示例: http://s1290.beta.photobucket.com/user/HartleySan83/media/NGdata_zps0a7203e7.png.html?sort = 3& o = 0

Please see the following link for an example of what I'm talking about: http://s1290.beta.photobucket.com/user/HartleySan83/media/NGdata_zps0a7203e7.png.html?sort=3&o=0

由于JSON字符串化的候选信息始终以'}}'结尾，因此通过在WebSocket服务器脚本中添加if条件，我得以解决此问题并使视频聊天应用程序正常工作.不幸的是，我想避免这种黑客行为.另外，我想知道为什么会首先发生这种情况.

Because the JSON-stringified candidate info always ends with '}}', by adding an if condition to the WebSocket server script, I was able to circumvent this problem and get the video chat app to work. Unfortunately, this is a hack that I'd like to avoid. Plus, I'd like to know why this is happening in the first place.

值得注意的是，当我在将候选信息发送到WebSocket服务器脚本之前向客户端的控制台发出警报或向其回显时，没有多余的乱码文本，因此我不确定为什么会出现在服务器端(有时只有)提供候选信息.

It's worth noting that when I either alert or echo the candidate info to the console on the client side before it's sent to the WebSocket server script, none of the extra garbled text is present, so I'm not sure why it's present with the candidate info on the server side and only sometimes.

以下是客户端代码的代码段，其中候选信息已发送到服务器端脚本:

The following is a code snippet of the client-side code where the candidate info is sent to the server-side script:

function startPeerConnection() {

  navigator.webkitGetUserMedia({ audio: true, video: true }, function (stream) {

    document.getElementById('vid1').src = webkitURL.createObjectURL(stream);

    pc = new webkitRTCPeerConnection(null);

    pc.onicecandidate = function (evt) {

      if (evt.candidate) {

        socket.send(JSON.stringify({ candidate: evt.candidate }));

      }

    };

    pc.onaddstream = function (evt) {

      document.getElementById('vid2').src = webkitURL.createObjectURL(evt.stream);

    };

    pc.addStream(stream);

  }, function () {});

}

以下是服务器端代码，这些代码可对接收到的WebSocket数据进行屏蔽:

And the following is the server-side code that unmasks the received WebSocket data:

$len = ord($buffer[1]) & 127;

if ($len === 126) {

  $masks_start = 4;

} else if ($len === 127) {

  $masks_start = 10;

} else {

  $masks_start = 2;

}

$masks = substr($buffer, $masks_start, 4);

$data = substr($buffer, $masks_start + 4);

$len = strlen($data);

$text = '';

for ($i = 0; $i < $len; $i++) {

  $text .= $data[$i] ^ $masks[$i % 4];

}

if (($end = strpos($text, '}}')) !== false) {
// This if condition eliminates the garbled text.
// Without it, a "Could not decode a text frame as UTF-8"
// error is output to the Chrome console.

  $text = substr($text, 0, $end + 2);

  $len = strlen($text);

}

if ($len <= 125) {

  $header = pack('C*', 129, $len);

} else if (($len > 125) && ($len < 65536)) {

  $header = pack('C*', 129, 126, ($len >> 8) & 255, $len & 255);

} else if ($len >= 65536) {

  $header = pack('C*', 129, 127, ($len >> 56) & 255, ($len >> 48) & 255, ($len >> 40) & 255, ($len >> 32) & 255, ($len >> 24) & 255, ($len >> 16) & 255, ($len >> 8) & 255, $len & 255);

}

$server_response = $header . $text;

foreach ($users as $user) {

  if ($user !== $users[$user_idx]) {

    @socket_write($user['socket'], $server_response, strlen($server_response));

  }

}

我在互联网上搜索高低不一的其他人，但都遇到了同样的问题，但是我在规范中找不到任何人或任何有关此问题的东西，所以我想我的代码有问题.

I've searched high and low on the Internet for anyone else with the same problem, but I can't find anyone or anything in the specs that talks about this, so I imagine it's some problem with my code.

任何人都可以提供有关问题根源的任何指导，将不胜感激.谢谢.

Any guidance that anyone can offer as to the source of the problem would be much appreciated. Thank you.

推荐答案

好吧，我终于找到了问题所在.我的服务器端WebSocket代码确实是错误的.问题是我计算的长度不正确.不幸的是，我依靠的是我在PHP中找到的有关WebSockets的页面，事实证明，该页面的代码中存在许多错误，我逐渐开始意识到这一点.无论如何，这是计算从客户端发送到服务器的消息长度的正确方法:

Well, I finally found the problem. My server-side WebSocket code was indeed wrong. The problem was that I was miscalculating the length. I, unfortunately, was relying on some page I found about WebSockets in PHP, and as it turns out, the page had a number of errors in its code, which I slowly started to realize more and more. Anyway, here's the proper way to calculate the length of messages sent from a client to the server:

$len = ord($buffer[1]) & 127; // This is the default payload length.

if ($len === 126) { // If 126, then need to use the payload length at the 3rd and 4th bytes.

  $masks_start = 4;

  $len = (ord($buffer[2]) << 8) + ord($buffer[3]);

} else if ($len === 127) { // If 127, then need to use the next 8 bytes to calculate the length.

  $masks_start = 10;

  $len = (ord($buffer[2]) << 56) + (ord($buffer[3]) << 48) + (ord($buffer[4]) << 40) + (ord($buffer[5]) << 32) + (ord($buffer[6]) << 24) + (ord($buffer[7]) << 16) + (ord($buffer[8]) << 8) + ord($buffer[9]);

} else { // Otherwise, the default payload length is correct.

  $masks_start = 2;

}

这样做之后，一切都很好.好吧，我仍然没有弄清楚如何正确关闭WebSocket连接，但是除此之外，WebRTC视频效果很好.

After doing that, everything worked great. Well, I'm still haven't figured out how to properly close a WebSocket connection, but other than that, the WebRTC video is working great.

这篇关于WebRTC候选人信息末尾的这些数据是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！