老师，有几个问题？
1.请问消息是在系统设计图的哪个地方打上的时间戳的。是在服务器端，还是在客户端？客户端我觉得不对，因为那样可以操纵时间戳。如果是后者，如果双方都去的是一个data center，虽然不是一台机但是这个时间上的差别我感觉还可以容忍，还可以有一个标准时间，但是你比如说我人在美国，我家人在国内，这个时候双方难道还要都到路由到同一个数据中心去打时间戳么？我感觉这个underlying的标准时间完全就是拿不到的。
在客户端上面聊天框消息显示接收的消息肯定是从websocket 推送过来的，自己敲出来的消息是立刻从本地直接就上了聊天框的么？那发出去的消息的时间戳怎么搞来的，先奔服务器上，请求一个时间回来append在这个message上么？
您上课说的conner case，说的好像就是屏幕聊天框上的显示问题，说发出去的消息本地还要把消息排序一下，按本地时间排个顺序，收到的消息按服务器的时间排个顺序。还是说，这个发送出去的消息的这个时间戳是哪来的，本地的么，还是服务器的？我比较困惑如果发送来的和发出去的时间的基准不一样，怎么把他们犬牙交错的按照正常的问答给表现出来呢？比如说极端情况下，我本地发送的时间都搞成了公元元年，岂不是收到的信息全跑最后面去了。
老师，我看到还有的说用在对话各方之间使用一个局部全局的单调递增的id作为时间的先后顺序。这种方案和直接用时间戳之间的trade off是什么呢？本质上应该都是一个意思吧。
那如果app自己就可以打上时间戳而且和服务器一样能跟time server进行校准的话，也就是说基本上可以认为时间打的是一致的，那我还是有点迷惑，那为啥还要可以强调说，时间用的是服务器时间呢？这个过程是在客户端打上了个时间戳，到了服务器那边再打个时间戳？
现在接收服务器端是可以打合理的时间戳，那么所谓本地排发送的信息，服务器端排收到的消息，意思就是说在客户端对话框显示，ideally就像merge two sorted list一样，merge成一问一答的效果，是这意思么？
logic
2021 年2 月 3 日 04:45
5
有点不一样。如果对话双方共用同一组单调递增的 ID 的话，会造成双方看到的对话顺序是完全一致的。那么如果双方同时发送，就会有一方看到对方的话跳到自己的话之前。
logic
2021 年2 月 3 日 04:48
6
不一样。因为数据到达服务器是需要时间的。
我们提的方案是自己打的内容按本地时间戳，其他人的内容按服务器时间戳，Sort 一下就好。就是一个 List。
老师，我不知道理解的对不对啊，如果是按照时间戳排序的话，那么一条消息从开始在发送方客户端上，到收件方的服务器上，应该经历的data flow，咱们上课说了会经历发送方app，发送方服务器，收件方服务器（有queue），然后收件方的APP，现在咱们在之前的讨论中一直再说本地时间戳，服务器时间戳。我就比较迷糊了，本地时间戳，发送方打出来的message在本地会为了显示在对话框上，会打一个时间戳，之后发出去了，彻底跟发送方的告别了，那究竟来到了是哪个服务器，发送方服务器，还是收件方服务器上拿到了第二个时间戳，就是您说的这个时候这个消息就变成您恢复中其他人的时间戳的这个服务器时间戳，这个时间戳在哪里打上的？
另外一个问题，我想问，如果这个queue是一个普通的队列，如果出现了丢包（会重新发送么？），或者网络延迟，那么进入队列的时候虽然是虽然靠前，但是其实是之前的消息，会有这种现象发生么？那么这个修正顺序的过程有办法解决么？是靠queue来解决么？还是靠客户端的重新排序解决？而且这个重新排序是base on 时间戳，丢包了的时候，乱序的消息的时间戳是重现按照上一个丢包的时间戳给呢，还是另算时间呢。
抱歉老师，细节有点多，卡了一步，过不去。 您受累。