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.
Буду описывать здесь процесс выполнения различных работ.
Страницы
четверг, 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
Причины возникновения
Причины этой ошибки разняться по своей "природе", но их объединяето то, что уже существующее (т.е. ранее установленое) соединение с клиентом разрывает сервер.
1. С версии 8.1.11 включен циклический перезапуск процессов, по наступлению интервала происходит автоматический перезапуск рабочих процессов rphost.
2. В некоторых случаях причиной ошибки могут стать утечки памяти.
3. Действия администратора в консоли (команда удалить пользователя)
4. Процесс rphost на серверном компьютере завершился аварийно
5. Ошибочное принятие высокой интенсивности пользователей за атаку на протокол в некоторых случаях Windows
6. Устаревание данных в кэшах
7. Плохо отслеживаемые события в фоновых процессах
8. Нестандартные запросы могут приводить к падениям rphost
Способы устранения
1. с 8.1.11 включен циклический перезапуск процессов, для анализа этого события на компьютере сервера 1С:Предприятия необходимо включить запись в технологический журнал событий PROC (пример файла logcfg.xml).
Когда процесс выключается, будет выведено событие PROC со свойством Txt=Process become disable.
Когда процесс останавливается, будет выведено событие PROC со свойством Txt=Process terminated. Any clients finished with error. Если аварийные завершения работы пользователей совпадают по времени с выводом этого события, то причиной является принудительная остановка рабочего процесса либо администратором (через консоль кластера), либо вследствие автоматического перезапуска.
2. перезагрузить сервер
3. убедиться, что причиной являются/не являются действия администратора в консоли
4. создать на сервере приложения два или более рабочих процесса, чтобы иметь возможность переподключиться в случаи сбоя рабочего процесса
5. Запусти программу regedit.exe, добавь новое значение типа DWORD с именем SynAttackProtect в раздел реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters и присвой ему значение 00000000
Имеет смысл делать для ОС Windows 2003 SP1 (http://msdn.microsoft.com/ru-ru/library/ms189083.aspx).
6. arp -d *
ipconfig /flushdns
ipconfig /registerdns
nbtstat -R
nbtstat -RR
7. отключить фоновые процессы во всех базах
8. найти технологическим журналом запрос, приводящий к падению
p.s. Кроме того, 54 ошибку можно получить на релизах 81(SQL) в типовой ТиС (демо, взятой с ИТС) релиз. 954 в клиент-серверном варианте.
обойти можно так:
— выполните конвертацию в файловый фариант информационной базы 1С:Предприятия 8.1,
— выгрузите полученную информационную базу в файл,
— загрузите в клиент-серверный вариант информационной базы 1С:Предприятия 8.1.