I'm developing a real-time game server with WebSocket.
Recently, I've got to know there's a possibility that a connection is broken but server and client both unaware of it. Link : https://github.com/websockets/ws#how-to-detect-and-close-broken-connections
The question is...
Q1. Is there a possibility to restore a broken connection? So below sequence could happen
==WebSocket connection established==
Server -> Client : Data1 frame
Server -> Client : ping frame
Server <-- Client : pong frame
==Connection broken but nobody notified==
Server ->x Client : Data2 frame
==Connection restored but nobody notified==
Server -> Client : ping frame
Server <-- Client : pong frame
==Connection still alive but Data2 not transferred...==
Q2. If possible, then how could detect broken connection? Is there an ideal ping-pong period time?
Related
I have used http://github.com/streadway/amqp package in my application in order to handle connections to a remote RabbitMQ server. Everything is ok and works fine but when a connection is idle for a long period of time f.g 6 hours it gets closed. I check NotifyClose(make(chan *amqp.Error)) all time in my go routine and it returns :
Exception (501) Reason: "write tcp
192.168.133.53:55424->192.168.134.34:5672: write: broken pipe"
Why this error happens? (is there any problem in my code?)
How long a connection can be idle?
How to prevent this problem?
As Cosmic Ossifrage says, the error is saying your RabbitMQ client has disconnected.
There are so many things that could sit between your client and server that can/will drop dormant connections that it's not worth focusing on how long your connection can be dormant for. You want to set the requested heartbeat interval in your connection manager.
https://www.rabbitmq.com/heartbeats.html
I'm not familiar with the framework you're using but I see it has a defaultHeartbeat field in connection.go. You might need to experiment with the value to find the best balance is to stop the connection being killed but not hit the server too often with keep-alive traffic.
I have two systems A: Windows and B: Nucleus RTOS.
B acts as server on port 50001 and A as a client to open a connection from a Windows application.
I came across the issue when the client application in A is killed and started again, the connection with B is not formed.
The 'netstat' show the connection status in SYN_SENT state.
The server on B comes to listening mode immediately after the connection is broken and stays in listening mode.
Thus the connection state nevers comes to established and it stays in hanged state.
Is the issue in A: Windows system or in B: RTOS system ?
How this can be fixed ?
TIA
Trying to establish a tcp connection between a client / server. Both machines are Macs and are on the same LAN. Server's app listens on port 12345. After receiving "SYN, ACK" from Server, I send "ACK" but then my client automatically sends a "FIN, ACK" followed by "RST, ACK". So the TCP Flow ends up being:
Client sends SYN.
SVR sends SYN, ACK.
Client sends ACK.
Client sends FIN, ACK.
Client sends RST, ACK.
SVR sends ACK.
SVR sends ACK.
Client sends RST.
Client sends RST.
From reading other posts with similar issues it sounds like this could be happening because I'm trying to manually create the handshake on the user level and the Unix kernel (operating at the system level) sees the "SYN, ACK" far before anything on the user level can respond and moves to close the connection, seeing it as open for no reason. A similar problem to what this Linux user experienced: Unwanted RST TCP packet with Scapy
Whereas iptables worked for the Linux user should I use something like pf in Mac OS X to block / drop the FIN and RST msgs? My client is running 10.9.5 and my server 10.10.3.
Here's a flow graph of the tcp communication Server is 10.0.100.5 and client is 10.0.100.4:
I am working on an FTP client for kicks and I am trying to understand the workflow of data connections.
As I understand, the initial (command) connection is permanent until you quit. However, I am unsure of the data connection - is it re-initiated per-command? So you call PORT ... or PASV, get a second connection, do a LIST, get the results, connection closes, start over?
Also, do you need to call PASV (or PORT ...) again after each connection closes? It seems that when I try to test some things out using a passive connection, I cannot re-connect to the same port after the first command has returned the results and closed the data connection. I can keep calling PASV -> Data Connect -> Run Command -> Get Results -> Data Connection closed -> PASV, but it seems like it's not how it's meant to run?
Also, if someone has a good material on FTP that is more terse than the RFC I really appreciate it.
You have to open a new connection every time. It's only the closing of the connection, how you (or the server) can tell that the transfer completed (at least in the common "stream mode").
You cannot even reuse the local/remote port number combination, as when a TCP connection is closed, it enters TIME_WAIT mode and the port number combination cannot be used for some time. So for two immediately consecutive transfers you have to use a different port number combination anyway.
Refer to RFC 959, section 3.3. Data management:
Reuse of the Data Connection: When using the stream mode of data
transfer the end of the file must be indicated by closing the
connection. This causes a problem if multiple files are to be
transfered in the session, due to need for TCP to hold the
connection record for a time out period to guarantee the reliable
communication. Thus the connection can not be reopened at once.
There are two solutions to this problem. The first is to
negotiate a non-default port. The second is to use another
transfer mode.
A comment on transfer modes. The stream transfer mode is
inherently unreliable, since one can not determine if the
connection closed prematurely or not. The other transfer modes
(Block, Compressed) do not close the connection to indicate the
end of file. They have enough FTP encoding that the data
connection can be parsed to determine the end of the file.
Thus using these modes one can leave the data connection open
for multiple file transfers.
See also:
Why does FTP passive mode require a port range as opposed to only one port?
How many data channel ports do I need for an FTPS server running behind NAT?
Why does Apache-Commons-Net's FTPClient sometimes make the wrong computation for the port number in the PORT command? This is in active mode. For example FTPClient it could send out
PORT <some>,<ip>,<address>,<here>,235,181 when in fact the port number used is 60340. What's the cause for this wrong computation?
This could happen on version 3.3.
I know ftpClient.enterLocalPassiveMode(); could solve this, but I want to know the part where the active mode doesn't work as expected.
From your comments, I assume you mistake an FTP control connection with a data connection.
I assume that the 60340 is local port of the FTP control connection. When opening data connection, 60341 is assigned (hence the PORT ...,235,181).
Reasoning: In an FTP active mode, the client opens listening port for the expected data connection, which it then reports to the server via PORT command over an existing control connection. If the server cannot connect to the port, no TCP/IP packet can ever come to that port. As you claim that the "two machines still communicate at port 60340", it must be the control connection. There cannot be any communication on port, if the connection failed ("Can't open data connection").
The actual cause of the "Can't open data connection" error is likely that you are behind a firewall, so the server cannot connect back to the client. What is a common nowadays. That's what passive mode is good for.