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下去，什么时候是结束的时候？
|
