m*****n
发帖数: 3575 | 1 有人说websocket纯粹就是为了纠正http把tcp缩编成客户问服务器答的缺陷而找补的
又有人说websocket是比tcp多了一层标记消息自动分包的协议
还有人说websocket是异步的，而tcp是同步的
前两个肯定都对，我的问题在第三者是否正确？
如果正确，是不是说明websocket可以在底层换用其它的tcp通路？
那么这是否说明websocket能用分布式的网路传输cdn，而普通tcp做不到？
我知道MultiPath TCP就是多路TCP，改成异步了，因为多路不可能保证包到达的时间完
全按顺序。
这是否暗示了普通TCP就是单路且同步传输的？
我推理这样TCP是绝对不可能在网络拥塞时换条线路进行传输的，因为是单路固定好的
？ |
T********i
发帖数: 2416 | |
m*****n
发帖数: 3575 | 3 魏老师，你好！
我现在要做一个向客户端推送行情的服务
http肯定是不合适的
现在有两个软件开发商
一个说用TCP好，简单直接
另一个说Websocket好，更先进好用
请问如果你做选择，选择哪个？
【在 T********i 的大作中提到】
: 你不要挖坟了，自己读一下spec啥都有了。
: https://tools.ietf.org/html/rfc6455
|
T********i
发帖数: 2416 | 4 我会三个都实现一遍。这样才能穿透最厉害的防火墙。
【在 m*****n 的大作中提到】
: 魏老师，你好！
: 我现在要做一个向客户端推送行情的服务
: http肯定是不合适的
: 现在有两个软件开发商
: 一个说用TCP好，简单直接
: 另一个说Websocket好，更先进好用
: 请问如果你做选择，选择哪个？
|
m*****n
发帖数: 3575 | 5 如果只能用一个呢？
【在 T********i 的大作中提到】
: 我会三个都实现一遍。这样才能穿透最厉害的防火墙。
|
T********i
发帖数: 2416 | 6 照理说websocket好一些。这里边变量太多。比如你的技术路线选择，客户需求，目标
平台等等。。。
【在 m*****n 的大作中提到】
: 如果只能用一个呢？
|
m*****n
发帖数: 3575 | 7 就是每秒向各客户各推一个按照行情生成的策略数据包，可能有上千个数那种，不会上万
这个服务是金融行情服务，因此非常的讨厌延迟，需要网络稳定可靠
还要加密，因为是客户订制策略，不想让其它人知道
客户那里用客户端
我最近还听说cdn还会提速
好像cdn并不直接支持普通TCP
所以可能还是websocket
【在 T********i 的大作中提到】
: 照理说websocket好一些。这里边变量太多。比如你的技术路线选择，客户需求，目标
: 平台等等。。。
|
m*****n
发帖数: 3575 | |
p***o
发帖数: 1252 | 9 每秒推送 vs 讨厌延迟, 这两个是怎么拼到一起的...
上万
【在 m*****n 的大作中提到】
: 就是每秒向各客户各推一个按照行情生成的策略数据包，可能有上千个数那种，不会上万
: 这个服务是金融行情服务，因此非常的讨厌延迟，需要网络稳定可靠
: 还要加密，因为是客户订制策略，不想让其它人知道
: 客户那里用客户端
: 我最近还听说cdn还会提速
: 好像cdn并不直接支持普通TCP
: 所以可能还是websocket
|
T********i
发帖数: 2416 | 10 这玩意儿是给人看的和给机器看的，要求完全不一样。
给人看的就是骗人眼睛，什么延迟之类都是扯淡。
给机器看的，每秒推送和讨厌延迟是矛盾的。你要有个指标才行。我做过的系统延迟都
是个位数微秒。1微秒是百万分之一秒。
这两种系统实现完全不一样。给人看的，你的flow control要做好。 |
|
|
m*****n
发帖数: 3575 | 11 讨厌延迟，是那种无理由莫名其妙的卡顿
每秒推送，就是稳定的每秒能收到刷新数据
这个不矛盾
我是指讨厌由于网络拥塞那种一下卡十秒的延迟
我给客户只要把延迟压缩在1秒以内，而且刷新非常稳定，就算过关
不要求特别高的实时性
【在 T********i 的大作中提到】
: 这玩意儿是给人看的和给机器看的，要求完全不一样。
: 给人看的就是骗人眼睛，什么延迟之类都是扯淡。
: 给机器看的，每秒推送和讨厌延迟是矛盾的。你要有个指标才行。我做过的系统延迟都
: 是个位数微秒。1微秒是百万分之一秒。
: 这两种系统实现完全不一样。给人看的，你的flow control要做好。
|
m*****n
发帖数: 3575 | 12 我指的延迟特指故障
例如一下卡十秒，等不到刷新消息
或者默默的掉线了，而等了很久都没发现
【在 p***o 的大作中提到】
: 每秒推送 vs 讨厌延迟, 这两个是怎么拼到一起的...
:
: 上万
|
T********i
发帖数: 2416 | 13 告诉你的办法：
1. 假定用户只需要最新的数据，价格，信号。。。
2. 每个连接每次只传输更新过的数据
3. 用户收到每个批次更新以后，要发送一个ACK消息
4. 发送方只有收到ACK消息以后，才发送下一批
5. 发送方可以人为增加延迟（比如最长间隔1s），这样会节约一些带宽。但是不能硬
发送。只能等收到ACK再送下一批
6. 这个方法是自适应的。而且是best effort。不能做的比这个更好了 |
T********i
发帖数: 2416 | 14 7. 忘了说了，发送方设置最大延迟，超时如果没有更新，也要发个heart beat。接收
方2 X MAX_TO没收到任何消息就重连接 |
g****t
发帖数: 31659 | 15 他这个就是典型的你说的骗人眼睛的吧。高速传数据。网络条件好的时候多穿点cache
起来。然后本地慢速刷新。这样就骗过去了。
这样可以吗？我拍脑袋想的。
: 7. 忘了说了，发送方设置最大延迟，超时如果没有更新，也要发个heart
beat
。接收
: 方2 X MAX_TO没收到任何消息就重连接
【在 T********i 的大作中提到】
: 7. 忘了说了，发送方设置最大延迟，超时如果没有更新，也要发个heart beat。接收
: 方2 X MAX_TO没收到任何消息就重连接
|
T********i
发帖数: 2416 | 16 抱歉，拍脑袋想的不是很对。
就是总是传最新的状态，网络条件好的时候，可以传快点；条件不好，就慢点，丢几个
更新就丢了，最新的价格才最重要。
就算网络条件再好，传太快了也没啥用。1微秒一个更新，和100毫秒一个更新，差10万
倍，对人有区别么？没有。所有可以适当限速。
客户端要有办法知道网络不好了，别傻等，要及时重连接。
cache
【在 g****t 的大作中提到】
: 他这个就是典型的你说的骗人眼睛的吧。高速传数据。网络条件好的时候多穿点cache
: 起来。然后本地慢速刷新。这样就骗过去了。
: 这样可以吗？我拍脑袋想的。
:
:
: 7. 忘了说了，发送方设置最大延迟，超时如果没有更新，也要发个heart
: beat
: 。接收
:
: 方2 X MAX_TO没收到任何消息就重连接
:
|
g****t
发帖数: 31659 | 17
我的意思是说。他的要求不是防止卡死吗。
那就确保1秒钟都有更新。别管是什数了。
例如你cache里面有100个数。
每次只显示第一个数。卡死的时候显示第二个。
来个假更新。好过让客户等。
【在 T********i 的大作中提到】
: 抱歉，拍脑袋想的不是很对。
: 就是总是传最新的状态，网络条件好的时候，可以传快点；条件不好，就慢点，丢几个
: 更新就丢了，最新的价格才最重要。
: 就算网络条件再好，传太快了也没啥用。1微秒一个更新，和100毫秒一个更新，差10万
: 倍，对人有区别么？没有。所有可以适当限速。
: 客户端要有办法知道网络不好了，别傻等，要及时重连接。
:
: cache
|
T********i
发帖数: 2416 | 18 假更新那是祸害用户啊。要是用户用假价钱下单，有了损失，可能会让你赔钱。
我的算法是如果用户带宽足够，保证能够及时得到数据，甚至最大延迟都能保证不超过。
如果带宽不够，那也能得到更新，延迟要大一点，但是也没办法。而且更新保证是在有
限的带宽下能拿到的最新的数据了。
即使用户的带宽只剩下需要带宽的1%。那么可能用户得到的数据是100秒以前的。但是
没办法，谁让你带宽低呢？有数据就不错了。反正我们尽力了。We took best effort
...
【在 g****t 的大作中提到】
:
: 我的意思是说。他的要求不是防止卡死吗。
: 那就确保1秒钟都有更新。别管是什数了。
: 例如你cache里面有100个数。
: 每次只显示第一个数。卡死的时候显示第二个。
: 来个假更新。好过让客户等。
|
w********m
发帖数: 1137 | 19 最近在搞Websocket。
这玩意不是request/response model. 收不收到信息不确定。这样就麻烦了。
就是一个http的长链接，http的缺点全都有。
推荐grpc。基于http2，安全高速。 |
T********i
发帖数: 2416 | 20 这个行业里，最恶心的就是那些所谓引领行业的人都是脑袋里面进了屎。
这个世界是基于消息的（message），不是基于request/response的。把啥烂玩意儿都
做成request/response还能振振有词去吹牛扯淡，不是无知，而是无耻了。
这帮孙子挖个烂坑让你们都跳进去。然后就他们手里有点奇货可居了。
【在 w********m 的大作中提到】
: 最近在搞Websocket。
: 这玩意不是request/response model. 收不收到信息不确定。这样就麻烦了。
: 就是一个http的长链接，http的缺点全都有。
: 推荐grpc。基于http2，安全高速。
|
|
|
f******2
发帖数: 2455 | 21 魏老师请深入介绍一下grpc/http2 （可以streaming消息）在这个场景下的问题
https://stackoverflow.com/questions/46904674/what-is-difference-between-grpc
-and-websocket-which-one-is-more-suitable-for-bi
: 这个行业里，最恶心的就是那些所谓引领行业的人都是脑袋里面进了屎。
: 这个世界是基于消息的（message），不是基于request/response的。把
啥烂玩
意儿都
: 做成request/response还能振振有词去吹牛扯淡，不是无知，而是无耻了。
: 这帮孙子挖个烂坑让你们都跳进去。然后就他们手里有点奇货可居了。
【在 T********i 的大作中提到】
: 这个行业里，最恶心的就是那些所谓引领行业的人都是脑袋里面进了屎。
: 这个世界是基于消息的（message），不是基于request/response的。把啥烂玩意儿都
: 做成request/response还能振振有词去吹牛扯淡，不是无知，而是无耻了。
: 这帮孙子挖个烂坑让你们都跳进去。然后就他们手里有点奇货可居了。
|
m*****n
发帖数: 3575 | 22 我看官方文档
声明它不是http只是兼容http使用其接口而已
本质是tcp，不过专门对消息传输做了优化
【在 w********m 的大作中提到】
: 最近在搞Websocket。
: 这玩意不是request/response model. 收不收到信息不确定。这样就麻烦了。
: 就是一个http的长链接，http的缺点全都有。
: 推荐grpc。基于http2，安全高速。
|
m*****n
发帖数: 3575 | 23 谢谢魏老师
我还是选Websocket那家算了
用现成的久经考验的技术更可靠一些
用TCP那家原来只做过内网，太冒险了 |
c*******v
发帖数: 2599 | 24 我是这样想的。他把不要卡死看的很重要。但是网络连接本身有不确定性。
所以更新必然不能直接和网络连接的不确定性脱钩。所以cache似乎是一个逻辑结果。
这个男盗女娼的世界，我觉得楼主最后会cache,假更新的。
如果条件允许，楼主别忘了产品release后来说说看。
过。
effort
【在 T********i 的大作中提到】
: 假更新那是祸害用户啊。要是用户用假价钱下单，有了损失，可能会让你赔钱。
: 我的算法是如果用户带宽足够，保证能够及时得到数据，甚至最大延迟都能保证不超过。
: 如果带宽不够，那也能得到更新，延迟要大一点，但是也没办法。而且更新保证是在有
: 限的带宽下能拿到的最新的数据了。
: 即使用户的带宽只剩下需要带宽的1%。那么可能用户得到的数据是100秒以前的。但是
: 没办法，谁让你带宽低呢？有数据就不错了。反正我们尽力了。We took best effort
: ...
|
n******t
发帖数: 4406 | 25 這是用TCP沒point啊。
上万
【在 m*****n 的大作中提到】
: 就是每秒向各客户各推一个按照行情生成的策略数据包，可能有上千个数那种，不会上万
: 这个服务是金融行情服务，因此非常的讨厌延迟，需要网络稳定可靠
: 还要加密，因为是客户订制策略，不想让其它人知道
: 客户那里用客户端
: 我最近还听说cdn还会提速
: 好像cdn并不直接支持普通TCP
: 所以可能还是websocket
|
c******o
发帖数: 1277 | 26 刚觉这个就是一切都好了，就差一个编程的。。
什么技术的都没计划呢， 也不是很清楚到底需要多大努力。。 |
m*****n
发帖数: 3575 | 27 少说风凉话
要不是我们这些提需求的
养得起码工全国第一高薪？
【在 c******o 的大作中提到】
: 刚觉这个就是一切都好了，就差一个编程的。。
: 什么技术的都没计划呢， 也不是很清楚到底需要多大努力。。
|
m*****n
发帖数: 3575 | 28 没听懂
你是说应该用TCP
还是说不应该用TCP？
【在 n******t 的大作中提到】
: 這是用TCP沒point啊。
:
: 上万
|
s**d
发帖数: 258 | 29 没看懂
request/response 说白了不也是消息？只是说这个模型能确认消息是否送达
【在 T********i 的大作中提到】
: 这个行业里，最恶心的就是那些所谓引领行业的人都是脑袋里面进了屎。
: 这个世界是基于消息的（message），不是基于request/response的。把啥烂玩意儿都
: 做成request/response还能振振有词去吹牛扯淡，不是无知，而是无耻了。
: 这帮孙子挖个烂坑让你们都跳进去。然后就他们手里有点奇货可居了。
|
m*****n
发帖数: 3575 | 30 为了不卡死
我还打算上cdn呢
不可能假更新啊，因为行情是交易所品种的行情，别人随便开个别的软件都能看见，造
假行情不是作死吗？
【在 c*******v 的大作中提到】
: 我是这样想的。他把不要卡死看的很重要。但是网络连接本身有不确定性。
: 所以更新必然不能直接和网络连接的不确定性脱钩。所以cache似乎是一个逻辑结果。
: 这个男盗女娼的世界，我觉得楼主最后会cache,假更新的。
: 如果条件允许，楼主别忘了产品release后来说说看。
:
: 过。
: effort
|
|
|
m*****n
发帖数: 3575 | 31 这个模型最垃圾的就是request只能由客户端发起
要不是这么恶心也不会再出一个Websocket
【在 s**d 的大作中提到】
: 没看懂
: request/response 说白了不也是消息？只是说这个模型能确认消息是否送达
|
c*******v
发帖数: 2599 | 32 你没听懂我的意思。
假设你有个cache堆栈，存之前的100个数。
正常情况下，T=1的时候你报这100个数的平均值。
那么网络断了，T=2的时候你发现cache 堆栈里面只有50个数更新了。
另外50个数是之前一秒的。
那么这时候你选择不更新，停在那里。
还是选择照样给出cache堆栈里的平均值(尽管cache里面有50个数是原来的。)?
你的需求不一定要选择cache。但这个办法我认为是一种有效的选项。
你用机器学习做预测那些missing values也是可以的。我不是在开玩笑
这样玩下去是无穷无尽的。
把要求报一个数，变成一个cache，变成cache的cache。
实际上是在用尽需求的边界。
【在 m*****n 的大作中提到】
: 为了不卡死
: 我还打算上cdn呢
: 不可能假更新啊，因为行情是交易所品种的行情，别人随便开个别的软件都能看见，造
: 假行情不是作死吗？
|
w********m
发帖数: 1137 | 33 你按着魏总的说法做一遍就可以了，他是权威，说的都对。
meteor.js就是websocket的model，丢数据丟的都习惯了。
所以，你得逐渐往websocket加ack，heartbeat，message queue。还要加密，压缩，上
ssl什么的。
websocket除了javascript，其他语言的库都不太好，你不会用js写client吧。
这样工作量就上去了。最后估计跟http差不多。
狗厂是个大evil，花钱买断了最好的码仔。你不喜欢就跟着混好了。 |
m*****n
发帖数: 3575 | 34 刷新包是整体发送的，在Websocket里面是一个消息
你说的这个情况比较极端，就是收一点刷新一点
那这种玩法必须用TCP，自己写协议才办得到
但是自己用TCP写协议，就要重新处理很多Websocket已经解决的问题
现在你的意见是TCP上自写协议好，还是用现成的Websocket好？
【在 c*******v 的大作中提到】
: 你没听懂我的意思。
: 假设你有个cache堆栈，存之前的100个数。
: 正常情况下，T=1的时候你报这100个数的平均值。
: 那么网络断了，T=2的时候你发现cache 堆栈里面只有50个数更新了。
: 另外50个数是之前一秒的。
: 那么这时候你选择不更新，停在那里。
: 还是选择照样给出cache堆栈里的平均值(尽管cache里面有50个数是原来的。)?
: 你的需求不一定要选择cache。但这个办法我认为是一种有效的选项。
: 你用机器学习做预测那些missing values也是可以的。我不是在开玩笑
: 这样玩下去是无穷无尽的。
|
w***g
发帖数: 5958 | 35 同意。要听老司机的话。
【在 w********m 的大作中提到】
: 你按着魏总的说法做一遍就可以了，他是权威，说的都对。
: meteor.js就是websocket的model，丢数据丟的都习惯了。
: 所以，你得逐渐往websocket加ack，heartbeat，message queue。还要加密，压缩，上
: ssl什么的。
: websocket除了javascript，其他语言的库都不太好，你不会用js写client吧。
: 这样工作量就上去了。最后估计跟http差不多。
: 狗厂是个大evil，花钱买断了最好的码仔。你不喜欢就跟着混好了。
|
T********i
发帖数: 2416 | 36 这个HTTP2 multiplex，我的理解，就是一个标准。把HTTP做成一个跛脚的双向协议。
这个协议仍然是无状态的。
首先，协议复杂无比，必然就需要各种框架，无状态，就需要各种中间件。这样便于控
制，大家都有事情做，也有利于阶级固化。
说什么WebSocket这个不好那个不好就是扯JB蛋了。HTTP2要是双向不但需要各种奇技淫
巧，而且也必须要保持长连接。而且要客户端刻意保持。关键是客户端JS根本他妈的就
不可能知道连接的状态，因为API只提供request/response。HTTP2 push只不过是反向
的request而已。
而且，现在连接都是TLS加密的，TLS握手完毕。中间的proxy根本不应该知道上面跑的
是websocket还是HTTP2。
grpc
【在 f******2 的大作中提到】
: 魏老师请深入介绍一下grpc/http2 （可以streaming消息）在这个场景下的问题
: https://stackoverflow.com/questions/46904674/what-is-difference-between-grpc
: -and-websocket-which-one-is-more-suitable-for-bi
:
:
: 这个行业里，最恶心的就是那些所谓引领行业的人都是脑袋里面进了屎。
:
: 这个世界是基于消息的（message），不是基于request/response的。把
: 啥烂玩
: 意儿都
:
: 做成request/response还能振振有词去吹牛扯淡，不是无知，而是无耻了。
:
: 这帮孙子挖个烂坑让你们都跳进去。然后就他们手里有点奇货可居了。
|
g****t
发帖数: 31659 | 37 我说的东西和用什么协议无关。跟老魏说的东西没有直接关系。是解决你说的卡死问题
的。
假设你要求的是每秒钟刷新。然后假设你的带宽在大多数情况下可以做到每秒传10个数。
那么把之前10个数求平均。我认为比你每秒从tcp或者websocket只接收一个数卡死的少
。代价是你要更多的接收数据。
这就是一个应用显示层的办法。利用你要求的刷新速度和带宽
的差，来提高robustness. 说穿了一钱不值，就是多次测量求平均好过一次。你连
cache都不需要，因为你还可以exponentially Moving average.
: 刷新包是整体发送的，在Websocket里面是一个消息
: 你说的这个情况比较极端，就是收一点刷新一点
: 那这种玩法必须用TCP，自己写协议才办得到
: 但是自己用TCP写协议，就要重新处理很多Websocket已经解决的问题
: 现在你的意见是TCP上自写协议好，还是用现成的Websocket好？
【在 m*****n 的大作中提到】
: 刷新包是整体发送的，在Websocket里面是一个消息
: 你说的这个情况比较极端，就是收一点刷新一点
: 那这种玩法必须用TCP，自己写协议才办得到
: 但是自己用TCP写协议，就要重新处理很多Websocket已经解决的问题
: 现在你的意见是TCP上自写协议好，还是用现成的Websocket好？
|
g****t
发帖数: 31659 | 38 如果你还听不懂，那我现在说个更直接的办法。
假设你已经搞定了每秒显示一个数，不管用什么办法和协议。
那么你用什么办法牺牲一些实时性换光滑？
很简单，求most recent 3秒你拿到的值的平均就可以了。
这样会造成正常情况下有1.5秒延时。
但是当你数字掉了的时候，不会卡死。因为自动就用之前的平均值代替了。
然后根据你的要求，你可以设计不同的加权平均。
: 我说的东西和用什么协议无关。跟老魏说的东西没有直接关系。是解决你
说的卡
死问题
: 的。
: 假设你要求的是每秒钟刷新。然后假设你的带宽在大多数情况下可以做到
每秒传
10个数。
: 那么把之前10个数求平均。我认为比你每秒从tcp或者websocket只接收一
个数卡
死的少
: 。代价是你要更多的接收数据。
: 这就是一个应用显示层的办法。利用你要求的刷新速度和带宽
: 的差，来提高robustness. 说穿了一钱不值，就是多次测量求平均好过一
次。你连
: cache都不需要，因为你还可以exponentially Moving average.
:
【在 g****t 的大作中提到】
: 我说的东西和用什么协议无关。跟老魏说的东西没有直接关系。是解决你说的卡死问题
: 的。
: 假设你要求的是每秒钟刷新。然后假设你的带宽在大多数情况下可以做到每秒传10个数。
: 那么把之前10个数求平均。我认为比你每秒从tcp或者websocket只接收一个数卡死的少
: 。代价是你要更多的接收数据。
: 这就是一个应用显示层的办法。利用你要求的刷新速度和带宽
: 的差，来提高robustness. 说穿了一钱不值，就是多次测量求平均好过一次。你连
: cache都不需要，因为你还可以exponentially Moving average.
:
:
: 刷新包是整体发送的，在Websocket里面是一个消息
|
s*i
发帖数: 5025 | 39 如果您不关心 IE 兼容性，可以考虑Server Send Event
: 魏老师，你好！
: 我现在要做一个向客户端推送行情的服务
: http肯定是不合适的
: 现在有两个软件开发商
: 一个说用TCP好，简单直接
: 另一个说Websocket好，更先进好用
: 请问如果你做选择，选择哪个？
【在 m*****n 的大作中提到】
: 刷新包是整体发送的，在Websocket里面是一个消息
: 你说的这个情况比较极端，就是收一点刷新一点
: 那这种玩法必须用TCP，自己写协议才办得到
: 但是自己用TCP写协议，就要重新处理很多Websocket已经解决的问题
: 现在你的意见是TCP上自写协议好，还是用现成的Websocket好？
|
m*****n
发帖数: 3575 | 40 那你的意思是websocket屁用不顶，还不如从tcp开始直接一点一点编？
我的客户端不用js，用标准的gui框架
【在 w********m 的大作中提到】
: 你按着魏总的说法做一遍就可以了，他是权威，说的都对。
: meteor.js就是websocket的model，丢数据丟的都习惯了。
: 所以，你得逐渐往websocket加ack，heartbeat，message queue。还要加密，压缩，上
: ssl什么的。
: websocket除了javascript，其他语言的库都不太好，你不会用js写client吧。
: 这样工作量就上去了。最后估计跟http差不多。
: 狗厂是个大evil，花钱买断了最好的码仔。你不喜欢就跟着混好了。
|
|
|
g****t
发帖数: 31659 | 41 老魏前面不是已经说了吗？"我会三个都实现一遍"
这个实际上有经验的人应该花不了太多功夫。带测试一周足够了。三个都实现一遍。
然后表示层再按我说的加点选项，把你的“可以延迟一秒”这个条件用上，用来增加
robustness margin。这样足够好了。
: 那你的意思是websocket屁用不顶，还不如从tcp开始直接一点一点编？
: 我的客户端不用js，用标准的gui框架
【在 m*****n 的大作中提到】
: 那你的意思是websocket屁用不顶，还不如从tcp开始直接一点一点编？
: 我的客户端不用js，用标准的gui框架
|
w********m
发帖数: 1137 | 42 我的意思是能抱大腿就抱大腿，不行就请魏总这种专家帮你做。
【在 m*****n 的大作中提到】
: 那你的意思是websocket屁用不顶，还不如从tcp开始直接一点一点编？
: 我的客户端不用js，用标准的gui框架
|
a****i
发帖数: 1182 | 43 每秒一个，用什么不行
http怎么了？处理不了每秒一个请求？一共几个客户吧
上万
【在 m*****n 的大作中提到】
: 就是每秒向各客户各推一个按照行情生成的策略数据包，可能有上千个数那种，不会上万
: 这个服务是金融行情服务，因此非常的讨厌延迟，需要网络稳定可靠
: 还要加密，因为是客户订制策略，不想让其它人知道
: 客户那里用客户端
: 我最近还听说cdn还会提速
: 好像cdn并不直接支持普通TCP
: 所以可能还是websocket
|
n******t
发帖数: 4406 | 44 UDP就行了啊。
發送方持續發送包的時候加上一個編號，接收方顯示當前一秒中收到的最新的包，一旦
顯示之前的都可以清掉。
當然也可以用tcp，不過這東西用流協議沒啥意義。
【在 m*****n 的大作中提到】
: 没听懂
: 你是说应该用TCP
: 还是说不应该用TCP？
|
d****r
发帖数: 300 | 45 你这个是video streaming 类似的做法，楼主要的是实时系统，需求不一样。
【在 g****t 的大作中提到】
: 老魏前面不是已经说了吗？"我会三个都实现一遍"
: 这个实际上有经验的人应该花不了太多功夫。带测试一周足够了。三个都实现一遍。
: 然后表示层再按我说的加点选项，把你的“可以延迟一秒”这个条件用上，用来增加
: robustness margin。这样足够好了。
:
:
: 那你的意思是websocket屁用不顶，还不如从tcp开始直接一点一点编？
:
: 我的客户端不用js，用标准的gui框架
:
|
g****t
发帖数: 31659 | 46 这是楼主说的：
我给客户只要把延迟压缩在1秒以内，而且刷新非常稳定，就算过关。
: 你这个是video streaming 类似的做法，楼主要的是实时系统，需求不一样。
【在 d****r 的大作中提到】
: 你这个是video streaming 类似的做法，楼主要的是实时系统，需求不一样。
|
m*****n
发帖数: 3575 | 47 我可能说的有误导
策略计算需要1秒时间
但传输显然不能花1秒
延迟得在1/10秒内
然后每隔1秒重传新数据
【在 g****t 的大作中提到】
: 这是楼主说的：
: 我给客户只要把延迟压缩在1秒以内，而且刷新非常稳定，就算过关。
:
:
: 你这个是video streaming 类似的做法，楼主要的是实时系统，需求不一样。
:
|
g****t
发帖数: 31659 | 48 你没做过软件产品吧？
客户希望看到的，或者你希望客户看到的东西，最好和实现分开。
每隔1秒重传新数据，这条属于实现。
你这几个数字不简单。建议你找个以前做过软件产品的把tech spec
写好。不然我预感你后面会出大麻烦。
分条分块做不好，后面就是无尽的软件工程师和系统工程师扯皮。
【在 m*****n 的大作中提到】
: 我可能说的有误导
: 策略计算需要1秒时间
: 但传输显然不能花1秒
: 延迟得在1/10秒内
: 然后每隔1秒重传新数据
|
T********i
发帖数: 2416 | |
m*****n
发帖数: 3575 | 50 我一句都没扯到前端啊
我说的是后端在传输能力方面的要求
问的也是这方面
至于计算和用户界面，当然不用你们想
【在 g****t 的大作中提到】
: 你没做过软件产品吧？
: 客户希望看到的，或者你希望客户看到的东西，最好和实现分开。
: 每隔1秒重传新数据，这条属于实现。
: 你这几个数字不简单。建议你找个以前做过软件产品的把tech spec
: 写好。不然我预感你后面会出大麻烦。
: 分条分块做不好，后面就是无尽的软件工程师和系统工程师扯皮。
|
|
|
c*******v
发帖数: 2599 | 51 楼主最后怎么实现的？
我写了个简单的redis proxy。下一步就是这贴里说的机器学习放进去。
【在 m*****n 的大作中提到】
: 有人说websocket纯粹就是为了纠正http把tcp缩编成客户问服务器答的缺陷而找补的
: 又有人说websocket是比tcp多了一层标记消息自动分包的协议
: 还有人说websocket是异步的，而tcp是同步的
: 前两个肯定都对，我的问题在第三者是否正确？
: 如果正确，是不是说明websocket可以在底层换用其它的tcp通路？
: 那么这是否说明websocket能用分布式的网路传输cdn，而普通tcp做不到？
: 我知道MultiPath TCP就是多路TCP，改成异步了，因为多路不可能保证包到达的时间完
: 全按顺序。
: 这是否暗示了普通TCP就是单路且同步传输的？
: 我推理这样TCP是绝对不可能在网络拥塞时换条线路进行传输的，因为是单路固定好的
|
x****u
发帖数: 44466 | 52 说个题外的话
你们写论文，如果发现一个神奇的，前人从未想到过的，颠覆性的点子，首先是质疑还
是把它做出来？为什么到了写程序的时候非要直接上来就造轮子啊。
【在 c*******v 的大作中提到】
: 楼主最后怎么实现的？
: 我写了个简单的redis proxy。下一步就是这贴里说的机器学习放进去。
|
g****t
发帖数: 31659 | 53 个人经验：
一般情况下，开始试验验证的第一天就会淘汰90%的idea。然后检查，重复，不停的折
腾这10%。最后剩下1%有用的东西。这1%积累的多了。
有天运气好，公司或者学校老板给了个课题，以前各种失败剩下的东西用上了一点。就
算是一个突破。
上面说的是真科研。如果说论文，现如今我感觉是文学和修辞术为主流。
: 说个题外的话
: 你们写论文，如果发现一个神奇的，前人从未想到过的，颠覆性的点子，首先是
质疑还
: 是把它做出来？为什么到了写程序的时候非要直接上来就造轮子啊。
【在 x****u 的大作中提到】
: 说个题外的话
: 你们写论文，如果发现一个神奇的，前人从未想到过的，颠覆性的点子，首先是质疑还
: 是把它做出来？为什么到了写程序的时候非要直接上来就造轮子啊。
|
x****u
发帖数: 44466 | 54 论文也有运气成分
AI当年是业界公认的卢瑟领域，吴恩达还用杨乐村专门做出来的送他的DVD在斯坦福公
开课上调侃。
谁想2012年风水大变，谷歌砸了几千台高档服务器的算法被辛顿学生宿舍里面一台PC干
出了屎，然后三人同获图灵奖了。
要是跟对了人，12-13年随便哪个小点子都能发顶级论文，现在就是业界权威了。
【在 g****t 的大作中提到】
: 个人经验：
: 一般情况下，开始试验验证的第一天就会淘汰90%的idea。然后检查，重复，不停的折
: 腾这10%。最后剩下1%有用的东西。这1%积累的多了。
: 有天运气好，公司或者学校老板给了个课题，以前各种失败剩下的东西用上了一点。就
: 算是一个突破。
: 上面说的是真科研。如果说论文，现如今我感觉是文学和修辞术为主流。
:
:
: 说个题外的话
:
: 你们写论文，如果发现一个神奇的，前人从未想到过的，颠覆性的点子，首先是
: 质疑还
|
g****t
发帖数: 31659 | 55 业界权威又如何？那是观众的评价，是这些观众生活的一部分。和科研关系不大。
总是站在观众的角度看问题，永远也不会明白科研这个圈子的。
: 论文也有运气成分
: AI当年是业界公认的卢瑟领域，吴恩达还用杨乐村专门做出来的送他的DVD在斯
坦福公
: 开课上调侃。
: 谁想2012年风水大变，谷歌砸了几千台高档服务器的算法被辛顿学生宿舍里面一
台PC干
: 出了屎，然后三人同获图灵奖了。
: 要是跟对了人，12-13年随便哪个小点子都能发顶级论文，现在就是业界权威了。
【在 x****u 的大作中提到】
: 论文也有运气成分
: AI当年是业界公认的卢瑟领域，吴恩达还用杨乐村专门做出来的送他的DVD在斯坦福公
: 开课上调侃。
: 谁想2012年风水大变，谷歌砸了几千台高档服务器的算法被辛顿学生宿舍里面一台PC干
: 出了屎，然后三人同获图灵奖了。
: 要是跟对了人，12-13年随便哪个小点子都能发顶级论文，现在就是业界权威了。
|
x****u
发帖数: 44466 | 56 你知道为什么吴恩达调侃了去年的图灵奖么？因为杨乐村搞出的卷积神经网络连自己工
作都没保住。
最近的深度学习大潮里，所有的决定性成果都是美国以外的人弄出来的。加拿大法国三
人组不说了，VGG是英国，ResNet是MSRA，DeepMind还是英国。为啥不是美国，因为美
国管纺锭的权威不评价他们啊。
了。
【在 g****t 的大作中提到】
: 业界权威又如何？那是观众的评价，是这些观众生活的一部分。和科研关系不大。
: 总是站在观众的角度看问题，永远也不会明白科研这个圈子的。
:
:
: 论文也有运气成分
:
: AI当年是业界公认的卢瑟领域，吴恩达还用杨乐村专门做出来的送他的DVD在斯
: 坦福公
:
: 开课上调侃。
:
: 谁想2012年风水大变，谷歌砸了几千台高档服务器的算法被辛顿学生宿舍里面一
: 台PC干
:
: 出了屎，然后三人同获图灵奖了。
|
a*****1
发帖数: 314 | 57 正在研究grpc
请问。grpc 适合 推送/接受 视频流吗？
谢谢
【在 w********m 的大作中提到】
: 最近在搞Websocket。
: 这玩意不是request/response model. 收不收到信息不确定。这样就麻烦了。
: 就是一个http的长链接，http的缺点全都有。
: 推荐grpc。基于http2，安全高速。
|
m*****n
发帖数: 3575 | 58 websocket就够用，什么nginx之类的都支持
就是http改不主动断，接着长连接，变相恢复成TCP了
至于高流量的视频直播什么的，和我无关了
【在 c*******v 的大作中提到】
: 楼主最后怎么实现的？
: 我写了个简单的redis proxy。下一步就是这贴里说的机器学习放进去。
|
