Socket error 10054 connection was reset by the other side

Конспект

Буду описывать здесь процесс выполнения различных работ.

Страницы

четверг, 29 марта 2012 г.

Ошибка Outlook. Ошибка сокета: 10054. Код ошибки: 0x800CCC0E

Ошибка Outlook. Ошибка сокета: 10054.
Код ошибки: 0x800CCC0E

Ошибка при соединении с сервером. Учетная запись: ‘КартинаM’, Сервер: ‘smtp.mail.ru’, Протокол: SMTP, Порт: 25, Защита (SSL): Нет, Ошибка сокета: 10054, Код ошибки: 0x800CCC0E

WSAECONNRESET (10054) Connection reset by peer.

A existing connection was forcibly closed by the remote host. This normally results if the peer application on the remote host is suddenly stopped, the host is rebooted, or the remote host used a «hard close» (see setsockopt for more information on the SO_LINGER option on the remote socket.)

2.2 Без описаний список кодов всех ошибок WinSock можно найти из файлов WinSock.pas и winsock.h

2.3 Список кодов ошибок и краткое описание ошибок от Microsoft MSDN Windows Sockets Error Codes и от Microsoft Support Windows sockets error codes, values, and meanings

2.4 На русском языке Коды ошибок TCP/IP описывают ошибку 10054 следующим образом :

10054 WSAECONNRESET Connection reset by peer (Соединение сброшено удаленной системой).

Существующее соединение принудительно закрыто удаленной стороной. Обычно это случается в случае неожиданного останова приложения на удаленной стороне, при перезагрузке удаленной машины, или в случае, когда удаленный хост использует «жесткое закрытие» ( setsockopt(SO_LINGER)) удаленного сокета.

2.5 По ссылке Socket error 10054 when testing email alerts описана ошибка и несколько возможных причин

This error happens when a connection is started (and working), but then closed by the other side of things before the SMTP conversation is completed

Источник

Irregular socket errors (10054) on Windows application

I am working on a Windows (Microsoft Visual C++ 2005) application that uses several processes running on different hosts in an intranet.

Processes communicate with each other using TCP/IP. Different processes can be on the same host or on different hosts (i.e. the communication can be both within the same host or between different hosts).

We have currently a bug that appears irregularly. The communication seems to work for a while, then it stops working. Then it works again for some time.

When the communication does not work, we get an error (apparently while a process was trying to send data). The call looks like this:

By inspecting the error code we get from

we see that it is an error 10054. Here is what I found in the Microsoft documentation (see here):

So, as far as I understand, the connection was interrupted by the receiving process. In some cases this error is (AFAIK) correct: one process has terminated and is therefore not reachable. In other cases both the sender and receiver are running and logging activity, but they cannot communicate due to the above error (the error is reported in the logs).

  • What does the SO_LINGER option mean?
  • What is a keep-alive activity and how can it break a connection?
  • How is it possible to avoid this problem or recover from it?

Regarding the last question. The first solution we tried (actually, it is rather a workaround) was resending the message when the error occurs. Unfortunately, the same error occurs over and over again for a while (a few minutes). So this is not a solution.

At the moment we do not understand if we have a software problem or a configuration issue: maybe we should check something in the windows registry?

One hypothesis was that the OS runs out of ephemeral ports (in case connections are closed but ports are not released because of TcpTimedWaitDelay), but by analyzing this issue we think that there should be plenty of them: the problem occurs even if messages are not sent too frequently between processes. However, we still are not 100% sure that we can exclude this: can ephemeral ports get lost in some way (. )

Another detail that might help is that sending and receiving occurs in each process concurrently in separate threads: are there any shared data structures in the TCP/IP libraries that might get corrupted?

What is also very strange is that the problem occurs irregularly: communication works OK for a few minutes, then it does not work for a few minutes, then it works again.

Thank you for any ideas and suggestions.

EDIT

Thanks for the hints confirming that the only possible explanation was a connection closed error. By further analysis of the problem, we found out that the server-side process of the connection had crashed / had been terminated and had been restarted. So there was a new server process running and listening on the correct port, but the client had not detected this and was still trying to use the old connection. We now have a mechanism to detect such situations and reset the connection on the client side.

Источник

socket error 10054

I have a C/S program. Client use socket to send a file to server, after send approximate more than 700k data, client(on win7) will receive a socket 10054 error which means Connection reset by peer.

Server worked on CentOS 5.4, client is windows7 virtual machine run in virtual box. client and server communicate via a virtual network interface. The command port(send log) is normal, but the data port(send file) have the problem. If it was caused by wrong configuration of socket buffer size or something else? If anyone can help me check the problem. Thanks.

Every time I call socket send a buffer equals 4096 byte send(socket, buffer, 4096, 0 )

READ  Raise exception cntl error

CentOS socket config.

I’m not quite understand what the socket buffer configuration means, if this will cause the receive incomplete result problem?

1 Answer 1

It’s almost definitely a bug in your code. Most likely, one side thinks the other side has timed out and so closes the connection abnormally. The most common way this happens it that you call a receive function to get data, but you actually already got that data and just didn’t realize it. So you’re waiting for data that you have already received and thus time out.

1) Client sends a message.

2) Client sends another message.

3) Server reads both messages but thinks it only got one, sends an acknowledge.

4) Client receives acknowledge, waits for second acknowledge which server will never send.

5) Server waits for second message which it actually already received.

Now the server is waiting for the client and the client is waiting for the server. The server was coded incorrectly and didn’t realize that it actually got two messages in one go. TCP does not preserve message boundaries.

If you tell me more about your protocol, I can probably tell you in more detail what went wrong. What constitutes a message? Which side sends when? Are there any acknowledgements? And so on.

But the short version is that each side is probably waiting for the other.

Most likely, the connection reset by peer is a symptom. Your problem occurs, one side times out and aborts the connection. That causes the other side to get a connection reset because the other side aborted the connection.

Источник

FTP socket error 10054 – Here’s how to fix this FTP connectivity error

I receive the ftp socket error 10054 when I try to connect to FTP for an upload. Please fix this problem.

That was a recent support ticket received from one of our customers as part of our Dedicated Support Services.

This FTP error occurs when the existing remote connection is forcibly closed by the remote host.

Today, let’s see the top 6 reasons for the ftp socket error 10054 and how our Support Engineers fix them.

FTP socket error 10054 – A Brief explanation

A socket is the endpoint of client-server communication.

FTP socket error 10054 indicates that the remote host has forcibly terminated or reset the existing connection of the FTP client. And, users see the complete error message as shown below.

This broken connection can be at the FTP server side or at the user’s side. So, our Support Engineers primarily check the server logs to determine if this is a network error at the client side or at the server side.

FTP socket error 10054 – Reasons & Solutions

Now, let’s see the main causes of this error and how our Support Engineers rule out each possibility to fix this problem.

1) Remote server issues

FTP socket error 10054 can occur due to the problems at the remote server end. This error usually occurs during the following scenarios.

  • The remote host is suddenly rebooted or restarted.
  • Network interface of the remote server is disabled.
  • User’s account on the remote server is disabled or restricted.
  • Too many users logged on to the server.
How we fix?

Firstly, our Support Experts check the availability of the remote host using the ping command.

In addition to that, we check the uptime of the server to verify that a reboot has been initiated on the server.

Thus, we can confirm whether the server reboot created problems for the user. Moreover, we ensure that the network settings on the server are intact and the FTP user is allowed to connect to the remote host.

2) Invalid FTP host

Once we’ve confirmed that there are no issues at the remote host, we then check the FTP client settings. And, one of the common reasons for this error is the use of invalid FTP host address.

Users should enter the hostname details in the FTP host field to initiate a connection. For example, customers usually give it as ftp.servername.com or servername.com.

However, a typo in the FTP hostname or missing hostname field can result in this error. Even a single additional space in the FTP hostname can create problems.

How we fix?

Firstly our Support Experts confirm the DNS connectivity of the FTP host using the dig command.

Further, we double check and confirm that customer is using the correct FTP host address in their FTP client.

3) Firewall restrictions

Similarly, firewalls can act up and break the FTP connection. Moreover, Antivirus or Antispyware tools can act as a second layer firewall and close the connections. Even the firewalls at the ISP end, firewall on a router can block connections through FTP ports.

How we fix?

In such cases, we ask the customers to temporarily disable the security applications such as Windows firewall, Antivirus, etc. one by one on their system. This helps us to identify the application that’s exactly creating problems and fix it’s settings.

Likewise, to resolve the firewall issues at the network level, our Support Engineers ask the customers to disable gateways and routers to establish a direct connection. Thus, we can verify if the problem lies at the intermediate level. Once we’ve confirmed that the problem is with the intermediate devices, we ask the customers to work with their ISPs to configure ISP firewall to allow connections to FTP ports.

4) Issues with File transfer mode

File transfer can happen in 2 types – Active and Passive mode, and most of the FTP clients use Passive mode by default. However, some remote servers accept the connections only in Active mode or PORT mode resulting in this error.

How we fix?

The steps to enable Active mode differs based on the FTP client software used by the customers.

READ  Keenetic air обновление прошивки

So, our Dedicated Engineers get the FTP client details from the users, and help them navigate the settings and enable Active mode. For example, we enable Active mode in Filezilla from Site Manager > Transfer settings > Transfer mode.

5) Connection timeout issues

Ftp socket error 10054 occurs when users try to upload relatively large files which conflict with the internal timeout settings of the FTP client. In other words, when user uploads a large file, the upload process may fail if it’s not completed within the predefined connection timeout limit.

How we fix?

In such cases, we recommend users to increase the connection timeout settings in their FTP client. For example, we increase the connection timeout limit from Edit > Settings > Connection > Timeout > Timeout in seconds.

Alternatively, in some cases we disable this timeout value by making it’s value as 0.

6) Advanced FTP client settings

Some of the FTP clients such as CuteFTP use advanced configurations which may not be compatible with the remote server you’re connecting. For example, some remote servers may be configured to allow only a limited number of connections or sessions. However, some users configure their FTP client to set large number of concurrent file transfers. In such cases, remote server terminates the connection and result in ftp socket error 10054.

Similarly, users set large values for send and receive buffer sizes in their FTP client settings. However, this may conflict with the remote server values and causes problems.

How we fix?

In such cases, our Dedicated Engineers help the customers navigate the FTP client settings and limit the number of concurrent connections. For example, on CuteFTP client, we change this parameter from Tools > Global options > Connection > Per site max concurrent transfers >Transfer.

Moreover, we tweak the send and receive buffer size values accordingly. For instance, we change the buffer size from Tools > Global options > Transfer in CuteFTP.

[Need help in resolving your FTP issue? Our Support Experts can help you here.]

Conclusion

In short, ftp socket error 10054 can occur due to remote server issues, firewall restrictions, and more. Today, we’ve discussed the top 6 reasons for this error and how our Dedicated Engineers fix them.

Источник

Socket error 10054 connection was reset by the other side

From: http://www.blogjava.net/pandawang/archive/2013/11/28/406922.html

WSAGetLastError May return 10053 Error, check msdn The explanation is:

Software caused connection abort .

An established connection was aborted by the software in your host computer, possibly due to a data transmission time-out or protocol error.

What? What is the meaning of the connection interruption caused by software? Isn’t it the same as not saying?
google chant

A connection abort was caused internal to your host machine. The software caused

a connection abort because there is no space on the socket’s queue and the socket

cannot receive further connections.

Partly the same as Berkeley. The error can occur when the local network system aborts

a connection. This would occur if WinSock aborts an established connection after data

retransmission fails (receiver never acknowledges data sent on a datastream socket).

A connection will timeout if the local system doesn’t receive an (ACK)nowledgement for

data sent. It would also timeout if a (FIN)ish TCP packet is not ACK’d

(and even if the FIN is ACK’d, it will eventually timeout if a FIN is not returned).

Berkeley said that this connection was interrupted because of the internal reason of the host machine. The connection interruption caused by the software may be because the queue of the socket is full and the socket cannot receive more connections.
This might as well not be said, the more confused the more.
The description of winsocket seems to be more reliable. This kind of error usually occurs when a connection established is retransmitted and the receiver does not send back the response data. But it is still relatively vague.
Look at the tcp ip standard document, if the local system does not receive a response (ack) to send data, then the connection will time out. If tcp’s fin packet is not acked (or fin packet is acked but fin did not return) then it will timeout. But, but, does timeout have anything to do with this 10053?
Look at the subsequent explanation:
Find the following description from Reference 1:

The Scenario:
An HTTP POST is to be sent to an HTTP server.
The server begins reading the POST and notices that the HTTP request header is invalid.
It immediately sends an HTTP response (with an error status, perhaps status=400) and closes the connection without trying to continue reading the remainder of the HTTP request that is forthcoming.

Meanwhile, the client is still happily writing the remainder of the HTTP request to the socket. (Remember a TCP/IP socket connection needs to be closed from both sides. In this case, the server has closed its side, but the client is still pumping data into the half-open connection.)
The client finishes writing the HTTP POST to the socket — meaning that data has been buffered to Winsock. The client application then tries to read the HTTP response, but it cannot because the outgoing retransmission (of the buffered data by WinSock) failed and the socket connection was shutdown on the client side (by Winsock). Even though the HTTP server sent the response, it is lost and cannot be retrieved. The error your application will receive when
trying to read the HTTP response on the socket is WSAECONNABORTED. The word «software» in any of the above error messages refers to «WinSock».

Go back and re-read the original error explanations. Hopefully, after that explanation, you’ll say «Aha! I understand what they’re talking about!».

Aha, there is http again, probably means that the http server received the request, but found that there is a problem, then return an http error code, and then close the socket, but at the same time, the client is still very happy to the socket Write data, pay attention, tcp is full-duplex. After the client writes, the data is actually placed in the sender’s buffer, and it may not have been sent out. If the program is not well written, the data will be read from the socket at this time, and a WSACONNECTABORTED will be generated at this time. Error, the corresponding 10053 error on windows.

READ  Opencv error capturing csv header

But this explanation is actually unsatisfactory. It just cites a scenario, but there is no explanation why it happened. A reference 2 was found later, first explaining the 10053 error is that the client will give up the data in the send buffer after receiving the fin and report the error at the same time. Although the argument is still a bit confused.

But these two references give us an idea to reproduce this problem.

So simply write a test c-s program, the approximate process is as follows

This simple program demonstrates how to get a 10053 error (and a 10054 error).

If the server closes the socket immediately after receiving the data sent by the client, the client will receive a 10053 error when it reads again; if the server crashes immediately after receiving the sent data, then the client will receive a 10054 error when it reads again.

ok Now that we can recreate the scene, let’s analyze the more detailed aspects. The network problem is naturally packet capture. In this problem, the packet capture also needs to look at the status of tcp for auxiliary analysis. We print it before each operation on the client side. Current tcp status.

The following is the client’s sending record and corresponding netstat situation

client Before sending, the tcp state is established. After sending, the server will immediately shut down, and the tcp state will also change to close_wait. recv will fail and return 10053. The corresponding packet capture situation is as follows:

The entire communication process is as follows:
1-3. Three-way handshake to establish a connection
4. The client (10.10.86.93) sends data to the server (10.10.86.98), 1 byte
5. The server stops sending fin (while pushing the ack before)
6.client ack that fin
7. The client sends two more bytes
8. The server has closed the socket at this time, which is an abnormal situation, and reply to the reset command

The whole process can reproduce the situation of 10053, and the situation of tcp sending packet data is also clear at a glance. Is this all right? Obviously not, you also see a lot of text in the back. I do n’t know if the problem in your heart is the same as mine. Let me talk about my own first. Through the packet capture, I found that there is a reset for the abnormal shutdown, but the reset is generally 10054 ( Connection reset by peer), what is the difference between 10053 and 10054. It is not difficult to figure out the problem, and focus on the scene analysis and analysis.
The following is the modification of the above cs program, crashes immediately after the 1-byte packet sent by the client, which causes the problem that the operating system will immediately recycle all resources, including socket resources

It can be seen that this tcp was established before the crash. After the crash, the client will receive a 10054 error when receiving data, the scene is reproduced, let’s look at the packet capture situation again

This packet capture situation is very similar to 10053. 1-7 is also the same as 10053. At 8 o’clock, the client receives a reset from the server, indicating that the current connection has been forcibly reset.
Comparing 10053 and 10054, we can find that if srv returns the fin flag and then reset, the corresponding error is 10053, and if it is directly reset, it is a 10054 error.
Looking back at the statement in Reference 2, I feel a little bit.

in conclusion:
1. Google is a very good method when you do n’t understand
2. For general problems, it is important to reproduce, you can repeatedly find the problem and verify the problem. Write your own program or try to reproduce the environment.
3. Network problem capture is a weapon, including the use of various tools such as netstat wireshark ping traceroute.
4. Compare the differences among multiple problems. Here we compare 10053 error and 10054 error.
5. The theoretical basis should be well established. This problem is mainly the problem of abnormal disconnection of tcp, and is familiar with the semi-closing and reset logic of tcp disconnection, but the theory is still the theory, and the error code of reset is different in different scenarios. And the implementation is also related to the specific operating system.
6. In actual work, 10053 When the error occurs, the user is mainly in the case of a transparent proxy. This is generally caused by the abnormal shutdown of the proxy server where the user is located, which may be caused by the rejection of our offline file private agreement by the proxy server where the user is located.

7. Looking back at the beginning of the explanation, the so-called connection terminal caused by software is the case in which the server side immediately shuts down the socket when transmitting in the shoutdown direction, which should have waited for the other party to send fin to completely end The normal logic is broken, and the programming is forced to abort this tcp in one direction, which causes the client to report an error afterwards, which is the so-called 10053 error. The software here is the program on the server side. (However, there is a saying that the client sends wrong data, which causes the server-side protection mechanism to be forced to close)

Источник

Smartadm.ru