为啥以前接受过小米摄像机共享 我先在无法共享了？

Posted 2023-05-15

以前能正常查看的 前几天手机恢复出厂设置后 叫人家重新分享给我 点进去就这样了

以前接受过小米摄像头的这个共享的话，他妈现在无法共享，可能是因为你已经接受连接别的，把它先取消掉，然后再连接就可以了。 参考技术A 不知道差友们目前有没有考虑过买个摄像头或者正在使用智能摄像头的？
智能摄像头这么小的一个东西价格也不贵，配合它的智能监控功能，无论是拿来在没人的时候看家护院还是照看留守在家的猫狗主子都再合适不过。

然而我们都知道任何凡是涉及隐私的东西，不管它看起来有多么安全难免都会存在隐私泄露的问题。
这不，就在今天下午，世超就看到了小米摄像头在国外被曝出存在重大漏洞的新闻。
再加上这件事情又刚好涉及到个人隐私泄露，所以谷歌直接把自家设备上所有的小米设备集成功能都暂时给禁了。。。

这到底是咋回事呢？
漏洞会对国内正在使用小米摄像头的人有影响吗？
别急，先让世超帮差友们简单梳理下这事的经过。
事情的起因最先是由国外一位名叫“ Dio-V ”网友在 Reddit 上发的一个帖子引起的。

当时他正在把小米米家安全摄像头连接到 Google Nest Hub（ 带显示屏的智能家居设备 ）上准备看看自家情况时，却意外的看到了别人家的画面。

而且这画面显示的是来自购买了相同硬件的随机人群家中获取的静态图像，每当他点进去查看摄像头的画面时，图片里的场景都会有所变化。
从他当时上传的几张照片里。
我们可以看到正在熟睡的婴儿。

正躺在客厅椅子上的老人。

还有空无一人的房间。

虽然这画面是静止并且随机的，有些画面也只有一部分而且上面的时间戳也不一样，但以上这些都不是发帖人家里的摄像头应该捕捉到的画面。
与此同时，他还顺带把自己购买的摄像头型号截图上传到了帖子上。

消息一出论坛上不少的网友们都炸了，很快就在原帖下引起了热议：
“ 太可怕了 ”、“ 这就是我为什么不购买小米的原因，他们的业务是数据，而不是实际的设备 ”、“ 这是 Google 的问题，还是小米的问题？”。。。

事情曝光没多久。
当事人之一的谷歌就对媒体发布声明说：“ 我们已经意识到了这一问题，并正在与小米联系以进行修复。同时，我们正在禁用设备上的小米集成。”
随后小米针对这件事也作出了回应：
整个事故是由上线的一项测试新功能的 bug 引起的，在弱网情况下才有极小概率出现，目前 bug 已经得到了修复，国内用户不受影响。

原来是 bug 的问题，好在其中只有极少数的人有可能受到影响，不过贸然在用户上测试新功能真的好吗。。。
自此小米摄像头用户在谷歌智能家居设备上收到其他用户串流画面的事件才正式告一段落。
如果世超没记错的话，在小米之前也有其它品牌的智能摄像头被爆出过隐私泄露的问题，有些隐私泄露就不是因为 bug ，而是真正的黑客故意入侵了。
亚马逊摄像头被黑后和女孩对话，称他是圣诞老人▼

这里可能有些差友会好奇为啥摄像头看起来这么不安全，就算是诸如谷歌、亚马逊等技术实力不弱的大公司的摄像头产品也会有隐私泄露的问题？
理由说出来差友们可能会不信，摄像头之所以会泄露隐私，可能是因为它们都太过智能了。。。

众所周知现在的智能摄像头，除了摄像头本身外，肯定还会有联网到云端以及手机端查看的功能。
因为只有这样，我们才可以直接使用家里的 Wi-Fi 来和它联网，并且在我们手机的 App 里远程实时查看监控家里的环境。

正是由于摄像头在实现监控过程中的中间环节越多，就越容易出现问题。
拿 Wi-Fi 来说，摄像头和云端采用的通信协议是通用的还是私有的每个摄像头都有区别；app 和云端连接时通信流量有没有加密或者挟持谁也说不准。
网友们常用密码排名▼

我们在使用配套的云服务时，对用户注册的密码复杂度有无要求、支持单点登录还是多点登录、服务器本身有没有防火墙等都会影响摄像头的安全性。
如果想要破解你摄像头的人能够接触到实物的话就更方便了，直接像小偷撬锁一样通过调试接口、获取敏感权限、篡改存放着密码的存储介质就行。

暂且忽略摄像头的 bug 问题，谁能保证它能在另外几个环节做到面面俱到毫无纰漏呢？就算厂商做到了，不改初始密码直接用的人也大有人在。
所以。。。
如果家里面要装监控，一定买个好一点的摄像头，并且及时进行固件升级，密码也要设置的长一些，才能离 “ 被直播 ” 更远。
当然如果你不嫌麻烦的话也有更直接的物理方法：人不在时开摄像头，人回来时拔掉摄像头电源，这样起码隐私泄露时人是不会被拍进去了。。。 参考技术B 如果接受过小米摄像机的共享的话，现在无法共享，是因为你没有打开GPS，所以可以先打开这个功能 参考技术C 以前接受过小米摄像头共享，现在无法共享了，很有可能他现在更新了之后，他就是没有这种的功能了。 参考技术D 以前接受过小米摄像机共享 我先在无法共享了，是因为你恢复出厂设置后改变了之前的设置，另外还需要安装对应APP才可以实现共享的

为啥通过共享内存的通信比通过队列慢得多？

【中文标题】为啥通过共享内存的通信比通过队列慢得多？

【英文标题】：Why is communication via shared memory so much slower than via queues?为什么通过共享内存的通信比通过队列慢得多？

【发布时间】：2014-10-05 23:03:15

【问题描述】：

我在最近的老式 Apple MacBook Pro 上使用 Python 2.7.5，它有四个硬件和八个逻辑 CPU；即，sysctl 实用程序给出：

$ sysctl hw.physicalcpu
hw.physicalcpu: 4
$ sysctl hw.logicalcpu
hw.logicalcpu: 8

我需要对大型一维列表或数组执行一些相当复杂的处理，然后将结果保存为中间输出，稍后将在我的应用程序的后续计算中再次使用它。我的问题的结构很自然地适合并行化，所以我想我会尝试使用 Python 的多处理模块将一维数组细分为几块（4 块或 8 块，我还不确定哪个），执行并行计算，然后将结果输出重新组合成最终格式。我正在尝试决定是使用multiprocessing.Queue()（消息队列）还是multiprocessing.Array()（共享内存）作为将结果计算从子进程传回主父进程的首选机制，我一直在尝试几个“玩具”模型，以确保我了解多处理模块的实际工作原理。然而，我遇到了一个相当出乎意料的结果：在为同一问题创建两个本质上等效的解决方案时，使用共享内存进行进程间通信的版本似乎比使用消息的版本需要更多的执行时间（比如多 30 倍！）排队。下面，我为一个“玩具”问题提供了两个不同版本的示例源代码，它使用并行进程生成一长串随机数，并以两种不同的方式将聚集的结果传回父进程：首先使用消息队列，第二次使用共享内存。

这是使用消息队列的版本：

import random
import multiprocessing
import datetime

def genRandom(count, id, q):

    print("Now starting process 0".format(id))
    output = []
    # Generate a list of random numbers, of length "count"
    for i in xrange(count):
        output.append(random.random())
    # Write the output to a queue, to be read by the calling process 
    q.put(output)

if __name__ == "__main__":
    # Number of random numbers to be generated by each process
    size = 1000000
    # Number of processes to create -- the total size of all of the random
    # numbers generated will ultimately be (procs * size)
    procs = 4

    # Create a list of jobs and queues 
    jobs = []
    outqs = []
    for i in xrange(0, procs):
        q = multiprocessing.Queue()
        p = multiprocessing.Process(target=genRandom, args=(size, i, q))
        jobs.append(p)
        outqs.append(q)

    # Start time of the parallel processing and communications section
    tstart = datetime.datetime.now()    
    # Start the processes (i.e. calculate the random number lists)      
    for j in jobs:
        j.start()

    # Read out the data from the queues
    data = []
    for q in outqs:
        data.extend(q.get())

    # Ensure all of the processes have finished
    for j in jobs:
        j.join()
    # End time of the parallel processing and communications section
    tstop = datetime.datetime.now()
    tdelta = datetime.timedelta.total_seconds(tstop - tstart)

    msg = "0 random numbers generated in 1 seconds"
    print(msg.format(len(data), tdelta))

当我运行它时，我得到的结果通常看起来像这样：

$ python multiproc_queue.py
Now starting process 0
Now starting process 1
Now starting process 2
Now starting process 3
4000000 random numbers generated in 0.514805 seconds

现在，这是等效的代码段，但稍作重构，使其使用共享内存而不是队列：

import random
import multiprocessing
import datetime

def genRandom(count, id, d):

    print("Now starting process 0".format(id))
    # Generate a list of random numbers, of length "count", and write them
    # directly to a segment of an array in shared memory
    for i in xrange(count*id, count*(id+1)):
        d[i] = random.random()

if __name__ == "__main__":
    # Number of random numbers to be generated by each process
    size = 1000000
    # Number of processes to create -- the total size of all of the random
    # numbers generated will ultimately be (procs * size)
    procs = 4

    # Create a list of jobs and a block of shared memory
    jobs = []
    data = multiprocessing.Array('d', size*procs)
    for i in xrange(0, procs):
        p = multiprocessing.Process(target=genRandom, args=(size, i, data))
        jobs.append(p)

    # Start time of the parallel processing and communications section
    tstart = datetime.datetime.now()    
    # Start the processes (i.e. calculate the random number lists)      
    for j in jobs:
        j.start()

    # Ensure all of the processes have finished
    for j in jobs:
    j.join()
    # End time of the parallel processing and communications section
    tstop = datetime.datetime.now()
    tdelta = datetime.timedelta.total_seconds(tstop - tstart)

    msg = "0 random numbers generated in 1 seconds"
    print(msg.format(len(data), tdelta))

但是，当我运行共享内存版本时，典型的结果看起来更像这样：

$ python multiproc_shmem.py 
Now starting process 0
Now starting process 1
Now starting process 2
Now starting process 3
4000000 random numbers generated in 15.839607 seconds

我的问题：为什么我的代码的两个版本之间的执行速度存在如此巨大的差异（大约 0.5 秒对 15 秒，是 30 倍！）？特别是，如何修改共享内存版本以使其运行得更快？

【问题讨论】：

将第一个示例中的queue.put 移动到for 循环中，使其与第二个示例中的d[i] 相同。目前，您无法比较这两种技术，因为 queue 一种被大量使用，而共享内存一种被急切使用。

【参考方案1】：

这是因为multiprocessing.Array默认使用锁来防止多个进程同时访问它：

multiprocessing.Array(typecode_or_type, size_or_initializer, *, lock=True)

...

如果 lock 为 True（默认值），则创建一个新的锁对象以同步对值的访问。如果 lock 是 Lock 或 RLock 对象 然后将用于同步访问该值。如果锁是 False 则不会自动访问返回的对象 受锁保护，因此不一定是“进程安全的”。

这意味着您并没有真正同时写入数组 - 一次只有一个进程可以访问它。由于您的示例工作人员除了数组写入之外几乎什么都不做，因此不断等待此锁会严重损害性能。如果在创建数组的时候使用lock=False，性能会好很多：

与lock=True:

Now starting process 0
Now starting process 1
Now starting process 2
Now starting process 3
4000000 random numbers generated in 4.811205 seconds

与lock=False:

Now starting process 0
Now starting process 3
Now starting process 1
Now starting process 2
4000000 random numbers generated in 0.192473 seconds

请注意，使用lock=False 意味着您需要手动保护对Array 的访问，只要您执行不安全的操作。您的示例是让进程写入独特的部分，所以没关系。但是，如果您在执行此操作时尝试从中读取，或者有不同的进程写入重叠部分，则需要手动获取锁。

【讨论】：

谢谢！一百万年我都不会猜到是内存锁定导致了所有额外开销。