在我们的应用中，我们使用socket.io来获取实时通知。
在连接到套接字之前，我们首先使用http请求获取所有先前的通知，然后使用套接字连接。
如果在http答案结束和套接字连接之间的时间内创建了通知，则会出现问题。
但事实上，即使我们在收到所有通知之前连接套接字。如果我们没有任何可能获得http答案的状态，我们无法知道它是否可能包含在套接字中收到的通知，例如我们的套接字来获取通知的数量。
--> connecting to the socket
--> http get notifications number
<-- new notification emit in socket
<-- http answer of the notification number
您如何知道http答案是否包含新通知？
这个“悖论”有名字吗？
也许我们没有做对，应该使用不同的模式？
答案 0 :(得分：0)
我知道解决这种竞争条件的唯一方法是在每个通知中都有一些识别标记。最常见的标签号是随着每个通知或时间/日期标记而增加的（但您可能希望确保不会使用相同的时间/日期标记获得重复）。
然后，您可以连接socket.io，它会向您发送一条消息，其中包含当前的最后一个标签号。然后，您可以执行一个http请求或一个socket.io消息（任何一个将起作用），该消息要求来自最后一个标签号和更早的（一种查询类型）的所有消息。然后，您知道您将可靠地获得所有消息。
所以，事件的顺序是：
可以将步骤2-4组合在一起，以便服务器在您连接后立即自动向您发送所有早期消息，但您必须确保在自动重新连接时不会发生这种情况。现有网页已经包含所有这些消息。如果要实现该自动发送行为，可以在socket.io connect上使用查询参数，该参数告诉服务器您希望它向您发送在连接之前到达的消息。