日B视频 亚洲,啪啪啪网站一区二区,91色情精品久久,日日噜狠狠色综合久,超碰人妻少妇97在线,999青青视频,亚洲一区二卡,让本一区二区视频,日韩网站推荐

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

深入地研究WebRTC!Websocket服務(wù)器JscodeReact前端編碼器

LiveVideoStack ? 來源:LiveVideoStack ? 2020-09-22 09:58 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

我的動機(jī) 我們的目標(biāo)是制作一個精簡易用的點對點文件共享網(wǎng)絡(luò)應(yīng)用程序,將更多的精力投入到用戶體驗與簡單地辦事上。這個網(wǎng)絡(luò)應(yīng)用程序不只是針對特定的個人群體服務(wù)的,而是針對整個社區(qū)服務(wù)。 既然有這么多文件共享網(wǎng)站,為什么我們還要做這些呢? 當(dāng)然,我也思考過這個問題,但所有的這些網(wǎng)站都沒有真正地說明過這些文件在哪里共享或存儲。這可能是一種隱私威脅,因為在當(dāng)前疫情的情況下,許多人或許經(jīng)常使用這些服務(wù)來共享文件甚至機(jī)密文件。使用安全的點對點連接和它的數(shù)據(jù)通道可以傳輸大量的文件,卻不需要存儲在任何服務(wù)器上,這使得它真正地結(jié)實與私有,因為只有連接的客戶端/對等端直接與中間服務(wù)器通信,不需要中間服務(wù)器進(jìn)行傳輸。 WebRTC使對等連接和數(shù)據(jù)通道成為可能。WebRTC基本上是一種相互通信與傳送數(shù)據(jù)的全球網(wǎng)絡(luò)方式,類似于藍(lán)牙、NFC和WIFI數(shù)據(jù)共享。我們可以使用WebRTC實現(xiàn)跨平臺支持,因為它是基于網(wǎng)絡(luò)的。 讓我們更深入地研究WebRTC。 WebRTC

“WebRTC是一個免費(fèi)的開放項目,通過簡單的APIs為瀏覽器與移動應(yīng)用程序提供實時通信(RTC)功能。WebRTC組件已經(jīng)進(jìn)行了優(yōu)化,以更好地滿足這一目的?!?webrtc.org

好吧,假設(shè),一個“點對點”關(guān)聯(lián)考慮兩部設(shè)備之間發(fā)送的直接信息,而不需要服務(wù)器保存這些信息。聽起來這對我們的情況很理想對吧?不幸的是,這不是WebRTC工作的方式!

圖為使用WebRTC進(jìn)行數(shù)據(jù)傳輸 盡管WebRTC實現(xiàn)了點對點連接,但它確實需要一個稱為信令服務(wù)器的服務(wù)器,該服務(wù)器用于共享有關(guān)預(yù)期將其相互連接的設(shè)備的數(shù)據(jù)。這些微妙之處可以通過任何傳統(tǒng)的信息共享技術(shù)來共享。WebSockets在這里受到青睞,因為它減少了在一個龐大的建立關(guān)聯(lián)的系統(tǒng)中共享這些額外數(shù)據(jù)的惰性。 簡而言之,信令服務(wù)器幫助建立連接,然而,當(dāng)連接建立后,服務(wù)器將不再涉及相關(guān)設(shè)備之間共享的信息。 一年前,當(dāng)我開始我的第一個WebRTC項目時,很難找到一個在“production”級別下工作得像樣的模型。后來我在網(wǎng)上找到了這個Youtube頻道編碼。開發(fā)人員給出了關(guān)于可用于生產(chǎn)的WebRTC應(yīng)用程序的一些很好的例子。 WebRTC如何創(chuàng)建一個連接(技術(shù)) 好吧,沒有簡單的方法來解釋這一點,但我的看法是,在網(wǎng)絡(luò)上所有數(shù)量可觀的設(shè)備中,無論如何都必須有一個設(shè)備通過產(chǎn)生信號來啟動連接,并將其發(fā)送到信令服務(wù)器上。這個對等點被稱為啟動器,在simple-peer(此項目中使用的模塊)中,當(dāng)創(chuàng)建一個啟動器對等點時,{initiator:true}會被傳遞給制作者/構(gòu)造函數(shù)。

如圖:信號服務(wù)器在運(yùn)行 當(dāng)我們得到對等點的信號信息時,這些信息應(yīng)該通過某種方式通過信令服務(wù)器發(fā)送到不同的集線器。不同的集線器獲取此信息并嘗試與發(fā)起程序建立關(guān)聯(lián)。在這個過程中,這些對等體同樣產(chǎn)生它們的信號信息并被發(fā)送給發(fā)起方。發(fā)起方獲取此信息并嘗試與其余對等方建立連接。 瞧!這些設(shè)備現(xiàn)在已經(jīng)連接起來,現(xiàn)在有一個數(shù)據(jù)通道,可以在沒有中間服務(wù)器的情況下共享信息。 盡量不要過分強(qiáng)調(diào)你無法理解WebRTC的上述工作方式以及簡單對等點如何把它抽象化。當(dāng)我一開始擺弄WebRTC時,它嚇了我一大跳。接下來的部分將對這一點進(jìn)行更簡單和細(xì)致的解釋。 與WebRTC共享文件(使用simple-peer)

const express = require("express"); const http = require("http"); const app = express(); const server = http.createServer(app); const socket = require("socket.io"); const io = socket(server); const users = {}; const socketToRoom = {}; io.on('connection', socket => { socket.on("join room", roomID => { if (users[roomID]) { const length = users[roomID].length; if (length === 2) { socket.emit("room full"); return; } users[roomID].push(socket.id); } else { users[roomID] = [socket.id]; } socketToRoom[socket.id] = roomID; const usersInThisRoom = users[roomID].filter(id => id !== socket.id); socket.emit("all users", usersInThisRoom); }); socket.on("sending signal", payload => { io.to(payload.userToSignal).emit('user joined', { signal: payload.signal, callerID: payload.callerID }); }); socket.on("returning signal", payload => { io.to(payload.callerID).emit('receiving returned signal', { signal: payload.signal, id: socket.id }); }); socket.on('disconnect', () => { const roomID = socketToRoom[socket.id]; let room = users[roomID]; if (room) { room = room.filter(id => id !== socket.id); users[roomID] = room; socket.broadcast.emit('user left', socket.id); } }); }); server.listen(process.env.PORT || 8000, () => console.log('server is running on port 8000')); Websocket服務(wù)器JscodeReact前端編碼器

import React, { useEffect, useRef, useState } from "react";import io from "socket.io-client";import Peer from "simple-peer";import styled from "styled-components";import streamSaver from "streamsaver"; const Container = styled.div` padding: 20px; display: flex; height: 100vh; width: 90%; margin: auto; flex-wrap: wrap;`; const worker = new Worker("../worker.js"); const Room = (props) => { const [connectionEstablished, setConnection] = useState(false); const [file, setFile] = useState(); const [gotFile, setGotFile] = useState(false); const chunksRef = useRef([]); const socketRef = useRef(); const peersRef = useRef([]); const peerRef = useRef(); const fileNameRef = useRef(""); const roomID = props.match.params.roomID; useEffect(() => { socketRef.current = io.connect("/"); socketRef.current.emit("join room", roomID); socketRef.current.on("all users", users => { peerRef.current = createPeer(users[0], socketRef.current.id); }); socketRef.current.on("user joined", payload => { peerRef.current = addPeer(payload.signal, payload.callerID); }); socketRef.current.on("receiving returned signal", payload => { peerRef.current.signal(payload.signal); setConnection(true); }); socketRef.current.on("room full", () => { alert("room is full"); }) }, []); function createPeer(userToSignal, callerID) { const peer = new Peer({ initiator: true, trickle: false, }); peer.on("signal", signal => { socketRef.current.emit("sending signal", { userToSignal, callerID, signal }); }); peer.on("data", handleReceivingData); return peer; } function addPeer(incomingSignal, callerID) { const peer = new Peer({ initiator: false, trickle: false, }); peer.on("signal", signal => { socketRef.current.emit("returning signal", { signal, callerID }); }); peer.on("data", handleReceivingData); peer.signal(incomingSignal); setConnection(true); return peer; } function handleReceivingData(data) { if (data.toString().includes("done")) { setGotFile(true); const parsed = JSON.parse(data); fileNameRef.current = parsed.fileName; } else { worker.postMessage(data); } } function download() { setGotFile(false); worker.postMessage("download"); worker.addEventListener("message", event => { const stream = event.data.stream(); const fileStream = streamSaver.createWriteStream(fileNameRef.current); stream.pipeTo(fileStream); }) } function selectFile(e) { setFile(e.target.files[0]); } function sendFile() { const peer = peerRef.current; const stream = file.stream(); const reader = stream.getReader(); reader.read().then(obj => { handlereading(obj.done, obj.value); }); function handlereading(done, value) { if (done) { peer.write(JSON.stringify({ done: true, fileName: file.name })); return; } peer.write(value); reader.read().then(obj => { handlereading(obj.done, obj.value); }) } } let body; if (connectionEstablished) { body = (

); } else { body = (

Once you have a peer connection, you will be able to share files

); } let downloadPrompt; if (gotFile) { downloadPrompt = (
You have received a file. Would you like to download the file?
); } return ( {body} {downloadPrompt} );}; export default Room; 在此Repo上找到整個代碼。如果你在瀏覽器中嘗試應(yīng)用上述代碼并選擇一些圖片文件(最好小于100KB),它會立即下載這些圖片文件。這是因為這個對等點位于一個類似的瀏覽器中,而發(fā)送方處于提示狀態(tài)。 傳送和獲取的信息的大小是相等的。這表明我們可以選擇一次性移動整個記錄! 為什么使用數(shù)據(jù)緩沖區(qū)而不是blob? 在我們過去的代碼中,如果我們選擇了一個巨大的文件(大于100KB),那么文檔很可能不會被發(fā)送,這是WebRTC通道的某些約束的直接結(jié)果。

如圖:數(shù)組緩沖區(qū)漫畫插圖(mozilla.org) 每個數(shù)組緩沖區(qū)一次只能有16KB的限制。簡而言之,這意味著我們必須將文檔劃分成小數(shù)組緩沖區(qū)。 小文件可以通過WebRTC一次性發(fā)處,然而,對于大文檔,明智的做法是將文件隔離到較小的數(shù)組緩沖區(qū)中,并同樣發(fā)送每個部分。ArrayBuffer和Blob對象都有削減容量,這使得此過程更加簡單。為此,如果你仔細(xì)查看代碼,你會發(fā)現(xiàn)我們使用了一個名為stream saver的模塊,它可以將數(shù)組緩沖區(qū)轉(zhuǎn)換回blob。 筆記 因為javascript是單線程的。處理大量數(shù)組緩沖區(qū)可能導(dǎo)致漂亮的UI無法響應(yīng)。為了解決這個問題,我們將使用服務(wù)工作人員。一個服務(wù)工作人員是瀏覽器在后臺運(yùn)行的腳本,是與Web頁面分離的,這為不需要Web頁面或用戶交互的特性打開大門。

let array = [];self.addEventListener("message", event => { if (event.data === "download") { const blob = new Blob(array); self.postMessage(blob); array = []; } else if (event.data === "abort") { array = []; } else { array.push(event.data); }}) 在服務(wù)工作程序中處理數(shù)組緩沖區(qū) 將文件劃分為數(shù)組緩沖區(qū)的優(yōu)點 雖然它可能會感覺分隔文件只是一些額外的代碼,并且會讓東西相互糾纏,但我們得到以下好處,并且可以幫助改進(jìn)我們的文檔共享應(yīng)用程序。

跨平臺支持(由mozilla.org提供說明)

支持幾乎所有的瀏覽器

支持龐大的文檔大小——正如前面提到的,這是我們?yōu)槭裁匆獙崿F(xiàn)它的基本解釋。

一個更好的方法來破譯所發(fā)送信息的度量——通過在緩沖區(qū)中發(fā)送一個記錄,我們現(xiàn)在可以顯示信息,例如,發(fā)送的文檔的級別,發(fā)送記錄的速度等等。

識別未完成發(fā)送的文件——在無法完全發(fā)送文件的情況下,現(xiàn)在能夠以不同的方式獲取和處理文件。

結(jié)論 由于我們有一個使用WebRTC的文檔直接共享程序,而且它還利用了ArrayBuffer,我們現(xiàn)在應(yīng)該開始考慮為應(yīng)用程序的生產(chǎn)做準(zhǔn)備的東西了。這些細(xì)節(jié)需要更多的探索,而不僅僅是遵循一個直接的教程。 可以補(bǔ)充的更多內(nèi)容:

信令服務(wù)器(STUN和TURN服務(wù)器)。

使多個對等連接可拓展。

當(dāng)WebRTC不能工作時才用的一種混合共享方式。

提高傳輸效率和速度。

我希望我已經(jīng)提供了足夠的信息讓你們開始使用WebRTC應(yīng)用程序。

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 編碼器
    +關(guān)注

    關(guān)注

    45

    文章

    4014

    瀏覽量

    143493
  • 服務(wù)器
    +關(guān)注

    關(guān)注

    14

    文章

    10380

    瀏覽量

    91782
  • WebRTC
    +關(guān)注

    關(guān)注

    0

    文章

    57

    瀏覽量

    11972

原文標(biāo)題:使用Webrtc和React Js在網(wǎng)絡(luò)上共享跨平臺的點對點文件

文章出處:【微信號:livevideostack,微信公眾號:LiveVideoStack】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點推薦

    深入解析HCS365 KEELOQ? 跳碼編碼器

    深入解析HCS365 KEELOQ? 跳碼編碼器 在電子安全領(lǐng)域,遠(yuǎn)程無鑰匙進(jìn)入(RKE)系統(tǒng)和安全遙控系統(tǒng)對安全性和可靠性有著極高的要求。HCS365 KEELOQ? 跳碼編碼器憑借其卓越的性能
    的頭像 發(fā)表于 04-07 11:20 ?200次閱讀

    深入解析HCS300:高性能代碼跳變編碼器的技術(shù)探秘

    深入解析HCS300:高性能代碼跳變編碼器的技術(shù)探秘 在電子工程領(lǐng)域,安全可靠的遠(yuǎn)程無鑰匙進(jìn)入(RKE)系統(tǒng)一直是研究的重點。Microchip Technology Inc.推出的HCS300代碼
    的頭像 發(fā)表于 04-07 10:50 ?146次閱讀

    深入解析Microchip HCS201 KEELOQ? 代碼跳變編碼器

    深入解析Microchip HCS201 KEELOQ? 代碼跳變編碼器 在電子安全領(lǐng)域,遠(yuǎn)程無鑰匙進(jìn)入(RKE)系統(tǒng)的安全性至關(guān)重要。Microchip的HCS201 KEELOQ? 代碼跳變
    的頭像 發(fā)表于 04-07 10:50 ?117次閱讀

    深入解析Microchip HCS101固定碼編碼器:特性、應(yīng)用與設(shè)計要點

    深入解析Microchip HCS101固定碼編碼器:特性、應(yīng)用與設(shè)計要點 在電子工程師的日常工作中,編碼器是實現(xiàn)遠(yuǎn)程控制等功能的關(guān)鍵組件。Microchip的HCS101固定碼編碼器
    的頭像 發(fā)表于 04-07 10:50 ?122次閱讀

    深入解析Microchip HCS200 KEELOQ? 代碼跳變編碼器

    深入解析Microchip HCS200 KEELOQ? 代碼跳變編碼器 在電子工程領(lǐng)域,安全可靠的編碼技術(shù)對于各種應(yīng)用至關(guān)重要。今天,我們將深入探討Microchip的HCS200
    的頭像 發(fā)表于 04-07 10:40 ?143次閱讀

    磁鐵在編碼器中的作用與應(yīng)用

    編碼器中,磁鐵的作用不可小覷,常用的磁性材料主要是釹鐵硼和鐵氧體,今天這篇文章主要介紹下磁鐵用于哪些編碼器類型,以及其具體作用。磁鐵在編碼器中的作用(功能)是什么?在編碼器中,磁鐵主
    的頭像 發(fā)表于 03-19 14:42 ?479次閱讀
    磁鐵在<b class='flag-5'>編碼器</b>中的作用與應(yīng)用

    Vishay USB編碼器接口技術(shù)解析與應(yīng)用指南

    Vishay/MCB Industrie RAMK/RAME USB編碼器接口是一款設(shè)計用于Vishay MCB編碼器(AMK和RAME系列,包括霍爾效應(yīng))的電子板。該接口板只需使用隨附的USB
    的頭像 發(fā)表于 11-12 11:51 ?1218次閱讀

    雷恩PRECILEC重載式編碼器:重載工況,精準(zhǔn)穩(wěn)定#編碼器

    編碼器
    開地電子
    發(fā)布于 :2025年10月31日 16:18:04

    雷恩 PRECILEC 重載編碼器:重載工況,精準(zhǔn)穩(wěn)定# 編碼器

    編碼器
    開地電子
    發(fā)布于 :2025年10月31日 15:06:40

    一文吃透WebSocket:智能物聯(lián)網(wǎng)通信的入門與實戰(zhàn)全攻略!

    解決方案,助你輕松掌握這一核心技術(shù)。 一、WebSocket基礎(chǔ)知識 1.1 ?什么是Websocket? WebSocket是HTML5下一種新的協(xié)議(本質(zhì)上是一個基于TCP的協(xié)議),主要解決傳統(tǒng)HTTP協(xié)議在 “實時通信”
    的頭像 發(fā)表于 10-15 18:16 ?647次閱讀
    一文吃透<b class='flag-5'>WebSocket</b>:智能物聯(lián)網(wǎng)通信的入門與實戰(zhàn)全攻略!

    Bourns發(fā)布全新增量式微型編碼器

    Bourns 推出 PEC04 系列 4 mm 增量式微型編碼器、PEC05 PEC05 系列 5 mm 增量式微型編碼器,以及 PEC06 型號 6 mm 增量式微型編碼器。Bourns 全新微型
    的頭像 發(fā)表于 09-22 16:05 ?1497次閱讀

    深入ZMC900E:主站控制編碼器的使用與優(yōu)勢

    視頻推薦在工業(yè)自動化領(lǐng)域,編碼器是確保設(shè)備精準(zhǔn)運(yùn)行的關(guān)鍵部件。本期我們將深入探討ZMC900E主站控制中的編碼器功能。編碼器
    的頭像 發(fā)表于 09-11 11:34 ?943次閱讀
    <b class='flag-5'>深入</b>ZMC900E:主站控制<b class='flag-5'>器</b><b class='flag-5'>編碼器</b>的使用與優(yōu)勢

    絕對值編碼器與增量式編碼器相比有哪些優(yōu)勢?

    絕對值編碼器與增量式編碼器相比有哪些優(yōu)勢?核心功能:斷電后位置信息不丟失,絕對值編碼器:通過機(jī)械結(jié)構(gòu)或電子存儲(如電池備份),能實時輸出當(dāng)前位置的唯一絕對值編碼(如二進(jìn)制、格雷碼)。無
    的頭像 發(fā)表于 08-11 13:57 ?2157次閱讀
    絕對值<b class='flag-5'>編碼器</b>與增量式<b class='flag-5'>編碼器</b>相比有哪些優(yōu)勢?

    增量型編碼器與絕對值型編碼器怎么選擇?

    在選擇增量型編碼器與絕對值型編碼器時,需要考慮多個因素,包括應(yīng)用需求、成本、精度、可靠性以及環(huán)境適應(yīng)性等。以下是對兩種編碼器的詳細(xì)比較及選擇建議: 一、增量型編碼器 1. 優(yōu)點: ?
    的頭像 發(fā)表于 07-10 10:34 ?1891次閱讀
    张家川| 广丰县| 明水县| 郎溪县| 海丰县| 彭州市| 灵丘县| 怀来县| 万载县| 大竹县| 乌兰县| 托克托县| 五莲县| 建水县| 金堂县| 林州市| 札达县| 获嘉县| 宁化县| 肃南| 渭南市| 北流市| 繁昌县| 恭城| 邵武市| 墨竹工卡县| 黔江区| 藁城市| 金溪县| 太白县| 墨脱县| 化隆| 奇台县| 文水县| 安达市| 兰坪| 永昌县| 仪征市| 合水县| 弋阳县| 白河县|