T********i
发帖数: 2416 | 1 既然是原创，就不能牵狗找到答案。
大家都是专业人士，背景就不介绍了。
假定你有一个服务，在内网。你希望外网能够访问（比如通过手机），你要设置NAT
port forwarding。
现在的问题是：你在外面如何知道你的服务的IP？
当然普遍的做法是通过dyndns。这种服务很多。良莠不齐。基本都是收费的。主要的问
题就是，如果你的外部IP突然变了，dyndns如何能迅速知道？这样就只能把dyndns
updater装在router上。但是取决于你的router的厂商做的好不好？因为只有router能
马上知道IP变化。
现实是，很多情况下，IP变化，可能要几天才反映到dyndns上。
我的问题是：你能不能不依赖于router，以及dyndns，能够迅速知道IP变化？比如在30
秒以内。guarantee! 你可以连接一个外部服务查询当前IP，但是你不能每30秒干一次
。因为你的外部IP可能一年都不变。 |
T********i
发帖数: 2416 | 2 澄清一下，我说不依赖router，是不需要在router上装任何额外的服务。router只需要
提供正常的NAT port forward服务即可。 |
n******t
发帖数: 4406 | 3 30秒搞一次也沒啥問題吧，實在覺得總試不好，也可以記下當前的外部ip，然後內網的
機器
定時ping一下這個ip，如果超時或者ttl變了就說明IP變了，再按30秒的做法搞一下就
好了。
【在 T********i 的大作中提到】
: 既然是原创，就不能牵狗找到答案。
: 大家都是专业人士，背景就不介绍了。
: 假定你有一个服务，在内网。你希望外网能够访问（比如通过手机），你要设置NAT
: port forwarding。
: 现在的问题是：你在外面如何知道你的服务的IP？
: 当然普遍的做法是通过dyndns。这种服务很多。良莠不齐。基本都是收费的。主要的问
: 题就是，如果你的外部IP突然变了，dyndns如何能迅速知道？这样就只能把dyndns
: updater装在router上。但是取决于你的router的厂商做的好不好？因为只有router能
: 马上知道IP变化。
: 现实是，很多情况下，IP变化，可能要几天才反映到dyndns上。
|
s*i
发帖数: 5025 | 4 好难。这个跟 ngrok 所解决的问题是一类的吗？ |
T********i
发帖数: 2416 | 5 任何公共服务，whatismyip之类，30秒一次，几分钟之内就把你ban掉了。
我的需求，是为将来部署几十亿节点设计的。你服务每个节点30秒一次的查询，成本是
巨大的。
你的ping的想法已经很接近了，但是如果router禁止应答呢？我说了，不能依赖router。
【在 n******t 的大作中提到】
: 30秒搞一次也沒啥問題吧，實在覺得總試不好，也可以記下當前的外部ip，然後內網的
: 機器
: 定時ping一下這個ip，如果超時或者ttl變了就說明IP變了，再按30秒的做法搞一下就
: 好了。
|
T********i
发帖数: 2416 | 6 我这个更靠谱！重点是尽量不依赖云服务，尤其是云转发。
你只要设置一次NAT port forwarding就好了。技术上当然要求多一点。但是设置NAT
port forwarding不是啥大问题。如果确实连这个都做不到，而且连找人帮忙都找不到
，可能也不会需要你的产品。
当然我的Hub缺省是云转发。但是会一直bug用户去设置port forwarding。port
forwarding是双赢。用户latency和可靠性都会大大改善。我们的运营成本也会降到0。
【在 s*i 的大作中提到】
: 好难。这个跟 ngrok 所解决的问题是一类的吗？
|
n******t
发帖数: 4406 | 7 router不應答ping也行，用tcp syn-ack就行了。
router。
網的
下就
【在 T********i 的大作中提到】
: 任何公共服务，whatismyip之类，30秒一次，几分钟之内就把你ban掉了。
: 我的需求，是为将来部署几十亿节点设计的。你服务每个节点30秒一次的查询，成本是
: 巨大的。
: 你的ping的想法已经很接近了，但是如果router禁止应答呢？我说了，不能依赖router。
|
T********i
发帖数: 2416 | 8 如果你邻居家恰好也开了这个port呢？
【在 n******t 的大作中提到】
: router不應答ping也行，用tcp syn-ack就行了。
:
: router。
: 網的
: 下就
|
n******t
发帖数: 4406 | 9 要想確保就搞個fingerprint好了。反正內部機器開個服務也行。
【在 T********i 的大作中提到】
: 如果你邻居家恰好也开了这个port呢？
|
T********i
发帖数: 2416 | 10 牛！思路完全正确！有老司机的风范。
其实不是内部机器开个服务，而是这个服务自己服务自己而已。
反正你开port forward就是有服务才开。这个服务加一个fingerprint的功能就好了。
你叫fingerprint，我叫port forward verification。一码事。
其实还有附加好处。那就是30秒以内就能验证你的port forward是不是设置对了？如果
设置错了，可以fallback to cloud forward，同时马上报警。
client，包括手机也是一样，cloud服务两个功能：
1. 任何时候port forward有问题，作为forward备份。
2. 给client实时提供service IP & port。
这是最可靠，零浪费的service framework。
【在 n******t 的大作中提到】
: 要想確保就搞個fingerprint好了。反正內部機器開個服務也行。
|
|
|
n******t
发帖数: 4406 | 11 對的，如果你自己的服務就直接整合掉好了。
問題這種類似問題做設計，現在很多公司裏面就一堆architecht提着buzzword衝上來了，
很煩。
【在 T********i 的大作中提到】
: 牛！思路完全正确！有老司机的风范。
: 其实不是内部机器开个服务，而是这个服务自己服务自己而已。
: 反正你开port forward就是有服务才开。这个服务加一个fingerprint的功能就好了。
: 你叫fingerprint，我叫port forward verification。一码事。
: 其实还有附加好处。那就是30秒以内就能验证你的port forward是不是设置对了？如果
: 设置错了，可以fallback to cloud forward，同时马上报警。
: client，包括手机也是一样，cloud服务两个功能：
: 1. 任何时候port forward有问题，作为forward备份。
: 2. 给client实时提供service IP & port。
: 这是最可靠，零浪费的service framework。
|
p***o
发帖数: 1252 | 12 内部服务用外部IP连自己？你这个得router支持NAT hairpinning吧。
【在 T********i 的大作中提到】
: 牛！思路完全正确！有老司机的风范。
: 其实不是内部机器开个服务，而是这个服务自己服务自己而已。
: 反正你开port forward就是有服务才开。这个服务加一个fingerprint的功能就好了。
: 你叫fingerprint，我叫port forward verification。一码事。
: 其实还有附加好处。那就是30秒以内就能验证你的port forward是不是设置对了？如果
: 设置错了，可以fallback to cloud forward，同时马上报警。
: client，包括手机也是一样，cloud服务两个功能：
: 1. 任何时候port forward有问题，作为forward备份。
: 2. 给client实时提供service IP & port。
: 这是最可靠，零浪费的service framework。
|
T********i
发帖数: 2416 | 13 是的，又称为NAT loopback，或者NAT reflection。
问题是，不支持这个功能的router是不合格的。因为你向外部提供的服务，内部反倒不
能用了。It doesn't make any sense!
事实上，不支持这个功能的router，现在已经找不到了。
: 内部服务用外部IP连自己？你这个得router支持NAT hairpinning吧。
【在 p***o 的大作中提到】
: 内部服务用外部IP连自己？你这个得router支持NAT hairpinning吧。
|
T********i
发帖数: 2416 | 14 如果你的router不支持NAT Hair pinning，对于我的架构，30秒以后，服务自己就能检
测到port forwarding不work。然后自动Rollback到cloud forward。同时报警，用户手
机立刻收到报警。
然后，用户就知道应该换掉那个sucker router。 |
g****t
发帖数: 31659 | 15 这问题以前你讨论过吧？
IP变了的话，client software发email。提供服务的机器，listen new email。
有新email ，改设置，这样可以吗？
类似的毛招搞几个并起来，鲁棒性应该有一定保证了。
【在 T********i 的大作中提到】
: 既然是原创，就不能牵狗找到答案。
: 大家都是专业人士，背景就不介绍了。
: 假定你有一个服务，在内网。你希望外网能够访问（比如通过手机），你要设置NAT
: port forwarding。
: 现在的问题是：你在外面如何知道你的服务的IP？
: 当然普遍的做法是通过dyndns。这种服务很多。良莠不齐。基本都是收费的。主要的问
: 题就是，如果你的外部IP突然变了，dyndns如何能迅速知道？这样就只能把dyndns
: updater装在router上。但是取决于你的router的厂商做的好不好？因为只有router能
: 马上知道IP变化。
: 现实是，很多情况下，IP变化，可能要几天才反映到dyndns上。
|
g****t
发帖数: 31659 | 16 另外我查了下，现在比特币用UPNP
https://en.wikipedia.org/wiki/Universal_Plug_and_Play
古代我记得中本聪就是一堆毛招并起来找自己的外部IP。（irc聊天室，网站，etc）
【在 g****t 的大作中提到】
: 这问题以前你讨论过吧？
: IP变了的话，client software发email。提供服务的机器，listen new email。
: 有新email ，改设置，这样可以吗？
: 类似的毛招搞几个并起来，鲁棒性应该有一定保证了。
|
T********i
发帖数: 2416 | 17 这个问题和email根本不是一个层面的问题。
至于Upnp，存在各种巨大安全风险，缺省都是禁用的。与其手动开启Upnp, 不如手动开
启port forwarding。
我的方案，是最优的。而且是以前没人用过的。有可能会影响将来数以亿计的设备的。
反正带来各种利益关系的变化是肯定的。
: 另外我查了下，现在比特币用UPNP
: https://en.wikipedia.org/wiki/Universal_Plug_and_Play
: 古代我记得中本聪就是一堆毛招并起来找自己的外部IP。（irc聊天室，网站，
etc）
【在 g****t 的大作中提到】
: 另外我查了下，现在比特币用UPNP
: https://en.wikipedia.org/wiki/Universal_Plug_and_Play
: 古代我记得中本聪就是一堆毛招并起来找自己的外部IP。（irc聊天室，网站，etc）
|
g****t
发帖数: 31659 | 18 firewall could cause issues.
【在 T********i 的大作中提到】
: 如果你的router不支持NAT Hair pinning，对于我的架构，30秒以后，服务自己就能检
: 测到port forwarding不work。然后自动Rollback到cloud forward。同时报警，用户手
: 机立刻收到报警。
: 然后，用户就知道应该换掉那个sucker router。
|
g****t
发帖数: 31659 | 19 30秒的话，email是可以的。你可以测一下。
我家里机器有个python就这么干的。
【在 T********i 的大作中提到】
: 这个问题和email根本不是一个层面的问题。
: 至于Upnp，存在各种巨大安全风险，缺省都是禁用的。与其手动开启Upnp, 不如手动开
: 启port forwarding。
: 我的方案，是最优的。而且是以前没人用过的。有可能会影响将来数以亿计的设备的。
: 反正带来各种利益关系的变化是肯定的。
:
:
: 另外我查了下，现在比特币用UPNP
:
: https://en.wikipedia.org/wiki/Universal_Plug_and_Play
:
: 古代我记得中本聪就是一堆毛招并起来找自己的外部IP。（irc聊天室，网站，
: etc）
|
T********i
发帖数: 2416 | 20 这个问题，和你说的那个过程，完全是不同的问题。
30秒是我随口说的。我做到3秒都没任何问题。给router带来的压力连万分之一CPU都不
到。
: 30秒的话，email是可以的。你可以测一下。
: 我家里机器有个python就这么干的。
【在 g****t 的大作中提到】
: 30秒的话，email是可以的。你可以测一下。
: 我家里机器有个python就这么干的。
|
|
|
g****t
发帖数: 31659 | 21 I agree.
时间,CPU loading 是一方面。
email没有安全性。自己玩玩还行。做产品肯定不能这么干。
我专门弄了个Gmail帐号，办这类事。
【在 T********i 的大作中提到】
: 这个问题，和你说的那个过程，完全是不同的问题。
: 30秒是我随口说的。我做到3秒都没任何问题。给router带来的压力连万分之一CPU都不
: 到。
:
:
: 30秒的话，email是可以的。你可以测一下。
:
: 我家里机器有个python就这么干的。
:
|
C*****n
发帖数: 1049 | 22 你都能换掉sucker router了，不如换一个dd-wrt的，想怎么玩都行。还是用dyndns是
正道，你那solution都是hack，万一你那每30秒查询一下自己的服务（通过loopback回
来)的cron job挂掉了呢？
实际情况是dyndns非常reliable，我用的freedns.afraid.org也是免费的，过去近10年
来从没出现过问题，都是外网ip一遍，dns就更新了（当然这种情况基本上是几个月甚
至一两年才发生一次）。 |
n******t
发帖数: 4406 | 23 不支持loopback的router，我最近10幾年沒見過，including isp送的。
從個人角度出發，dyndns本身的確還行沒什麼問題，但是你用免費的難道不會每個月叫
你手動上去verify capcha嗎？
當然他要做產品另當別論，肯定不能指望dyndns的。
【在 C*****n 的大作中提到】
: 你都能换掉sucker router了，不如换一个dd-wrt的，想怎么玩都行。还是用dyndns是
: 正道，你那solution都是hack，万一你那每30秒查询一下自己的服务（通过loopback回
: 来)的cron job挂掉了呢？
: 实际情况是dyndns非常reliable，我用的freedns.afraid.org也是免费的，过去近10年
: 来从没出现过问题，都是外网ip一遍，dns就更新了（当然这种情况基本上是几个月甚
: 至一两年才发生一次）。
|
T********i
发帖数: 2416 | 24 其实这是个逻辑问题，普通用户可以不需要任何逻辑，专业人士应该时时刻刻都要坚持
才对。
现在分析一下需求。假定你产品提供商，用户是产品使用者。你和用户的需求都是什么？
前提条件：
你的产品放在用户内网，为用户的手机提供服务。
大家的共同需求，是一致的：
用户的手机随时能够访问你的产品。
附加要求：
如果你的产品挂了，用户的手机在第一时间能够知道。
现在根据逻辑，看看dyndns是不是需要？
可能方案有两个：
1. 你在internet上有个公共服务器，提供转发服务。
2. 你让用户开一个NAT port forwarding。
下面回到我的初始问题。dyndns是不是需要？
1. 公共服务器转发服务 - 不需要dyndns
2. NAT port forwarding - 用我的设计，也绝对不需要dyndns。因为我的公共服务器
就是dyndns的作用。而且比dyndns要好。
以下“公共服务器”称为bridge...
下面是我的具体实现逻辑：
1. bridge转发 - 不用说了。缺省就是这个。用户啥也不需要做。就能满足需求。
2. NAT port forwarding - 用户设置以后，3-30秒以内，整个系统自己就知道是不是
设置错了？如果设置错了，自动转换成上面的（bridge转发）。
3. 如果自我验证设置正确，通知bridge。然后从bridge断开。从此以后提供独立服务。
手机用户：
首次使用，先连接bridge。如果是转发模式，就通过bridge转发使用。如果是port
forwarding，从bridge断开。永久记录IP:port，从此进入直连模式。
如果一切正常。port forwarding以后一直都会成功直连。不论手机还是内网服务从此
都不会打扰bridge。bridge的运营就省钱了。
下面讲port forwarding不正常的情况：
1. 你的外网IP变了。服务3-30秒以内检测到。重新连接bridge，马上bridge就告诉它
新的IP。顺便在bridge注册新的IP。port没有变化。手机连接你的router会马上失败。
然后连接bridge。bridge告知新的IP。重连接。一切正常。
2. 你把router设置改了。port forward关掉了。服务3-30秒以内检测到。重新连接
bridge。发现IP没有变化。知道配置错了。重新切换bridge转发。手机连接你的router
会马上失败。然后连接bridge。从此转换到bridge转发。
下面讲你的内网服务挂了。或者你家网络断了。
这两种情况，逻辑上，光靠我们自己，是无法区分的。到底是网络断了？还是我们的服
务挂了？永远要靠用户去判断。但是用户手机在第一时间就知道服务连不上了。故障是
肯定的。
我们的bridge挂了：
绝大多数port forward的用户，因为IP变化不频繁，仍然能够长期（几天，几个月，几
年？）使用不受任何影响。所以我们的bridge越简单越好。一旦挂了，可以几分钟修复。
因此，我的设计和架构。是绝对不需要dyndns的。
而且，bridge转发是必须要有的。因为1. 肯定有不设置port forwarding的用户。2.
设置port forwarding，手机用户也需要随着知道最新的IP:port。
bridge的作用，就是让用户尽量不需要它。正因为如此，它才会变成永远不可或缺的。
变成所有用户必须需要的。
因此，bridge有所用dyndns的功能，还有很多dyndns没有的。而且它是私密的。auth不
通过，不会告诉你信息的。不像dyndns，知道你的域名，你的家庭IP永远被别人追踪。
dyndns每隔几秒钟都需要重新查询。bridge可能几年都不需要被查询。
老sui提到的ngrok，设计思想就是错的。按照我说的修改，照样大家都依赖，运营成本
能降低几十倍。 |
T********i
发帖数: 2416 | 25 我们往更深层次去探讨社会哲学问题。
你设计一个服务，目的是所有人都尽量不需要你。结果是所有人都离不开你。我就刚刚
给出了一个例子。
这是一个思维转向的问题。就像数学一样，符号逻辑多转一个弯，能搞定的只剩下那些
得沃尔夫奖之类的人士了。在这个码工遍地的时代，这个哲学从来没人提出来过，也是
醉了！！！
尤其是目前我们的后现代，后工业化时代。大多数生意已经变成损人不利己祸害社会了
。思维转向尤其重要！
是为记。。。 |
s*i
发帖数: 5025 | 26 厉害！
换router后，手机需要考虑一下怎么提醒重新设置问题
: 我们往更深层次去探讨社会哲学问题。
: 你设计一个服务，目的是所有人都尽量不需要你。结果是所有人都离不开你。我
就刚刚
: 给出了一个例子。
: 这是一个思维转向的问题。就像数学一样，符号逻辑多转一个弯，能搞定的只剩
下那些
: 得沃尔夫奖之类的人士了。在这个码工遍地的时代，这个哲学从来没人提出来过
，也是
: 醉了！！！
: 尤其是目前我们的后现代，后工业化时代。大多数生意已经变成损人不利己祸害
社会了
: 。思维转向尤其重要！
: 是为记。。。
【在 T********i 的大作中提到】
: 我们往更深层次去探讨社会哲学问题。
: 你设计一个服务，目的是所有人都尽量不需要你。结果是所有人都离不开你。我就刚刚
: 给出了一个例子。
: 这是一个思维转向的问题。就像数学一样，符号逻辑多转一个弯，能搞定的只剩下那些
: 得沃尔夫奖之类的人士了。在这个码工遍地的时代，这个哲学从来没人提出来过，也是
: 醉了！！！
: 尤其是目前我们的后现代，后工业化时代。大多数生意已经变成损人不利己祸害社会了
: 。思维转向尤其重要！
: 是为记。。。
|
T********i
发帖数: 2416 | 27 给你看看截图，设置port forwarding以后，在router上把port forwarding关闭。
每次都是30秒以内。检测到port forwarding突然不work了。自动切换成bridge转发模
式。同时顺便给手机发个消息。
顶上数2，3，4项。
手机总之都能时刻连上内网服务。这是手机和bridge以及你的router之间的逻辑。
结果就是不管你咋折腾，手机都能时刻找到并连接你的内网服务。有错还能随时给你报
错。
【在 s*i 的大作中提到】
: 厉害！
: 换router后，手机需要考虑一下怎么提醒重新设置问题
:
:
: 我们往更深层次去探讨社会哲学问题。
:
: 你设计一个服务，目的是所有人都尽量不需要你。结果是所有人都离不开你。我
: 就刚刚
:
: 给出了一个例子。
:
: 这是一个思维转向的问题。就像数学一样，符号逻辑多转一个弯，能搞定的只剩
: 下那些
:
: 得沃尔夫奖之类的人士了。在这个码工遍地的时代，这个哲学从来没人提出来过
|
g****t
发帖数: 31659 | 28 我没细想。但是直觉觉得，design好像有点太复杂了。
程序里面应该有好几个等待，继续try几次然后做结论的地方。
这些等待的时间配合不好的话，可能会有问题。小心为妙。
The potential conflications of network delay and other hardware response delay
could be very tricky.
IMPHO，design越靠近email/new email listener，越强壮。
如果是手机开家里台灯这种任务，除了你说的bridge的办法，我会用email做
冗余。
【在 T********i 的大作中提到】
: 给你看看截图，设置port forwarding以后，在router上把port forwarding关闭。
: 每次都是30秒以内。检测到port forwarding突然不work了。自动切换成bridge转发模
: 式。同时顺便给手机发个消息。
: 顶上数2，3，4项。
: 手机总之都能时刻连上内网服务。这是手机和bridge以及你的router之间的逻辑。
: 结果就是不管你咋折腾，手机都能时刻找到并连接你的内网服务。有错还能随时给你报
: 错。
|
h****e
发帖数: 2125 | 29 你其实不用和那个假行家讨论啥，他一个硬工转行的，根本不懂你在说啥。
【在 T********i 的大作中提到】
: 这个问题，和你说的那个过程，完全是不同的问题。
: 30秒是我随口说的。我做到3秒都没任何问题。给router带来的压力连万分之一CPU都不
: 到。
:
:
: 30秒的话，email是可以的。你可以测一下。
:
: 我家里机器有个python就这么干的。
:
|
g****t
发帖数: 31659 | 30 我说的方案，代码是成立的。任何人一眼就可以看出来。
不足之处在安全和资源消耗。
本身network programming就是专门的学问。不懂很正常。
你有什么高见，也可以讲。
【在 h****e 的大作中提到】
: 你其实不用和那个假行家讨论啥，他一个硬工转行的，根本不懂你在说啥。
|
|
|
T********i
发帖数: 2416 | 31 要是没任何复杂度，还能轮到我原创么？
当然，很多人一听就明白了。这就是一个典型的状态自动机。当然，不要以为状态自动
机很容易实现。其实也就100行左右的代码，但是没10年功力还想做对？也不要当码工
那么不值钱好吧？
无论如何，这个问题本身和email没有任何关系。
delay
【在 g****t 的大作中提到】
: 我没细想。但是直觉觉得，design好像有点太复杂了。
: 程序里面应该有好几个等待，继续try几次然后做结论的地方。
: 这些等待的时间配合不好的话，可能会有问题。小心为妙。
: The potential conflications of network delay and other hardware response delay
: could be very tricky.
: IMPHO，design越靠近email/new email listener，越强壮。
: 如果是手机开家里台灯这种任务，除了你说的bridge的办法，我会用email做
: 冗余。
|
g****t
发帖数: 31659 | 32 [A]
你们讨论的solution中用的网络技术,多数
都是为了应对client很多的情况,发展而来的.
但是如果client的(cell phone)个数不是很多。cell phone从外网访问内网。
短信，email，irc server，telegram....为基础的代码,都是成立的。
只要满足
1.有个第三方服务器
2.客户端能listen the 3rd party server,而不是轮询。
(在十多年前，这个是blackberry手机的高技术)
用什么都可以。
[B]
另外我不明白为啥你那个bridge要转发内容？
bridge用来保障port forwarding,换ip什么的可以理解。
转发内容，那cost会不会很高。
【在 T********i 的大作中提到】
: 要是没任何复杂度，还能轮到我原创么？
: 当然，很多人一听就明白了。这就是一个典型的状态自动机。当然，不要以为状态自动
: 机很容易实现。其实也就100行左右的代码，但是没10年功力还想做对？也不要当码工
: 那么不值钱好吧？
: 无论如何，这个问题本身和email没有任何关系。
:
: delay
|
T********i
发帖数: 2416 | 33 ISO Layer都不在同一层。讨论哪一层说哪一层的事情。
persistent & reliable communication channel建立了，是发短信还是发email，那是
另外一个层面的问题。
就是这个特定层，我也只是解决了一个具体问题而已。所以我只针对这个具体问题讨论
。所以大家也都是针对这个具体问题讨论，这样才不会跑偏。
这个问题的本质是一种新的分布式网络架构。解决的是服务去中心化的问题。
server,，
【在 g****t 的大作中提到】
: [A]
: 你们讨论的solution中用的网络技术,多数
: 都是为了应对client很多的情况,发展而来的.
: 但是如果client的(cell phone)个数不是很多。cell phone从外网访问内网。
: 短信，email，irc server，telegram....为基础的代码,都是成立的。
: 只要满足
: 1.有个第三方服务器
: 2.客户端能listen the 3rd party server,而不是轮询。
: (在十多年前，这个是blackberry手机的高技术)
: 用什么都可以。
|
g****t
发帖数: 31659 | 34 你用bridge转内容，cost会不会很高？一家4个手机。
【在 T********i 的大作中提到】
: ISO Layer都不在同一层。讨论哪一层说哪一层的事情。
: persistent & reliable communication channel建立了，是发短信还是发email，那是
: 另外一个层面的问题。
: 就是这个特定层，我也只是解决了一个具体问题而已。所以我只针对这个具体问题讨论
: 。所以大家也都是针对这个具体问题讨论，这样才不会跑偏。
: 这个问题的本质是一种新的分布式网络架构。解决的是服务去中心化的问题。
:
: server,，
|
T********i
发帖数: 2416 | 35 那家人如果有个symmetrical firewall，又拒绝设置port forwarding，难道我不让他
们用？
cost也不高，控制灯和空调，每天流量几百byte。倒是heartbeat每分钟有16 bytes。
当然，这个流量，平摊给每个人，每年运营成本都不到一美分。
而且，你只要在家，就自动切换到家里wifi和Hub内部连接了。不会用bridge流量了。
别家的产品，乐不得的。而且都是强制转发。偷你数据，不管有用没用先偷着，而且还
要想方设法让你习惯，而且让你子子孙孙都习惯。
至少，我可以让用户每次用手机app的时候，bug他一下，弹出一个窗口说：设置port
forwarding，你好我好大家好。
另外，每个用户第一次上电使用hub的时候，用手机设置，缺省一定是转发的。
【在 g****t 的大作中提到】
: 你用bridge转内容，cost会不会很高？一家4个手机。
|
g****t
发帖数: 31659 | 36 你有用Bluetooth 嗎？我幾日前買了一組google router自用。第一次上電時，
bluetooth連手機app。看著過程平順，強壯，堪稱優秀設計。
這些邊界情況，看著不起眼，但設計好頗為不易。
: 那家人如果有个symmetrical firewall，又拒绝设置port forwarding，
难道我
不让他
: 们用？
: cost也不高，控制灯和空调，每天流量几百byte。倒是heartbeat每分钟
有16
bytes。
: 当然，这个流量，平摊给每个人，每年运营成本都不到一美分。
: 而且，你只要在家，就自动切换到家里wifi和Hub内部连接了。不会用
bridge流
量了。
: 别家的产品，乐不得的。而且都是强制转发。偷你数据，不管有用没用先
偷着，
而且还
: 要想方设法让你习惯，而且让你子子孙孙都习惯。
: 至少，我可以让用户每次用手机app的时候，bug他一下，弹出一个窗口说
：设置
port
: forwarding，你好我好大家好。
: 另外，每个用户第一次上电使用hub的时候，用手机设置，缺省一定是转
发的。
【在 T********i 的大作中提到】
: 那家人如果有个symmetrical firewall，又拒绝设置port forwarding，难道我不让他
: 们用？
: cost也不高，控制灯和空调，每天流量几百byte。倒是heartbeat每分钟有16 bytes。
: 当然，这个流量，平摊给每个人，每年运营成本都不到一美分。
: 而且，你只要在家，就自动切换到家里wifi和Hub内部连接了。不会用bridge流量了。
: 别家的产品，乐不得的。而且都是强制转发。偷你数据，不管有用没用先偷着，而且还
: 要想方设法让你习惯，而且让你子子孙孙都习惯。
: 至少，我可以让用户每次用手机app的时候，bug他一下，弹出一个窗口说：设置port
: forwarding，你好我好大家好。
: 另外，每个用户第一次上电使用hub的时候，用手机设置，缺省一定是转发的。
|
T********i
发帖数: 2416 | 37 我个人不喜欢bluetooth。主要是它那个mesh network，节点转发竟然靠broadcast
flood。任何懂行的都能看出属于极端不负责任。
【在 g****t 的大作中提到】
: 你有用Bluetooth 嗎？我幾日前買了一組google router自用。第一次上電時，
: bluetooth連手機app。看著過程平順，強壯，堪稱優秀設計。
: 這些邊界情況，看著不起眼，但設計好頗為不易。
:
:
: 那家人如果有个symmetrical firewall，又拒绝设置port forwarding，
: 难道我
: 不让他
:
: 们用？
:
: cost也不高，控制灯和空调，每天流量几百byte。倒是heartbeat每分钟
: 有16
|
n******t
发帖数: 4406 | 38 bluetooth的兼容性是個大問題。可能現在好好的，一update就不行了。
比如，蘋果自從他出了airpod，藍牙耳機就開始問題越來越多。
【在 g****t 的大作中提到】
: 你有用Bluetooth 嗎？我幾日前買了一組google router自用。第一次上電時，
: bluetooth連手機app。看著過程平順，強壯，堪稱優秀設計。
: 這些邊界情況，看著不起眼，但設計好頗為不易。
:
:
: 那家人如果有个symmetrical firewall，又拒绝设置port forwarding，
: 难道我
: 不让他
:
: 们用？
:
: cost也不高，控制灯和空调，每天流量几百byte。倒是heartbeat每分钟
: 有16
|
T********i
发帖数: 2416 | 39 这些标准，仔细看简直不能再烂。
我宁可我的产品没人用，也不会去昧着良心用Zigbee。宁可自己写一个。
因为，那是Right thing to do!
将来，我的协议会兼容Zigbee，但是那是第二优先级，二等公民。而不是反过来。
很多事，我要是不做，这辈子都不会有人做。我感觉的是一种urge!
【在 n******t 的大作中提到】
: bluetooth的兼容性是個大問題。可能現在好好的，一update就不行了。
: 比如，蘋果自從他出了airpod，藍牙耳機就開始問題越來越多。
|
w********m
发帖数: 1137 | |
|
|
T********i
发帖数: 2416 | 41 不管你咋穿透，都要设置port forwarding。
我是自己的穿透协议。因为要两套密钥才能端到端加密。
转发服务器只有转发密钥。仍然不知道转发的内容。
I don't want to know anything about you!
【在 w********m 的大作中提到】
: 内网穿透
: 或者ipsec
|
y****w
发帖数: 3747 | 42 需要设置很小的TTL，最好1s（你的dyndns服务还未必允许你改，一般他们也就给1分钟
而已），强迫你的用户每次都去authorative dns server拿dns结果。 所以好的
dyndns一定会收费. 但这个对你的产品来说基本不太可行，你让用户干这个基本就是自
绝于用户，可以当选项但绝不能当需要。
你的客户端（设备），服务(用户数据点）， 控制设备（手机电脑）其实本质上都是客
户端。 外网弄一个有固定ip的server当掮客或者代理把他们连起来。 尤其是你提到你
的数据量并不大。 中间服务器不需要知道加密传输的内容。
【在 T********i 的大作中提到】
: 不管你咋穿透，都要设置port forwarding。
: 我是自己的穿透协议。因为要两套密钥才能端到端加密。
: 转发服务器只有转发密钥。仍然不知道转发的内容。
: I don't want to know anything about you!
|
T********i
发帖数: 2416 | 43 看这篇就可以了：
http://www.mitbbs.com/article/Programming/31580375_0.html
我的service架构，不需要dyndns。
1. 外部IP改变，10秒以内保证更新。
2. 用户设置了port forward，就走port forward。否则代理转发
3. port forward设置错了，或者任何时候port forward被关闭了，10秒以内切换到代
理模式。
用户客户端无论如何都能连接，port forward还是代理还是任何改变都能自动发现。
如果port forward设置正确一切不变，service不会为了维持服务产生任何额外流量。
【在 y****w 的大作中提到】
: 需要设置很小的TTL，最好1s（你的dyndns服务还未必允许你改，一般他们也就给1分钟
: 而已），强迫你的用户每次都去authorative dns server拿dns结果。 所以好的
: dyndns一定会收费. 但这个对你的产品来说基本不太可行，你让用户干这个基本就是自
: 绝于用户，可以当选项但绝不能当需要。
: 你的客户端（设备），服务(用户数据点）， 控制设备（手机电脑）其实本质上都是客
: 户端。 外网弄一个有固定ip的server当掮客或者代理把他们连起来。 尤其是你提到你
: 的数据量并不大。 中间服务器不需要知道加密传输的内容。
|
l*********s
发帖数: 5409 | |
