 |
1
op 这个和 pairdrop.net localsend.org 有什么区别吗？
|
 |
liuzimin14h 3m ago
3
我这边一直卡在“正在建立直连...”
|
 |
4
@liuzimin 看到你的消息我刚立刻又测试了一遍，一个房间是 Windows 机器，另一个房间是 MacOS 机器，几乎 1 秒内就建立连接了，传文件也正常。你这边是在一台机器上可以看到另一台机器的名字吗？还是说只是点击连接时一直连不上？一定要在同一个局域网内才行哦。
|
 |
5
支持 op ，我也开发了一个 zipover.app 跨设备剪贴板，复制粘贴就像使用同一台设备一样。
|
 |
6
确实很棒的方法，能解决不少小问题
|
 |
7
不错不错
|
|
8
@harrisonwang 感谢分享，跨设备剪贴板我还没接触过，我来学习下。
|
|
9
@harrisonwang 我下载了体验了一下，功能也是局域网传文件，只不过是桌面端应用。我看到也是用房间码的方式，我的应用第一版也是房间码，但我家电脑不在一个房间，每次记忆 6 位码感觉也费劲。你的应用也可以考虑做成局域网内自动发现设备，这样感觉体验会提升很多。加油💪🏻
|
|
10
@me876 #4 是可以看到的，双方都能看到对方，点击连接连不了。不过一台是手机，一台是电脑，手机通过 AC+AP 的 wifi 接入，电脑是直连交换机。
|
|
11
@liuzimin 感谢反馈，这种情况确实能看到对方但连不上，解决的话需要加 TURN 中继，但这样文件就会经过服务器，不符合文件只在用户本地传输的原则，所以暂时不打算这样做。我会优化体验，连接超时或失败时告知失败原因。
|
 |
12
你再优化优化吧，237mb 可以做到 10 秒内的，而且绝对不是极限。给你点建设性思路，如果你用了 tcp/ip 协议栈的话，扔掉用 udp 然后改用涌泉码(Fountain Codes)类似的思路。
|
 |
13
公司的无线 ap 之间有隔离，同个局域网下，经常也连接失败，成功了的话，传到一半也开始停住传不了了
|
 |
14
我选择 local send
|
|
15
@qiuhang 感谢建议！其实 WebRTC 本身就跑在 UDP 上，并不是 TCP 。我也实测了一下，在网页里，浏览器自身的 WebRTC 通道上限大约是 17~19 MB/s ，是浏览器协议实现的限制。至于你说的 237mb 在 10 秒内完成，我认为只能做原生客户端才可能达到这种效果。
另外喷泉码解决的是高丢包、高延迟链路上重传太贵的问题，比如卫星、广播、跨洋传输。局域网丢包少、延迟只有几毫秒，重传几乎没有成本。瓶颈不在丢包恢复，加了喷泉码反而要多传冗余数据，还要在 JS 里做大量编解码运算。 |
 |
16
这个站的收音机我很喜欢
|
|
17
@me876 #15 你在 js 和 web 做的话我就不确定了，我做原生 app 用到过类似的场景，确实做到了我说的级别，而且只是初步走通还没针对性极限优化。然后也不是让你用涌泉码，你只借鉴涌泉码的思路，不止用来解决丢包问题，而是为了消解常规网络数据传输方案的复杂确认机制，把传输过程中无关的交互扔掉，让双方一个专心赛数据，一个专心收，收够就停止。
|
 |
dashupc8h 41m ago
18
手机和电脑没有成功
|
|
harrisonwang7h 41m ago
20
@me876 多谢建议！打开就该能被发现采纳了，基于安全配对码还是保留，但是只用输一次，之后自动重连。
|
|
21
@harrisonwang 我发现 web 端因为浏览器自身限制，传输速度有上限，传 1G 以内小文件感觉还可以，但是传大文件肯定会考虑传输速度，这正是桌面端原生应用的优势，楼上有朋友说原生应用的传输速度可以做到 23+MB/s ，你可以把你写的桌面端应用的传输速度发一下，趁着这个帖子还有点热度打个广告。
|
 |
22
好奇站长做了 这么多功能如何盈利
|
|
23
@Fengyesuixiang 如果我做的小东西，能帮别人解决生活里的某件小事，对我来说就是一件很有意义的事。站里也有打赏站长的入口，0.99 、2.99 、4.99 元都可以。如果有人愿意打赏，那就更让我开心了。这让我知道，有人在陪我一起把这件有意义的事做下去。
|
4
Select Language