View previous topic :: View next topic |
Author |
Message |
GrAnd CMS Master
Joined: 21 Oct 2005 Posts: 766 Location: г. Коломна
|
Posted: 24 Apr 2013 15:49 (Wed) Post subject: Разрыв коннекта после некорректного ответа сервера. |
|
|
Обычный обмен SMTP-сервера с клиентом выглядит так:
===[CMSLog cut]===============8<----------------------------------------------
~24.04.2013 02:50:35 00NQ Thread started (TCsSMTPServer)
<24.04.2013 02:50:35 00NQ 220 [88.86.79.2] Courier Mail Server 3.01 ESMTP service ready
>24.04.2013 02:50:35 00NQ EHLO smtp.primacom.net
...
>24.04.2013 02:50:36 00NQ QUIT
<24.04.2013 02:50:36 00NQ 221 Service closing transmission channel
-24.04.2013 02:50:36 00NQ Отключился SMTP-клиент [217.68.186.240]
~24.04.2013 02:50:36 00NQ Thread stopped (TCsSMTPServer)
------------------------------>8===============================[CMSLog cut]===
Но иногда CMS вместо IP внешнего интерфейса подставляет нулевой адрес:
===[CMSLog cut]===============8<----------------------------------------------
~24.04.2013 15:12:35 014A Thread started (TCsSMTPServer)
<24.04.2013 15:12:35 014A 220 [0.0.0.0] Courier Mail Server 3.01 ESMTP service ready
-24.04.2013 15:12:35 014A Отключился SMTP-клиент [213.198.235.76]
~24.04.2013 15:12:35 014A Thread stopped (TCsSMTPServer)
!24.04.2013 15:12:35 014A Соединение разорвано удалённым хостом (10054)
------------------------------>8===============================[CMSLog cut]===
После чего соединение рвется по инициативе клиента.
Правда оно рвется иногда и при корректном ответе, но это, скорее, исключение. А вот при некорректном - всегда.
Проблема давнишняя. Просмотрел логи годовой давности. Она и тогда уже наблюдалась. _________________ Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец! |
|
Back to top |
|
|
NAMOR CMS Developer
Joined: 15 Oct 2005 Posts: 1079
|
Posted: 24 Apr 2013 18:34 (Wed) Post subject: |
|
|
Странная проблема... Ни разу не сталкивался. В исходниках не нашёл, где могла бы, даже теоретически, возникнуть такая ситуация.
Для каждого подключившегося клиента Windows создаёт новый сокет. CMS просто запрашивает у Windows локальный IP-адрес этого сокета и пользуется. Возможно, иногда сокет создаётся некорректно. В пользу этого предположения косвенно свидетельствует тот факт, что клиент сразу же отключается, хотя CMS отправляет ему нормальное приветствие (пусть даже и с нулевым IP-адресом).
В любом случае возьму ваше сообщение на заметку. |
|
Back to top |
|
|
GrAnd CMS Master
Joined: 21 Oct 2005 Posts: 766 Location: г. Коломна
|
Posted: 25 Apr 2013 12:03 (Thu) Post subject: |
|
|
Поднял самые старые сохранившиеся архивы логов, начиная с 2004 года.
В самых старых логах до середины 2008 года такой проблемы не было. Релей проходящей почты еще не использовался. В свойствах CMS было прописано его зарегистрированное DNS-имя хоста. От этого имени он и отвечал SMTP-клиенту при коннекте. Так что, проблемы не могли возникнуть в принципе.
С середины 2008 года стал использоваться антиспам SO-1024, как описано в http://www.courierms.ru/forum/viewtopic.php?t=1043
При этом, от имени хоста отвечал сам SО-1024 (на том же сервере, что и CMS, пропускал через себя всю почту, работая как ALG-прокси), поэтому настройки имени хоста в CMS не требовались. Он отвечал SO-1024 просто своим адресом "220 [127.0.0.1] ...".
Тогда проблемы были, но крайне редки. За полгода - считанные разы.
В конце января 2011 года была произведена массовая модернизация оборудования. Заменены сервера, операционки с Win2K на Win2K3, коммутационное оборудование. А так же SO-1024 стала вызываться как подключаемая dll, а не работать в качестве почтового шлюза. Но т.к. CMS на шлюзе предприятия не отправляет почту, а только служит релеем на внутренний почтовый сервер, то DNS-имя ему присвоено не было. Он отвечал IP-адресом при коннекте внешних клиентов.
И с этого момента понеслось ... Такие ошибки возникают ежедневно по много раз.
То ли Win2K3 Server SE виновата, то ли еще то сказывается, что на шлюзе большое число открытых вовне сокетов. Но возможно, в какой-то момент CMS не может корректно создать сокет для нового подключения извне. Вот соединение и рвется.
Может быть пытаться пересоздать сокет, если возникают такие проблемы?
Кстати, бывает клиенты тоже отваливаются с таким же кодом ошибке и при корректном ответе CMS. _________________ Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец! |
|
Back to top |
|
|
NAMOR CMS Developer
Joined: 15 Oct 2005 Posts: 1079
|
Posted: 25 Apr 2013 13:55 (Thu) Post subject: |
|
|
GrAnd wrote: | В конце января 2011 года была произведена массовая модернизация оборудования. Заменены сервера, операционки с Win2K на Win2K3, коммутационное оборудование. А так же SO-1024 стала вызываться как подключаемая dll, а не работать в качестве почтового шлюза. Но т.к. CMS на шлюзе предприятия не отправляет почту, а только служит релеем на внутренний почтовый сервер, то DNS-имя ему присвоено не было. Он отвечал IP-адресом при коннекте внешних клиентов.
И с этого момента понеслось ... Такие ошибки возникают ежедневно по много раз. |
Так. CMS обрабатывал подключения клиентов нормально. Заменили сервера, ОС, сетевое оборудование и т. д. CMS стал обрабатывать подключения ненормально. Если версия CMS при этом не менялась, то вывод, по-моему, можно сделать однозначный.
Хотя, даже если версия CMS и изменилась, проблему это вызвать не могло. Я сейчас специально сравнил между собой исходники модулей TCP-сервисов и сокет-библиотеки разных версий CMS. Для версий 2.09 — 2.12 эти модули побайтово идентичны, а в остальных версиях (вплоть до 2.04 вниз и до 3.01 вверх) изменения минимальны и не имеют отношения к приёму клиентский подключений. Конкретно, функция принимающая от Windows сокет с клиентским подключением, начиная с CMS 2.04 вообще ни разу не менялась.
GrAnd wrote: | Но возможно, в какой-то момент CMS не может корректно создать сокет для нового подключения извне. Вот соединение и рвется.
Может быть пытаться пересоздать сокет, если возникают такие проблемы? |
Сокет создаёт не CMS, а сама Windows, CMS только сообщает ей, что готов принять подключение и получает в распоряжение готовый сокет, к которому уже подключён клиент. Соответственно, пересоздать такой сокет со стороны CMS невозможно (во всяком случае, я не представляю как это можно сделать).
GrAnd wrote: | Кстати, бывает клиенты тоже отваливаются с таким же кодом ошибке и при корректном ответе CMS. |
Кроме вас никто больше о такой ошибке нам не сообщал. И в присылаемых в техподдержку журналах я не замечал такой проблемы.
Вполне возможно, что эти сбои с подключениями у вас происходят по вине какого-то внешнего приложения, проверяющего (пересылающего) трафик, или из-за проблем с сетью (сетевым оборудованием). Или влияет какое-то другое звено из числа заменённых при массовой модернизации оборудования. |
|
Back to top |
|
|
GrAnd CMS Master
Joined: 21 Oct 2005 Posts: 766 Location: г. Коломна
|
Posted: 25 Apr 2013 15:59 (Thu) Post subject: |
|
|
Все же разрывы связи были и раньше. Иногда чаще, иногда реже. Поэтому, возникновение ошибки 10054 и не настораживало - считал, что это спамерские проги сами отваливаются.
Например, вот еще до модернизации (еще использовалась SO-1024 в виде полупрозрачного шлюза):
+29.11.2010 12:04:07 0001 Подключился SMTP-клиент [127.0.0.1]
~29.11.2010 12:04:07 0DB5 Thread started (TCsSMTPServer)
<29.11.2010 12:04:07 0DB5 220 [127.0.0.1] Courier Mail Server 2.07 ESMTP service ready
>29.11.2010 12:04:07 0DB5 EHLO lxqdhj.com
<29.11.2010 12:04:07 0DB5 250-[127.0.0.1] greets lxqdhj.com
<29.11.2010 12:04:07 0DB5 250-SIZE
<29.11.2010 12:04:07 0DB5 250-AUTH PLAIN LOGIN CRAM-MD5
<29.11.2010 12:04:07 0DB5 250 8BITMIME
>29.11.2010 12:04:07 0DB5 MAIL FROM:<konstancija.chuprina@awcantwerp.org>
<29.11.2010 12:04:07 0DB5 250 OK, sender - <konstancija.chuprina@awcantwerp.org>
>29.11.2010 12:04:08 0DB5 RCPT TO:<egorov@teplo.kolomna.ru>
<29.11.2010 12:04:08 0DB5 250 OK, recipient - <egorov@teplo.kolomna.ru>
>29.11.2010 12:04:08 0DB5 DATA
<29.11.2010 12:04:08 0DB5 354 Send data. End with CRLF.CRLF
!29.11.2010 12:04:13 0DB5 Соединение разорвано удалённым хостом (10054)
-29.11.2010 12:04:13 0DB5 Отключился SMTP-клиент [127.0.0.1]
~29.11.2010 12:04:13 0DB5 Thread stopped (TCsSMTPServer)
В этом случае перед отвалом кое какой обмен происходил.
А вот сегодня:
===[CMSLog cut]===============8<----------------------------------------------
~01.05.2012 17:04:59 06IO Thread started (TCsSMTPServer)
<01.05.2012 17:04:59 06IO 220 [88.86.79.2] Courier Mail Server 2.10 ESMTP service ready
-01.05.2012 17:04:59 06IO Отключился SMTP-клиент [119.199.231.39]
~01.05.2012 17:04:59 06IO Thread stopped (TCsSMTPServer)
!01.05.2012 17:04:59 06IO Соединение разорвано удалённым хостом (10054)
------------------------------>8===============================[CMSLog cut]===
Адрес был корректным в ответе, но соединение всё равно разорвалось. _________________ Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец! |
|
Back to top |
|
|
NAMOR CMS Developer
Joined: 15 Oct 2005 Posts: 1079
|
Posted: 25 Apr 2013 18:33 (Thu) Post subject: |
|
|
GrAnd wrote: | >29.11.2010 12:04:08 0DB5 DATA
<29.11.2010 12:04:08 0DB5 354 Send data. End with CRLF.CRLF
!29.11.2010 12:04:13 0DB5 Соединение разорвано удалённым хостом (10054) |
Налицо явное вмешательство извне в обмен между CMS и клиентом (если считать, что клиент не сам отключился). Ну не рвёт CMS просто так соединение. Тем более в процессе приёма данных письма (там просто цикл построчного приёма и сохранения в файл). Да и ошибка "Соединение разорвано удалённым хостом" говорит о том, что либо сам клиент отключился, либо отключился кто-то посередине (кого CMS принимает за клиента).
Сколько нам уже писали по такой проблеме... И в техподдержку и на форум. В большинстве случаев выяснялось, что виновата внешняя программа (типичные случаи: Outpost, UserGate, NOD32, Panda). В остальных случаях клиенты уходили "в никуда" и до конца разобраться не удавалось.
Внешняя программа "вклинивается" между CMS и клиентом и начинает проверять почтовый трафик. На очередном письме её "клинит" и она либо вешает сессию, либо начинает тормозить, либо рвёт соединение. И вложения может портить.
Проходили такое и не один раз.
У PWL, помнится, Outpost иногда вообще перезагружал компьютер (именно из-за передачи почты).
Пару раз, припоминаю, даже в "железе" была проблема (в роутере, вроде). |
|
Back to top |
|
|
GrAnd CMS Master
Joined: 21 Oct 2005 Posts: 766 Location: г. Коломна
|
Posted: 25 Apr 2013 18:36 (Thu) Post subject: |
|
|
NAMOR wrote: | ... типичные случаи: Outpost, UserGate, NOD32, Panda ... |
А вот это уже идея. Как раз тогда на шлюз поставили NOD32. _________________ Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец! |
|
Back to top |
|
|
GrAnd CMS Master
Joined: 21 Oct 2005 Posts: 766 Location: г. Коломна
|
Posted: 26 Apr 2013 11:25 (Fri) Post subject: |
|
|
Установил CMS на другой сервер. Не помогло.
Отключил антивирус, внес небольшие изменения в настройки сервера (которые, впрочем, влиять не могут). Пока что 2 часа полет нормальный. Но это еще ничего не значит. _________________ Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец! |
|
Back to top |
|
|
GrAnd CMS Master
Joined: 21 Oct 2005 Posts: 766 Location: г. Коломна
|
Posted: 29 Apr 2013 10:57 (Mon) Post subject: |
|
|
При отключенном NOD32 проработало 3 суток (правда, 2 из них - выходные) без возникновения этой ошибки.
Буду поэтапно включать антивирь. Может быть, всё же не в нем дело. _________________ Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец! |
|
Back to top |
|
|
GrAnd CMS Master
Joined: 21 Oct 2005 Posts: 766 Location: г. Коломна
|
Posted: 06 May 2013 8:54 (Mon) Post subject: |
|
|
Включил в NOD32 защиту файлов в реальном времени -вроде бы она влиять не должна. Оставил выключенной защиту Интернета и почтового клиента. Хотя и не понятно, как защита клиента может влиять на создание серверных сокетов ...
Пару дней работало без ошибок. Но за праздничные дни 1-5 мая проскочило 7 случаев создания нулевого сокета. Немного, по сравнению с тем, что было раньше и на другом сервере, но все же (( _________________ Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец! |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|