I have a FIX server and FIX client implementing FIX4.4 running on the same network. I use QuickFIX C++ engine. Altough they are on the same network, sometimes they disconnect. In the FIX server's event logs:
20140612-01:21:30.000 : Sent test request TEST
20140612-04:11:56.000 : Sent test request TEST
20140612-07:05:26.029 : Sent test request TEST
20140612-07:05:26.029 : Socket Error: An established connection was aborted by the software in your host machine.
Means HEARTBIT messages are failed to send/recv.
What can be wrong? I have a regular setup and nothing special..
Thanks
while the client connection was accepted by the server, it doesn't look like you then achieved "logon". First you connect, then you logon. You need to make a logon request after you connect. Look at the initial FIX messages sent between client and server.
Related
i am having an application running inside a gateway,
this application is a coap-server coded using the libcoap library
the server is running perfectly fine, the ip:port is tested using different commands such as nmap , telnet and others, each time it shows that the port is open and the connection is a success.
My problem is that there's no response from the server, wireshark is showing that the requests are being re-transmitted until timeout.
After some research, i thought that the gateway doesn't support NAT loopback, so i tried sending requests from another connection (i used my phones 4G). I even disabled firewall on the gateway too, But no success either.
UPDATE:
after some digging, i managed to receive a response from the server, but only when using TCP connection, the UDP still sends requests until timeout,
from a logical point of view, what may be the problem here ?
note: UDP is a must in this application so i cant just ignore it.
I am entering the ip of the machine I wanted to connect using vnc viewer but it's giving me this error:
So, that error means
No response was received from the specified IP address, even to reject
the connection.
Ways to fix this:
Check the remote computer is switched on. Ensure antivirus software lists VNC Server as an exception, and the firewall is configured to allow access on VNC Server’s listening port (5900 by default).
See if you are attempting to establish a direct connection over the Internet.
You can check any vnc error message from https://help.realvnc.com/hc/en-us/articles/360002254738-VNC-Connect-Error-Messages
I am working on a product which uses ZeroMQ (version 4.0.1).
The server and client communicate based on ZeroMQ ROUTER-socket.
To read socket events, server and client also create socket-monitor sockets (PAIR). There are three ports on which server binds and listens. Out of these three ports, one port is in a non-secured mode. Other two ports are using md5-authentication.
The issue I am facing is that, both the server and the client spontaneously receive socket disconnect for one of the secure port sockets (please see a log below). I have checked multiple times that server and client both have L3 reachability to each other.
What else I should check for?
What really triggers this error scenario?
zmq_print_callback:ZmQ: int zmq::stream_engine_t::read(void*, size_t):923
Stream engine recv():
TCP socket (187) to unknown:0 was disconnected
with error 107 [Transport endpoint is not connected]
Below sequence of events can trigger this error on server
Server receives ACCEPTED event for clientY and gets FD1.
Link-flap/network issue happens and clientY disconnects but server does not receive this disconnect.
Network recovers and clientY connects back to server.
Server receives ACCEPTED event for clientY and gets FD2. However, packets sent to this sockets does not go out of the server.
After 1 min or so, clientY receives "Transport endpoint is not connected error" for FD1.
Application can use this to treat as client disconnect.
I have a client-server (Java) application using persistent TCP connections, but sometimes the Server receives java.io.IOException: Connection reset by peer exception when trying to write on the socket, however I don't see any error in the Client log.
This RST is probably caused by an intermediate proxy/router, but if that's the case, should this be seen on the client as well?
If the RST is sent by the client, it can be seen on it using a packet sniffer such as wireshark. However, it won't show up in any user-level sockets since it's sent by the OS as a response to various erroneous inputs (such as connection attempts to a closed port).
If the RST is sent by the network, then it's pretending to be the client to sever the connection. It can do so in one direction, or in both of them. In that case, the client might not see anything, except for a RST sent by the actual server when the client continues to send data to a connection it perceives as open, while the server sees it as closed.
Try capturing the traffic on both the server and the client, see where the resets are coming from.
My client app gets intermittent winsock errors (10060, 10053) against one particular server we interface with. I have it re-trying the request that failed, but sometimes it fails repeatedly, and I give up after 5 re-tries. Would it be likely to help at all if I closed the socket and created a new one? (I know nothing about the server-side.)
Ok, so the errors that you're getting are:
10060 - WSAETIMEDOUT
10053 - WSAECONNABORTED
When do you get them? What are you doing at the time?
You get a WSAECONNABORTED when the remote end of the connection, or possibly an intermediary router, resets the connection and sends an RST. This could simply be the remote end issuing a non lingering close or it could be the remote end aborting or crashing.
You can't continue doing anything with a connection that has had a WSAECONNABORTED on it as the connection has been aborted and is no more; it is a dead connection, it has passed on...
Context matters immensely as to why you might get a WSAETIMEDOUT exception and the context will dictate if retrying is sensible or not.
One thing I would try is- do tracert to your server.
Often when someone is connected through VPN; you may see this error because your local and remote ip addresses overlap.
e.g. if your local ipaddress range is 192.168.1.xxx and vpn remote range is also 192.168.1.xxx you will also see this error.
sharrajesh