Странный сброс TCP (RST) на некоторых HTTP-запросах - PullRequest
1 голос
/ 14 марта 2012

У нас есть приложение, написанное на Delphi, которое использует Delphi On Rails , работает как сервер и общается с клиентами, используя HTTP, JSON и веб-сокеты.В последнее время мы столкнулись с некоторыми проблемами, и их трудно отладить и найти источник проблемы.

Используя Wireshark для анализа трафика, мы можем увидеть следующее поведение: есть запрос от клиента (HTTP GET для файла),Обычно мы обрабатываем этот запрос и отправляем код состояния HTTP, файл (если не кэширован) и т. Д. Однако у нас есть воспроизводимая проблема, когда есть только запрос от клиента, TCP SYN с сервера, но после этогоСервер отправляет пакет RST, и связь TCP прекращается.

Странно то, что мы можем воспроизвести проблему довольно хорошо (хотя файлы, в которых пакет RST нарушает связь, различаются), и таинственным образом исчезает в одном изследующие случаи:

  • В среде отладки (Delphi IDE) отключение madExcept
  • В среде выпуска, не исправляя исполняемый файл с помощью madExceptPatch
  • Сделайте акцент на другом окне, отличном от основного окна приложения.

Поскольку у нас были некоторые проблемы с Delphi On Rails, и мы должны были внести в него небольшие изменения, чтобы избежать нарушений доступа и отладкиисключения, я подозреваю, что DOR является виновником некоторого странного повреждения памяти или не отслеживаемого исключениябыть ошибкой, но это все еще сбивает с толку, особенно тот факт, что проблема исчезает, если мы изменим фокус.

Мой главный вопрос не в том, как решить эту проблему, а в том, как ее отладить и где искать проблемы.,Источник сброса TCP также озадачивает меня, так как мы не сталкиваемся с обычными процедурами, которые обрабатывают запросы в этом случае, и кажется, что либо DOR, либо что-то еще (приложение, Winsock, OS) сбрасываетсясоединение по ошибке.

Для полноты, как это может быть связано, вот проблемы, о которых я сообщил в проекте Delphi On Rails, и в ветке форума, где я спросил автора madExcept о проблеме: Проблема# 6 , выпуск # 7 , выпуск № 8 , запись на форуме .

1 Ответ

2 голосов
/ 14 марта 2012

В качестве теста мы проверили некоторые более старые источники DOR из системы контроля версий, где не было известно ни о каких проблемах с подключением, и это работает, не показывая ни одной из перечисленных выше проблем.

Поэтому мы решили решить эту проблему другимнаоборот: откат исходного кода DOR (около 20 файлов) до последней стабильной версии и «повторное обновление» его по частям, пока ошибка не возникнет снова.Если это произойдет, мы можем

  1. Быстро вернуться к последней рабочей версии
  2. Надеемся, что мы будем достаточно близки к исходным источникам DOR, чтобы мы могли реагировать на обновления в библиотеке.
  3. Проанализируйте возникшую ошибку и сообщите подробный вопрос (и, возможно, даже решение) проекта DOR.

РЕДАКТИРОВАТЬ: Теперь мы можем обновить все файлы, кроме одного, до старого состояния безполучать проблемы с подключением.Файл, который создает проблемы, это dorSynchronizer.pas, точнее - r179 этого файла, который вызвал проблемы - потоки были изменены с Windows API на Delphi TThread.Мы исследуем это далее и, возможно, добавим проблему в проект DOR в ближайшие дни.

EDIT2: Оказалось, что DOR использует устаревшие процедуры TThread.Suspend и TThread.Resume, которые могут вызывать неопределенное поведение.Я сообщил о проблеме проекту DOR.

...