Hi Alex,
Thanks so much for replying.
In our environment, a remote site has the Autohan/Python WAMP client/component behind a firewall/modem. The backend is where Crossbar.io is running. The remote WAMP component initiates the connection to Crossbar.io (which is configured in its config.json to listen on port 8080). Since this is therefore an "outgoing" connection from the remote site across the firewall to Crossbar.io, this seems to work fine.
Now as I understand it, Crossbar.io is the entity that initiates the auto_ping feature to check client/component connections, is that right? With the following auto_ping options configured in Crossbar.io's config.json:
"transports": [
{
"id": "web",
"type": "web",
"endpoint": {
"type": "tcp",
"port": 8080
},
"paths": {
"api": {
"type": "websocket",
.
.
.
"options": {
"enable_webstatus": false,
"max_frame_size": 1048576,
"max_message_size": 1048576,
"auto_fragment_size": 65536,
"fail_by_drop": true,
"open_handshake_timeout": 2500,
"close_handshake_timeout": 1000,
"auto_ping_interval": 10000,
"auto_ping_timeout": 5000,
"auto_ping_size": 4,
"compression": {
"deflate": {
"request_no_context_takeover": false,
"request_max_window_bits": 11,
"no_context_takeover": false,
"max_window_bits": 11,
"memory_level": 4
}
}
}
}
}
}
],
We observe the following messages in the syslog file:
Feb 8 16:39:52 arts-stageprodenv supervisord: lj_wwwApiRouter 2017-02-08T16:39:52-0500 [Router 9870] dropping connection to peer tcp4:
127.0.0.1:47492 with abort=True: WebSocket ping timeout (peer did not respond with pong in time)
Feb 8 16:52:47 arts-stageprodenv supervisord: lj_wwwApiRouter 2017-02-08T16:52:47-0500 [Router 9870] dropping connection to peer tcp4:10.250.0.2:37178 with abort=True: WebSocket ping timeout (peer did not respond with pong in time) Feb 8 16:55:35 arts-stageprodenv supervisord: lj_wwwApiRouter 2017-02-08T16:55:35-0500 [Router 9870] dropping connection to peer tcp4:
127.0.0.1:47501 with abort=True: WebSocket ping timeout (peer did not respond with pong in time)
10.250.0.2 is the address of the remote site, and the reason for my question is that I noticed the port 37178, which obviously isn't specified anywhere, and is centrainly not an open port on the firewall/modem for Crossbar.io to be able to reach/auto_ping the remote component. What am I missing?
Also, I just noticed the messages about the localhost (127.0.0.1) auto_pings failing. Not sure what that is? We do run a couple components on the same system as Crossbar.io as well (ex. components that register RPCs for the remote components to call, etc.), but I'm not sure why they wouldn't be able to respond to the auto_ping?
Sorry if this is confusing at all - I'm trying not to provide irrelevant data. Let me know if I need to provide more or if something isn't clear.
Thank you again very much for your help,
Dave