我正在为我的 iOS 消息应用程序使用 GCDAsyncSocket 库，并在后端使用 Twisted Server。一切都设置得很好并且工作正常，但是当它不能正常工作时，我发现了一个特殊的情况。因此，我的服务器的架构方式是，当用户离线时，他的所有消息都缓存在服务器上，当检测到他在线时，服务器会立即将所有缓存的待处理消息发送给他。
现在，GCDAsyncSocket 使用内部读取和写入队列，所以这里，那些由服务器发送的挂起消息被读取队列排队，直到它们被委托(delegate)方法读取 -(void)socket:didReadData:withTag:现在，在我的应用程序中，这个委托(delegate)方法处理传入的消息并在表格 View 中一一显示。因此，问题的关键在于，每当委托(delegate)方法从队列中读取时，如果您暂停应用程序，读取队列中所有未处理的消息都会丢失。因此，为了解决这个问题，我想访问读取队列，以便在应用程序暂停之前保存其内容，以便在再次打开应用程序时恢复它。
备注 :根据我的理解，丢失的消息来自队列而不是服务器，因为服务器显示“发送的所有消息”甚至在代理在处理时达到一半消息之前。之后，如果暂停，则此问题仍然存在。
那我做错了吗？或者有什么方法可以访问队列？
最佳答案
您可以考虑在您的协议(protocol)中添加一个确认步骤。与其让服务器发送所有排队的消息然后立即忘记它们，不如让它记住它们，直到客户端发回每条消息的确认。
这样，无论客户端在接收特定消息并将其显示给用户之间做什么，该消息将始终可用于从服务器重新传递。只有在客户端查看(并因此确认)消息之后，服务器才会忘记它(因此不会在客户端下次出现时将其重新传输给客户端)。
通过为消息分配唯一标识符，您可以很容易地做到这一点。这些可能是随机的 UUID，或者 - 如果您的消息传递必须始终按顺序排列 - 序列号。序列号很方便(如果它们对您的应用程序有意义)，因为通过确认单个消息序列号，您的客户端可以指示它已经处理了多个消息(因为如果它总是按顺序处理它们，那么任何具有较早序列号的消息都必须具有也被处理)。
此策略的失败模式与您当前策略的失败模式相反。现在，当电话在从接收队列中拉出消息之前挂起时，它就会丢失。使用确认，消息在处理(显示)之前不会丢失。但是，您可能会显示该消息，然后以某种方式无法发送确认。这将导致消息显示两次。
您还可以通过在电话上记录有关已处理(显示)哪些消息的信息来缩小此故障的窗口。如果电话从服务器接收到它知道它已经显示的消息，那么它可以跳过显示它并重新发送确认以允许服务器忘记它。
这会将失败窗口缩短为仅显示消息与您设法在本地记录该消息已显示之间的时间(或相反的顺序，如果您更喜欢消息丢失而不是显示消息的失败模式两次)。
关于ios - 访问 GCDAsyncSocket 读取队列，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26258080/