手上有一华为的机器，虽然还没坏，但只能一直用4.0的android，确实伤脑筋

tr069本身就是未来远程管理的，不会抓取隐私的。

安全性做的比较好，可以支持https，除非DNS拦截，你还能有什么招？

android根本没有禁止的机会

貌似是连夜更新了，态度还是不错，至少没有抵赖，国内公司这样已经很厚道了。


哈哈，笑死。苏州难得有个公司，却要先修炼品行，可惜。

@est Neato哪一款？ irobot也很多人推荐，但是都在3k以上了。

@viator42 不是有千把块的机器人么？传感器也有贵有便宜。

@zts1993 是的。

机器人的技术会大量开源，而且已经有不少开源技术了，这是个方向，不是你愿意不愿意的。

@konakona dfrobot社区不错，研究研究。不过对硬件不太懂。

这种直接http不加密，而且只传一个key进行标识APP的API，简直就是为开发者设定的地雷，随随便便就能把你的账单刷爆。

使用juhe的开发者小心了。

可以来苏州
虽然有时候污染也严重

这个好

不是不可以，比如我

我可不可以说，lz一些基础都没搞清楚吗？http和html的关系?

HTTP足够了，做成RESTful API

@canesten
@tjmao
@CMGS

最新进展，找了一台物理机，8核，8Gb CentOS，客户端：i5 2.4Mhz, 8Gb

内核参数：
fs.file-max = 999999
net.ipv4.tcp_rmem = 4096 4096 16777216
net.ipv4.tcp_wmem = 4096 4096 16777216
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 4096
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_tw_buckets = 360000
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_synack_retries = 2



[root@sz-monitor ~]# ulimit -n
1000000
[root@sz-monitor ~]# ulimit -Sn
1000000
[root@sz-monitor ~]# ulimit -Hn
1000000


并发10000，ab -n 5000000 -c 10000
Requests per second: 70806.95 [#/sec] (mean)
Time per request: 141.229 [ms] (mean)
Time per request: 0.014 [ms] (mean, across all concurrent requests)
Transfer rate: 5255.20 [Kbytes/sec] received


网卡的速度
05:16:19 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
05:16:24 PM lo 0.20 0.20 0.10 0.10 0.00 0.00 0.00
05:16:24 PM eth0 147588.73 75031.99 14179.64 10316.23 0.00 0.00 0.00

rxkB/s 14179.64
txkB/s 10316.23

CPU在200%-400%左右
内存在3.5%左右

正常速度70806.95/s，离400000/s差距甚远啊

@canesten 不是PC上的虚拟机，是母鸡上划出来的。

找了个ucloud机器，4核，16Gb，C10K， 2.5w+/s，cpu 120%，mem:3.5%

@dndx 简单的文本协议（私有），使用\n作为结束符号。C10k问题不大，主要是处理速度，没达到10w+/s


@canesten 请教下，怎么你用哪个测试工具测试的，有没有推荐的？我使用的是修改后的ab程序

@canesten 内核调过，虚拟机服务器下，C10K下只有1w+/s，网卡没仔细观察，再测试一下看看。

@clino
@lsylsy2 openresty 难道是用的姿势不对？没netty高。

@canesten i5 2.4GHz, 8G, 并发是10K下的50w/s? 我测下来,并发1000,在6w+/s，和你差距好大；


@mengskysama 暂时是想找找有没现成的方案，nginx可能不适合这种长链接的案例？

@canesten 需要存到后端MQ中去，当然可以暂时不考虑存储，3-4之间，接收后直接返回，暂不考虑耗时问题。