Redian新闻
>
请教魏老师一个协议设计的基本功问题
avatar
请教魏老师一个协议设计的基本功问题# Programming - 葵花宝典
c*e
1
今天听朋友说的,
他的父亲2个月前签b2没有签过,
这次在约就不让了。
这是什么时候的新规定呀?
哪儿能看到原始文件
avatar
l*d
2
请教一下:刚铺的新草皮。大概有一个半礼拜了,每天早晚个浇一次水,自动浇的。现
在看起来好像不如别人家的草坪。人家的绿绿的,我家的没别人的绿。个别地方发黄。
这个正常不?请赐教。多谢。
avatar
b*2
3
前几天不是说男友的公司在裁人吗,意料之中男友在名单之列,全公司就只有8个
人了。有个还是个光杆司令,这下面都没人还怎么干活,放在谁身上都不爽啊。所以这
个光杆司令就决定跟他们老总商量保住男友,而且他们那个工作要是忙起来一个人肯定
是不够的,最终经过商量男友终于幸免了。
avatar
z*u
4
http://acg.178.com/201204/127938686587.html
在最新一期的电击文库上,又公布了一部轻小说将要动画化的消息,她就是《樱花庄
的宠物女孩》。不过具体的STAFF名单还未公布,而配音方面则会沿用之前广播剧CD的
配音阵容。
《樱花庄的宠物女孩》(さくら荘のペットな彼女)是由鸭志田一撰写,沟口ケー
ジ负责插画的轻小说,是一部校园向的恋爱喜剧。讲述了住在樱花庄的神田空太被刚搬
到这里的缺乏常识的天才画家椎名真白耍的团团转的故事。天闻角川曾代理发行过简体
中文版。
「樱花庄的宠物女孩」轻小说:http://xs.178.com/936/index.shtml
【广播剧CD CAST】
椎名真白:茅野爱衣
神田空太:松冈祯丞
青山七海:中津真莉子
上井草美咲:高森奈津美
三鹰仁:樱井孝宏
赤坂龙之介:堀江由衣
千石千寻:丰口惠美
avatar
o*2
5
这个协议是要用在messaging上的,就是说和有connection的通讯不大一样,比如你得
不到connection broken或EOF这样的额外信息,所有的信息就是message本身。
1,甲 >> MSG >> 乙
2,甲 << ACK << 乙
假设甲管钱,乙管车票。第一步就是甲给乙发一个MSG,这个MSG含有购一张票的信息。
如果乙有票的话,就库存减一,否则库存不变,这个结果放在ACK里返回。
第二步,甲收到这个ACK里的结果后,相应地扣钱:乙成功,扣钱;反之,不扣。
现在的问题是,在MSG/ACK有可能丢失的前提下,如何保证甲乙双方动作同步?比如,
ACK丢失了,结果乙扣了票,但甲没有扣钱。
如果象下面那样继续互相ACK下去,什么时候是结束的时候?
3,甲 >> ACK1 >> 乙
4,甲 << ACK2 << 乙
5,甲 >> ACK3 >> 乙
6,甲 << ACK4 << 乙
7,甲 >> ACK5 >> 乙
8,甲 << ACK6 << 乙
avatar
i*n
6
听说都是胡说

【在 c**e 的大作中提到】
: 今天听朋友说的,
: 他的父亲2个月前签b2没有签过,
: 这次在约就不让了。
: 这是什么时候的新规定呀?
: 哪儿能看到原始文件

avatar
g*o
7
缺铁了?瞎琢磨的,等专家来

【在 l*******d 的大作中提到】
: 请教一下:刚铺的新草皮。大概有一个半礼拜了,每天早晚个浇一次水,自动浇的。现
: 在看起来好像不如别人家的草坪。人家的绿绿的,我家的没别人的绿。个别地方发黄。
: 这个正常不?请赐教。多谢。

avatar
T*i
8
messaging也可以有connection。我这个就是TCP上的。也便于简化讨论。
你看看能不能甲乙丙。
甲就是web server APP,便于分布。数据可以完全划分。
乙就是我的牛逼核心,一串机器横跨很多DC。
丙就是负责连接银行管钱的
甲先check车票cache,如果有票,告诉用户。如果用户要买,他可能先check钱,再
check一次cache,如果还有票,送请求给乙。
乙负责抢票。注意,因为异步通信,送到乙也不一定抢到。如果抢不到,乙直接拒绝好
了。如果抢到了,乙就会更新票状态,然后把买票消息往下传。
一直传到丙。注意,这都是在我们的DC群内,latency有一定保障。丙会送ACK回来。然
后同时去银行划钱。
丙的ACK一直送到甲。通知用户买到票了。这个过程,在任何一个乙服务器中,都是微
秒级。latency主要是跨DC通信延迟。毫秒级。
现在设想甲乙丙,任何一个死掉了。都能通过上下游恢复状态。消息是不可能丢的。因
为是TCP。即使不是TCP, APP级别保证delivery不是问题。
avatar
T*m
9
才一个半礼拜,你心太急。

【在 l*******d 的大作中提到】
: 请教一下:刚铺的新草皮。大概有一个半礼拜了,每天早晚个浇一次水,自动浇的。现
: 在看起来好像不如别人家的草坪。人家的绿绿的,我家的没别人的绿。个别地方发黄。
: 这个正常不?请赐教。多谢。

avatar
l*n
11
正常,根还没有长好呢。等两个月再看看效果如何。
avatar
g*r
12
这不是计算机网络第一页就讲了的那个红军、蓝军的例子吗
双方约定只要收到了2个或3个以上的ACK,就算确认成功了?

【在 o**2 的大作中提到】
: 这个协议是要用在messaging上的,就是说和有connection的通讯不大一样,比如你得
: 不到connection broken或EOF这样的额外信息,所有的信息就是message本身。
: 1,甲 >> MSG >> 乙
: 2,甲 << ACK << 乙
: 假设甲管钱,乙管车票。第一步就是甲给乙发一个MSG,这个MSG含有购一张票的信息。
: 如果乙有票的话,就库存减一,否则库存不变,这个结果放在ACK里返回。
: 第二步,甲收到这个ACK里的结果后,相应地扣钱:乙成功,扣钱;反之,不扣。
: 现在的问题是,在MSG/ACK有可能丢失的前提下,如何保证甲乙双方动作同步?比如,
: ACK丢失了,结果乙扣了票,但甲没有扣钱。
: 如果象下面那样继续互相ACK下去,什么时候是结束的时候?

avatar
r*s
13
放点照片上来我看看。你的土壤有没有做土壤测试, 土壤的酸碱度? 建筑工人有时会
破坏本来的土壤。 你用的是啥草? 在那里?
avatar
o*2
14
我的问题是一个抽象的问题,是我的project面对的,不是针对你的车票方案问的,只
是借用了你的scheme,所以不能再加第三方。
问题的本质是在只有双方的情况下,如何靠每次单向的通讯来达到双方之间完全的
awareness。
我之前列出的互相ACK是可以做到的,只是太没有效率,太愚蠢了。这个方案的核心是
甲乙都事先知道对方的decision moment,只要知道对方过了那个moment,那个step,
就可以停下来了。比如甲知道乙在收到ACK3之后就会make decision了,而乙知道甲在
收到ACK2之后就会make decision。这样,甲乙要继续ACK直到大家都知道对方过了那个
点。
avatar
o*2
15
fantasist和gondar,谢谢你们。我正在阅读中,想看看有没有最新的进展。我之前想
借鉴SSL的握手协议,后来发现在这个messaging环境下和有connection的环境下,还是
不一样的。
avatar
o*2
16
我刚才进来这个帖子看了一下,感觉自己的回复很没有礼貌,因为单独感谢了楼上两位
,都没有提及魏老师。
谢谢魏老师回应这个呼叫贴。
avatar
b*s
17
你可以看一下我帮魏老师画的图,应该比较容易理解的

【在 o**2 的大作中提到】
: 这个协议是要用在messaging上的,就是说和有connection的通讯不大一样,比如你得
: 不到connection broken或EOF这样的额外信息,所有的信息就是message本身。
: 1,甲 >> MSG >> 乙
: 2,甲 << ACK << 乙
: 假设甲管钱,乙管车票。第一步就是甲给乙发一个MSG,这个MSG含有购一张票的信息。
: 如果乙有票的话,就库存减一,否则库存不变,这个结果放在ACK里返回。
: 第二步,甲收到这个ACK里的结果后,相应地扣钱:乙成功,扣钱;反之,不扣。
: 现在的问题是,在MSG/ACK有可能丢失的前提下,如何保证甲乙双方动作同步?比如,
: ACK丢失了,结果乙扣了票,但甲没有扣钱。
: 如果象下面那样继续互相ACK下去,什么时候是结束的时候?

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。