由买买提看人间百态

boards

本页内容为未名空间相应帖子的节选和存档,一周内的贴子最多显示50字,超过一周显示500字 访问原贴
Programming版 - 请教魏老师一个协议设计的基本功问题
... ?
相关主题
ip问题code question
回goodbug,关于DC的failover策略,兼普及基础知识如何下载网络页面,不包含,
谁做过嵌入式设备(类似手环)到手机的通讯python的一大缺点
如何减少libcurl内存的使用低手问个C的scanf问题
老魏 机器已经上了问一个很弱的c++ cin的问题
port复用question about "popen" in C/C++
[转载] 简单的题都不敢做了.多次调用yyarse()的buffer flush问题。
EOF一问请帮忙看一下这个c程序(更新)
相关话题的讨论汇总
话题: ack话题: msg话题: 扣钱话题: connection话题: 协议
进入Programming版参与讨论
1 (共1页)
o**2
发帖数: 168
1
这个协议是要用在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 << 乙
T********i
发帖数: 2416
2
messaging也可以有connection。我这个就是TCP上的。也便于简化讨论。
你看看能不能甲乙丙。
甲就是web server APP,便于分布。数据可以完全划分。
乙就是我的牛逼核心,一串机器横跨很多DC。
丙就是负责连接银行管钱的
甲先check车票cache,如果有票,告诉用户。如果用户要买,他可能先check钱,再
check一次cache,如果还有票,送请求给乙。
乙负责抢票。注意,因为异步通信,送到乙也不一定抢到。如果抢不到,乙直接拒绝好
了。如果抢到了,乙就会更新票状态,然后把买票消息往下传。
一直传到丙。注意,这都是在我们的DC群内,latency有一定保障。丙会送ACK回来。然
后同时去银行划钱。
丙的ACK一直送到甲。通知用户买到票了。这个过程,在任何一个乙服务器中,都是微
秒级。latency主要是跨DC通信延迟。毫秒级。
现在设想甲乙丙,任何一个死掉了。都能通过上下游恢复状态。消息是不可能丢的。因
为是TCP。即使不是TCP, APP级别保证delivery不是问题。
f*******t
发帖数: 7549
g****r
发帖数: 1589
4
这不是计算机网络第一页就讲了的那个红军、蓝军的例子吗
双方约定只要收到了2个或3个以上的ACK,就算确认成功了?

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

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

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

1 (共1页)
进入Programming版参与讨论
... ?
相关主题
请帮忙看一下这个c程序(更新)老魏 机器已经上了
如何用 preprocessor unroll for loop?port复用
C++ Q13: Input[转载] 简单的题都不敢做了.
how to skip the last empty lines in ifstream?EOF一问
ip问题code question
回goodbug,关于DC的failover策略,兼普及基础知识如何下载网络页面,不包含,
谁做过嵌入式设备(类似手环)到手机的通讯python的一大缺点
如何减少libcurl内存的使用低手问个C的scanf问题
相关话题的讨论汇总
话题: ack话题: msg话题: 扣钱话题: connection话题: 协议