GCM XMPP Socket在发送通知时始终获得EPIPE并断开连接

时间:2017-12-07 19:39:48

标签: node.js google-cloud-messaging xmpp firebase-cloud-messaging node-xmpp

我们有一个xmpp连接服务器,它将套接字连接到GCM XMPP端点并开始发送通知。

我们注意到的一件事是在发送半大通知(比如只有1000个设备)时,套接字不断突然断开收到以下错误消息:< / p>

Client disconnected  socket=b913-512-904dc69, code=EPIPE, errno=EPIPE, syscall=write

例如,这是开始向不同注册IDS发送通知时实时服务器的日志。

  
      
  1. info:发送下游消息msgId = P#c1uq ... socketId = 512
  2.   
  3. info:发送下游消息msgId = P#c3tE ... socketId = 512
  4.   
  5. info:发送下游消息msgId = P#c1TF ... socketId = 512
  6.   
  7. info:发送下游消息msgId = P#c3sy ... socketId = 512
  8.   
  9. info:发送下游消息msgId = P#c41N ... socketId = 512
      ...      
        
    1. info:发送下游消息msgId = P#cJbr ... socketId = 512
    2.   
    3. info:发送下游消息msgId = P#cJXO ... socketId = 512
        info:客户端断开连接socket = b913-512-904dc69,code = EPIPE,errno = EPIPE,   系统调用=写
    4.   
  10.   

这在我们系统中的所有时间和地点都在不断发生,并且使服务质量保证非常困难。

我们注意到的另一件事是,有时在调用socket.send(stanza)时,返回值false即使套接字已明确连接。这个更糟糕,因为我们必须对消息进行重新排队,并且在发送数百万条消息时它确实非常耗费资源。这将在下面解释。

其他信息:

  1. 从第1条消息到第84条消息(发生断开连接),减去 超过100毫秒。

  2. 我们为这个JID / PASSWORD打开了大约52个套接字 (3个不同的服务器上的senderId,GCM&#39;中的Api_key)。一切都保持 当大型通知发送任务到来时,现在断开连接 沿着(比如10000名接收者)。

  3. 套接字成功重新连接,但它们已经断开连接几秒钟,这会降低我们系统的效率和可靠性。
  4. 如何设置连接:

    const xmpp = require('node-xmpp-client');
    let socket = new xmpp.Client({
            port: 5235,
            host: 'gcm-xmpp.googleapis.com',
            legacySSL: true,
            preferredSaslMechanism: 'PLAIN',
            reconnect: true,
            jid: $JID,
            password: $PASSWORD
    });
    socket.connection.socket.setTimeout(0);
    socket.connection.socket.setKeepAlive(true, 10000);
    socket.on('stanza', (stanza) => handleStanza(stanza));
    ...
    

    为收到的每个上游消息发送Ack 但我们看到的一件事是,跟随有时在发送下游消息时返回false,即使连接套接字&#34; 也是如此。

    // This returns false many times! even when the socket.connection.connected === true! 
    socket.send(xmppStanza)
    

    如果发生这种情况,我们会将ack消息排队,以便稍后重试,但继续向gcm发送消息。

    为什么socket.send有时会返回false? (这显然不是像EPIPE或其他任何错误,它只是一个错误,意味着刷新套接字是不成功的,即使它已连接,套接字也可能变得不可写?)。

    如果ack延迟,GCM会关闭与延迟时间的连接,还是会停止向上游发送? (AFAIK,它只是停止发送上游,所以这可能与关闭的连接(EPIPE)无关?)

    如果有人能对这种行为有所了解,我真的很感激。

    谢谢!

0 个答案:

没有答案