博文

在 Docker 容器中发现 Apple TV:mDNS、多播与 Avahi

Home Assistant(HA)在物理机上可以自动发现 Apple TV(ATV), 但当 HA 跑在 Docker 容器里、使用 bridge 网络时,经常会出现下面这些现象: HA 发现不了 ATV 容器里 atvremote scan 看不到 ATV,宿主机可以 容器里和宿主机里 avahi-browse 都能看到 ATV 下面是我排查这个问题的过程。 Avahi 能看到,但 HA 看不到 按照 HA 的推荐配置,把宿主机的 Avahi socket 挂进容器: volumes: - /var/run/avahi-daemon:/var/run/avahi-daemon - /run/dbus:/run/dbus 在容器里跑: avahi-browse -a 能看到 Apple TV,但 HA 依然发现不了。 查了一下才意识到一点: HA 并不通过 Avahi 发现 Apple TV。 HA 用的是 pyatv , pyatv 用的是 zeroconf ,完全不走 Avahi。 avahi-browse 能看到,是因为它通过 socket 连的是宿主机上的 Avahi。 这意味着: HA 是在容器里自己直接发 mDNS 包。 mDNS 在跑,但容器里收不到 mDNS 用的是 UDP 5353,多播地址 224.0.0.251。 在局域网里随便抓: tcpdump -i any udp port 5353 能看到 Apple TV 的广播。 但在容器里: 抓不到任何 5353 流量 在容器里跑 atvremote scan ,查询包看起来“发了”,但宿主机物理网卡上完全看不到 基本可以确认两件事: Docker bridge 网络 收不到 外部 mDNS 广播 Docker bridge 网络 发不出 mDNS 多播查询 主动扫描 vs 被动发现 atvremote scan 是主动扫描: 发 mDNS 查询,等设备回应 —— 在 bridge 网络里直接死掉。 但 mDNS 还有一条路: 设备会周期性广播 announce 包,只要你在监听,就能“被动发现”。 这也解释了一个现象: 即使容器里发不出查询,只要能收到广播,理论上还是...

《比特币:一种点对点电子货币系统》详解

图片
  《比特币:一种点对点电子货币系统》详解 最近开始学习比特币,第一步就是阅读它的白皮书: https://bitcoin.org/files/bitcoin-paper/bitcoin_zh_cn.pdf 。白皮书其实不长,中文版只有 9 页,很快就能读完。不过读完后我发现,里面省略了不少细节,只讲了大致的思路。为了搞清楚具体流程,我又查阅了很多资料,结合具体的 Bitcoin Core 程序实现。在这篇文章里,我会按段落列出白皮书内容,并加上自己的扩充,希望能帮到也在学习比特币的你。 我添加的段落,会以“ 注: ”开始。 摘要:一种完全的点对点电子货币应当允许在线支付从一方直接发送到另一 方,而不需要通过一个金融机构。数字签名提供了部分解决方案,但如果仍需 一个可信任的第三方来防止双重支付,那就失去了电子货币的主要优点。我们 提出一种使用点对点网络解决双重支付问题的方案。该网络通过将交易哈希进 一条持续增长的基于哈希的工作量证明链来给交易打上时间戳,形成一条除非 重做工作量证明否则不能更改的记录。最长的链不仅是被见证事件序列的证 据,而且也是它本身是由最大 CPU 算力池产生的证据。只要多数的 CPU 算 力被不打算联合攻击网络的节点控制,这些节点就将生成最长的链并超过攻击 者。这种网络本身只需极简的架构。信息将被尽力广播,节点可以随时离开和 重新加入网络,只需接受最长的工作量证明链作为它们离开时发生事件的证 据。 简介 互联网贸易已经变得几乎完全依赖金融机构作为可信任的第三方来处理电子支付。尽管对于大部分交易这种系统运行得足够好,但仍需忍受基于信任模型这个固有缺点。由于金融机构不可避免的需要仲裁纠纷,完全不可撤销的交易实际是做不到的。仲裁成本增加了交易成本,限制了最小实际交易额度从而杜绝了日常小额交易的可能性,而且由于不支持不可撤销支付,对不可撤销服务进行支付将需要更大的成本。由于存在交易被撤销的可能性,对于信任的需求将更广泛。商家必须警惕他们的客户,麻烦他们提供更多他本不需要的信息。一定比例的欺诈被认为是不可避免的。虽可通过当面使用实物货币来避免这些成本及支付的不确定性,但不存在一个无可信任方而能在通信通道上进行支付的机制。 我们需要的是一个基于密码学原理而不是信任的电子支付系统,该系统允许任何有交易意愿的双方能直接交易而不需要一...