N*****m
发帖数: 42603 | 1 现在哪个是最好的push framework？
比如说能够轻松从1万个用户scale到1百万个用户 |
z****e
发帖数: 54598 | |
N*****m
发帖数: 42603 | 3 认真讨论，别捣蛋
【在 z****e 的大作中提到】
: 多push几次，人家连app都给卸载了
|
h******b
发帖数: 6055 | 4 建议parse, 成熟后台和api，脸书收购的公司，为了移动量身打造。 糙快猛的极致。
高中生拿parse搞了个千万下载的在线游戏。
而且初始阶段完全免费，等你流量需要付钱的时候，你已经不用上这个板块了。 |
d*******r
发帖数: 3299 | 5 解释下 push framework 是干啥的, 为啥需要 |
l**********n
发帖数: 8443 | 6 和real time server啥区别？
【在 N*****m 的大作中提到】
: 现在哪个是最好的push framework？
: 比如说能够轻松从1万个用户scale到1百万个用户
|
l**********n
发帖数: 8443 | 7 node websocket？
【在 l**********n 的大作中提到】
: 和real time server啥区别？
|
d*******r
发帖数: 3299 | 8 是指这样的 message service 吗?
https://pusher.com/ |
N*****m
发帖数: 42603 | 9 对，自己搞一个怎么搞？
【在 d*******r 的大作中提到】
: 是指这样的 message service 吗?
: https://pusher.com/
|
N*****m
发帖数: 42603 | 10 差不太多
主要是单向，server到client
【在 l**********n 的大作中提到】
: 和real time server啥区别？
|
|
|
N*****m
发帖数: 42603 | 11 websocket想过，不过有安全问题的顾虑
【在 l**********n 的大作中提到】
: node websocket？
|
l**********n
发帖数: 8443 | |
W***o
发帖数: 6519 | 13 这种做法有点像“强奸”哦，不管用户是否需要，都要给
【在 N*****m 的大作中提到】
: 差不太多
: 主要是单向，server到client
|
N*****m
发帖数: 42603 | 14 当然是用户注册/关注了
【在 W***o 的大作中提到】
: 这种做法有点像“强奸”哦，不管用户是否需要，都要给
|
N*****m
发帖数: 42603 | 15 这个是node+websocket，楼上说过了
【在 l**********n 的大作中提到】
: sails.js
|
W***o
发帖数: 6519 | 16 好奇楼主最后选择用什么push framework了
我最近打算从Parse迁移出来自己做个后台，想趁着改起来的成本不大的时候马上纠正
一下, 刚看到了这个 https://github.com/mqttjs/MQTT.js 应该可以镶嵌到express.
js用作push framework
【在 N*****m 的大作中提到】
: 现在哪个是最好的push framework？
: 比如说能够轻松从1万个用户scale到1百万个用户
|
f*******t
发帖数: 7549 | |
s******s
发帖数: 3694 | 18 打算定制？
【在 f*******t 的大作中提到】
: parse收费那么便宜，你们为啥要自己做平台
|
z****e
发帖数: 54598 | 19
有iaas便宜吗？
【在 f*******t 的大作中提到】
: parse收费那么便宜，你们为啥要自己做平台
|
f*******t
发帖数: 7549 | 20 恐怕比你直接买aws host便宜，更别说写framework的人工了
【在 z****e 的大作中提到】
:
: 有iaas便宜吗？
|
|
|
s******s
发帖数: 3694 | 21 不知道您的问题是什么， 需要用在什么地方？
MQTT 是一个轻量级的推送库，目前微处理器等智能家居产品上用的很多，不过安全问
题好像考虑的不是太多。 现在几家主流的 IoT平台都是在用这个。
另外一个Ejabber/XMPP中的推送模块，支持OTR, 安全机制看起来是目前最好的，客户
端主要是手机等。
【在 N*****m 的大作中提到】
: 现在哪个是最好的push framework？
: 比如说能够轻松从1万个用户scale到1百万个用户
|
g*****g
发帖数: 34805 | 22 我觉得做大了在考虑 iaas还是对的，早期快糙猛最重要。
【在 f*******t 的大作中提到】
: 恐怕比你直接买aws host便宜，更别说写framework的人工了
|
z****e
发帖数: 54598 | 23
用vert.x就很容易，web其实就那点东西，很容易搞
而且有些paas巨难用，比如gae
【在 f*******t 的大作中提到】
: 恐怕比你直接买aws host便宜，更别说写framework的人工了
|
W***o
发帖数: 6519 | 24 发现一个例子，把vert.x 镶嵌到Spring mvc里做push notifications，明天试试
【在 z****e 的大作中提到】
:
: 用vert.x就很容易，web其实就那点东西，很容易搞
: 而且有些paas巨难用，比如gae
|
z****e
发帖数: 54598 | 25
spring mvc能做的，vert.x都能做
你没有必要带上spring还有tomcat/jetty这些一起
有些太heavy了，虽然不是很难做
push notification只要找到合适的轮子就可以用了
其实就是xmpp的一个东西，网络上很多
【在 W***o 的大作中提到】
: 发现一个例子，把vert.x 镶嵌到Spring mvc里做push notifications，明天试试
|
z****e
发帖数: 54598 | 26 apns麻烦点
xmpp完全就是一个公开的协议，随便你搞 |
s******s
发帖数: 3694 | 27 还是那句话，取决于应用。
【在 z****e 的大作中提到】
: apns麻烦点
: xmpp完全就是一个公开的协议，随便你搞
|
z****e
发帖数: 54598 | 28
vert.x已经很糙快猛了
关键是有些paas比iaas还恶心
iaas只要是对linux稍微有点感觉的
一般都没啥问题，而且还有juju这种傻瓜化的ui界面
不比paas强？paas基本上都是做炮灰的
【在 g*****g 的大作中提到】
: 我觉得做大了在考虑 iaas还是对的，早期快糙猛最重要。
|
s******s
发帖数: 3694 | 29 APNs, Google push notification 一个很大的问题还是受制于人。大规模商业应用（
比如上百万设备的），APNs的延时很多时候多则两分钟，少则20秒
【在 z****e 的大作中提到】
: apns麻烦点
: xmpp完全就是一个公开的协议，随便你搞
|
f*******t
发帖数: 7549 | 30 parse push主要做的是往db送query，再分别向apns和gcm等push service发消息。自己
写这些既没技术含量又有很多特别trivial的问题要解决，吃力不讨好。
ios不允许background service，android 6.0也开始限制，自己做push service基本没
有可行性。 |
|
|
s******s
发帖数: 3694 | 31 现在的这些聊天的 wechat/momo咋搞的？
【在 f*******t 的大作中提到】
: parse push主要做的是往db送query，再分别向apns和gcm等push service发消息。自己
: 写这些既没技术含量又有很多特别trivial的问题要解决，吃力不讨好。
: ios不允许background service，android 6.0也开始限制，自己做push service基本没
: 有可行性。
|
f*******t
发帖数: 7549 | 32 wechat不用说了，腾讯钱多，自然要自己做一套，android background service里加一
些代码而已。
momo咋搞的不知道。国内也有一些SDK可以做push notification，不过还是有很多国内
app用parse，毕竟便宜，另外运行在AWS上暂时没被墙。
聊天比较注重latency和consistency，所以我还没发现哪个聊天工具用parse。
【在 s******s 的大作中提到】
: 现在的这些聊天的 wechat/momo咋搞的？
|
H**********2
发帖数: 107 | 33 聊天主要是XMPP，协议什么都给你设计好了，而且有大把开源的server和client可以用
。 |
z****e
发帖数: 54598 | 34 这个东西延时应该没关系吧？
应该没有人会追求这种东西的即时性
【在 s******s 的大作中提到】
: APNs, Google push notification 一个很大的问题还是受制于人。大规模商业应用（
: 比如上百万设备的），APNs的延时很多时候多则两分钟，少则20秒
|
g*****g
发帖数: 34805 | 35 看啥应用，messenger就要求很高。
【在 z****e 的大作中提到】
: 这个东西延时应该没关系吧？
: 应该没有人会追求这种东西的即时性
|
z****e
发帖数: 54598 | 36
xmpp就是典型的
tcp+http+xml，这三层压下去，基本上黄花菜都凉了
如果是自己做的话，直接udp就好了，反正丢掉包无所谓
聊天的话，完全可以牺牲msg质量以保证时效的
我最早在大学做的一个聊天室就是udp
【在 g*****g 的大作中提到】
: 看啥应用，messenger就要求很高。
|
g*****g
发帖数: 34805 | 37 视频音频可以，text不行的。
【在 z****e 的大作中提到】
:
: xmpp就是典型的
: tcp+http+xml，这三层压下去，基本上黄花菜都凉了
: 如果是自己做的话，直接udp就好了，反正丢掉包无所谓
: 聊天的话，完全可以牺牲msg质量以保证时效的
: 我最早在大学做的一个聊天室就是udp
|
z****e
发帖数: 54598 | 38
可以吧，做个序列编号
然好客户端接收的时候自动验证一下序列号是否完整就好了
这种算法我们大学时候都写过
其实跟星际联机时候很像
星际的udp应该也是基于同样的方式
【在 g*****g 的大作中提到】
: 视频音频可以，text不行的。
|
m***i
发帖数: 2480 | 39 push的一般答案是xmpp notify,然后client HTTPS pull
【在 N*****m 的大作中提到】
: 现在哪个是最好的push framework？
: 比如说能够轻松从1万个用户scale到1百万个用户
|
k**n
发帖数: 3989 | 40 觉得client pull这样很合理...直接push over 有时是费力不讨好,
但是有时clients 方有问题时有时还是需push over..
【在 m***i 的大作中提到】
: push的一般答案是xmpp notify,然后client HTTPS pull
|
|
|
x*******6
发帖数: 262 | 41 如果用xmpp的话为什么还要特地去做个push framework？不是本来就用的长连接来接受
信息吗？ |
l***p
发帖数: 358 | 42 竟然没有人提HTTP2？born for server push，websocket？firework 穿得过再来说 |
