Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: error writing to socket: bad file descriptor
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > Программирование
robix
Всем привет!

Написал сервер в Linux, который с большой скоростью, сотни мегабит, передает поток клиенту.
В общем все работает хорошо за исключением одного но: если во время передачи большого потока
вырубить клиента, то сервер падает с выдачей сообщения:
error writing to socket bad file descriptor

Перед каждым вызовом функции write или send проверяю состояние сокета, после отправки тоже проверка.
В свойствах send ставил флаг MSG_NOSIGNAL, тоже не помогает.

Коллеги, помогите чем можете!!!

gerber
Цитата(robix @ May 29 2015, 18:59) *
Коллеги, помогите чем можете!!!

Если клиент закрыл TCP-сокет - серверу уже ничем не помочь! biggrin.gif
Падать не нужно, нужно просто корректно обрабатывать эту ситуацию - например, прекращать передачу и тоже закрывать файловый дескриптор сокета. Достаточно проанализировать значение, возвращаемое функцией send (write).
А проверять до и после состояние сокета смысла никакого нет.
krux
зависит от операционки, настроек среды, протокола (TCP/UDP) и пр.

проверять состояние сокета до отправки данных - вообще нет смысла. операционка не обновляет состояние тех структур, которые вы пытаетесь читать.
дальше после вызова send(), проверять состояние сокета.

если у вас TCP, то предполжу, что:
- закончился сокет-буфер операционки, поскольку клиент отрубился без оповещения (не послал FIN) и TCP-стек ждёт 2 минуты после последнего ACK
т.е. вы не ждёте того кода ошибки сокета, который вам возвращает операционка, не обрабатываете его, вместо этого тупо пытаетесь молотить данные дальше.
gerber
Цитата(krux @ May 29 2015, 21:00) *
если у вас TCP, то предполжу, что:
- закончился сокет-буфер операционки, поскольку клиент отрубился без оповещения (не послал FIN) и TCP-стек ждёт 2 минуты после последнего ACK

Судя по тексту ошибки, вынесенной в название темы, клиент как раз отрубился корректно (т. е. послал FIN и закрыл соединение), возможно, это сделала не сама программа-клиент, а операционка при завершении программы-клиента, закрывая все открытые им файловые дескрипторы и сокеты в том числе. На стороне сервера, получив FIN, стек TCP/IP тоже закрыл соединение, поэтому производить какие-то операции с закрытым дескриптором нельзя, что и видим. Просто это нужно учитывать и обрабатывать корректно, а не молотить и сносить уже освобожденные буфера.
robix
Спасибо, коллеги!
Ваша убедительность дала результат.
Оказывается проверял возврат send на отрицательные значения, но не на ноль.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.