Socket error 10054 connection reset by peer effector saver

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.

Источник

An application may receive the «10054» error when the application receives data from a connection on a computer that is running Windows 7 or Windows Server 2008 R2 if a TDI filter driver is installed

Symptoms

Consider the following scenario:

You have a computer that is running Windows 7 or Windows Server 2008 R2.

A Transport Driver Interface (TDI) filter driver is installed on the computer. For example, a TDI filter driver is installed when you install McAfee VirusScan.

An application opens a TCP listening port to receive connections.

In this scenario, the application may receive the following error message:

WSAECONNRESET (10054) Connection reset by peer.
A existing connection was forcibly closed by the remote host.

This issue occurs because the TCP/IP driver does not close an incomplete TCP connection. Instead, the TCP/IP driver sends a notification that the TCP/IP driver is ready to receive data when the incomplete TCP connection is created. Therefore, the application receives an instance of the 10054 error that indicates that a connection is reset when the application receives data from the connection.

Resolution

To resolve this issue, install this hotfix.

Note This hotfix temporarily resolves this issue for application vendors before they migrate their implementation to Windows Filtering Platform (WFP). These application vendors use the TDI filter driver or the TDI extension driver (TDX) on a computer that is running Windows 7 or Windows Server 2008 R2.

Hotfix information

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.

If the hotfix is available for download, there is a «Hotfix download available» section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.

Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site:

http://support.microsoft.com/contactus/?ws=supportNote The «Hotfix download available» form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.

Prerequisites

To apply this hotfix, you must be running Windows 7 or Windows Server 2008 R2.

Registry information

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 How to back up and restore the registry in WindowsTo enable the hotfix in this package, follow these steps:

In Registry Editor, locate the following registry subkey:

If you are running a 32-bit operating system, perform the following step:

Right-click the Parameters registry subkey, point to New, and then click DWORD Value.If you are running a 64-bit operating system, perform the following step:

Right-click the Parameters registry subkey, point to New, and then click DWORD (32-bit) Value.

Rename the new registry entry to TdxPrematureConnectIndDisabled and set the value to 1.

Restart requirement

You may have to restart the computer after you apply this hotfix.

Hotfix replacement information

This hotfix does not replace a previously released hotfix.

File information

The global version of this hotfix installs files that have the attributes that are listed in the following tables. The dates and the times for these files are listed in Coordinated Universal Time (UTC). The dates and the times for these files on your local computer are displayed in your local time together with your current daylight saving time (DST) bias. Additionally, the dates and the times may change when you perform certain operations on the files.

Windows 7 and Windows Server 2008 R2 file information notes

Important Windows 7 hotfixes and Windows Server 2008 R2 hotfixes are included in the same packages. However, hotfixes on the Hotfix Request page are listed under both operating systems. To request the hotfix package that applies to one or both operating systems, select the hotfix that is listed under «Windows 7/Windows Server 2008 R2» on the page. Always refer to the «Applies To» section in articles to determine the actual operating system that each hotfix applies to.

The MANIFEST files (.manifest) and the MUM files (.mum) that are installed for each environment are listed separately in the «Additional file information for Windows Server 2008 R2 and for Windows 7» section. MUM and MANIFEST files, and the associated security catalog (.cat) files, are extremely important to maintain the state of the updated components. The security catalog files, for which the attributes are not listed, are signed with a Microsoft digital signature.

Источник

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 )

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.

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.

Источник

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:

send(socket, (char *) data, (int) data_size, 0);

By inspecting the error code we get from

WSAGetLastError()

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

WSAECONNRESET
10054

Connection reset by peer.

An 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, the host or remote network interface is disabled, or the
remote host uses a hard close (see setsockopt for more information on the
SO_LINGER option on the remote socket). This error may also result if a
connection was broken due to keep-alive activity detecting a failure while
one or more operations are in progress. Operations that were in progress
fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.

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).

My questions.

• 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.

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.

Upload failed.
Socket Error # 10054
Connection reset by peer.

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.

ping test.remotehost.com

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

uptime

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.

dig ftp.servername.com

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.

[Messed up firewall rules on your server? Click here and get one of our Server Experts to fix your firewall rules.]

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.

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.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;