URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID9
Нить номер: 2306
[ Назад ]
Исходное сообщение
"Проверка связи на сокетах и проблема с доменом PF_UNIX"
Отправлено FrOdO , 20-Ноя-03 10:45 
Всем привет.

Есть два вопроса.

1. Я использовал класс sock из книги Чана "Системное программирование на C++ для UNIX". На его основе я создаю сервер и клиент. Интерсено, что при использовании домена PF_UNIX, создаваемый файл, после выполнения shutdown() и close() на сокете, не удаляется, и при следующем вызове мой демон не может стартовать, пока не удалю этот файл. Так должно быть или нет? Правда я не пробовал создавать клиента из книги, а сразу делал свой демон. Никто не сталкивался с данной проблемой?

2. Можно ли как-нибудь проверить со стороны сервера, а есть ли соединение с клиентом, чтобы определить когда следует выходить из цикла чтения данных из сокета. Единственное, что мне приходит на ум, сделать некий протокол обмена с завершающей командой. Но это не решит проблемы при разрыве связи с клиентом. Насколько я понял, команда recv будет ждать данных, пока не получит хоть байт.

Заранее благодарю за ответы.

Содержание
Сообщения в этом обсуждении
"Проверка связи на сокетах и проблема с доменом PF_UNIX"
Отправлено aixd , 20-Ноя-03 12:50 
>Всем привет.
>
>Есть два вопроса.
>
>1. Я использовал класс sock из книги Чана "Системное программирование на C++
>для UNIX". На его основе я создаю сервер и клиент. Интерсено,
>что при использовании домена PF_UNIX, создаваемый файл, после выполнения shutdown() и
>close() на сокете, не удаляется, и при следующем вызове мой демон
>не может стартовать, пока не удалю этот файл. Так должно быть
>или нет? Правда я не пробовал создавать клиента из книги, а
>сразу делал свой демон. Никто не сталкивался с данной проблемой?
>
>2. Можно ли как-нибудь проверить со стороны сервера, а есть ли соединение
>с клиентом, чтобы определить когда следует выходить из цикла чтения данных
>из сокета. Единственное, что мне приходит на ум, сделать некий протокол
>обмена с завершающей командой. Но это не решит проблемы при разрыве
>связи с клиентом. Насколько я понял, команда recv будет ждать данных,
>пока не получит хоть байт.
>
>Заранее благодарю за ответы.


1:
  Перед вызовом bind нужно написать:
  unlink("/tmp/your.sock");

"Проверка связи на сокетах и проблема с доменом PF_UNIX"
Отправлено Dmitry , 28-Ноя-03 22:55 
>>Всем привет.
>>
>>Есть два вопроса.
>>
>>1. Я использовал класс sock из книги Чана "Системное программирование на C++
>>для UNIX". На его основе я создаю сервер и клиент. Интерсено,
>>что при использовании домена PF_UNIX, создаваемый файл, после выполнения shutdown() и
>>close() на сокете, не удаляется, и при следующем вызове мой демон
>>не может стартовать, пока не удалю этот файл. Так должно быть
>>или нет? Правда я не пробовал создавать клиента из книги, а
>>сразу делал свой демон. Никто не сталкивался с данной проблемой?
>>
>>2. Можно ли как-нибудь проверить со стороны сервера, а есть ли соединение
>>с клиентом, чтобы определить когда следует выходить из цикла чтения данных
>>из сокета. Единственное, что мне приходит на ум, сделать некий протокол
>>обмена с завершающей командой. Но это не решит проблемы при разрыве
>>связи с клиентом. Насколько я понял, команда recv будет ждать данных,
>>пока не получит хоть байт.
>>
>>Заранее благодарю за ответы.
>
>
>1:
>  Перед вызовом bind нужно написать:
>  unlink("/tmp/your.sock");

почитай другую книгу. например "Программирование сетевых приложений в среде Линукс". Там тебе нрмально расскажут что и как в сокетах.

"Проверка связи на сокетах и проблема с доменом PF_UNIX"
Отправлено Jess , 29-Ноя-03 03:22 
>Всем привет.
>
>Есть два вопроса.
>
>1. Я использовал класс sock из книги Чана "Системное программирование на C++
>для UNIX". На его основе я создаю сервер и клиент. Интерсено,
>что при использовании домена PF_UNIX, создаваемый файл, после выполнения shutdown() и
>close() на сокете, не удаляется, и при следующем вызове мой демон
>не может стартовать, пока не удалю этот файл. Так должно быть
>или нет? Правда я не пробовал создавать клиента из книги, а
>сразу делал свой демон. Никто не сталкивался с данной проблемой?

aixd прав на счет функции unlink, она всегда выполняется с ошибкой на сколько Я помню, это нормально для unlink
>
>2. Можно ли как-нибудь проверить со стороны сервера, а есть ли соединение
>с клиентом, чтобы определить когда следует выходить из цикла чтения данных
>из сокета. Единственное, что мне приходит на ум, сделать некий протокол
>обмена с завершающей командой. Но это не решит проблемы при разрыве
>связи с клиентом. Насколько я понял, команда recv будет ждать данных,
>пока не получит хоть байт.
>
смотря какой сокет используеш(блокируемый или нет), по всей видимости дескриптор на сокете у тебя по дефолту а значит будет ждать хоть байта.
а на счет конекта на тачке, в этом поможет тебе netstat

"Проверка связи на сокетах и проблема с доменом PF_UNIX"
Отправлено Dvorkin , 29-Ноя-03 15:22 
>>Всем привет.
>>
>>Есть два вопроса.
>>
>>1. Я использовал класс sock из книги Чана "Системное программирование на C++
>>для UNIX". На его основе я создаю сервер и клиент. Интерсено,
>>что при использовании домена PF_UNIX, создаваемый файл, после выполнения shutdown() и
>>close() на сокете, не удаляется, и при следующем вызове мой демон
>>не может стартовать, пока не удалю этот файл. Так должно быть
>>или нет? Правда я не пробовал создавать клиента из книги, а
>>сразу делал свой демон. Никто не сталкивался с данной проблемой?
>
>aixd прав на счет функции unlink, она всегда выполняется с ошибкой на
>сколько Я помню, это нормально для unlink
??? не правда. любой системный вызов должен возвращать суксесс если используются настройки по умолчанию например для сокетов. При неблокируемом вводе-выводе на сокете функция может возвращать и иное значение (например EWOULDBLOCK). В данном случае если unlink возвращает не нуль - это ошибка в программе.

>>
>>2. Можно ли как-нибудь проверить со стороны сервера, а есть ли соединение
>>с клиентом, чтобы определить когда следует выходить из цикла чтения данных
>>из сокета. Единственное, что мне приходит на ум, сделать некий протокол
>>обмена с завершающей командой. Но это не решит проблемы при разрыве
>>связи с клиентом. Насколько я понял, команда recv будет ждать данных,
>>пока не получит хоть байт.
>>
>смотря какой сокет используеш(блокируемый или нет), по всей видимости дескриптор на сокете
>у тебя по дефолту а значит будет ждать хоть байта.
>а на счет конекта на тачке, в этом поможет тебе netstat
тоже глупости. первое что я бы сделал - это аккуратно проверял все возвращаемые начения и перед соединением установил опцию SO_LINGER на сокете, ну возможно еще что-нибудь чтоб сообщение об отсутствии связи (в случае ТСП) приходило как можно скорей. естественно чтобы все было более контролируемо просто необходимо использовать либо сигнальный ввод/вывод, либо селект, либо неблокируемый. По умолчанию действительно сокет тормозит рекв до первого поступившего байта. Если возникает рассоединение то это обнаруживается не сразу. Рецепт дан выше.

WBR, Dvorkin

"Проверка связи на сокетах и проблема с доменом PF_UNIX"
Отправлено Jess , 02-Дек-03 05:23 
>>aixd прав на счет функции unlink, она всегда выполняется с ошибкой на
>>сколько Я помню, это нормально для unlink
>??? не правда. любой системный вызов должен возвращать суксесс если используются настройки
>по умолчанию например для сокетов. При неблокируемом вводе-выводе на сокете функция
>может возвращать и иное значение (например EWOULDBLOCK). В данном случае если
>unlink возвращает не нуль - это ошибка в программе.
виноват ... сморозил
ошибка при выполнении unlink это нормально(её можно игнорировать).
ошибка возникает если при удалении файла - нечего удалять, есть при первом старте программы, в дальнейшем если файло имеется всё нормально удаляется и unlink молчит
>
>>>
>>>2. Можно ли как-нибудь проверить со стороны сервера, а есть ли соединение
>>>с клиентом, чтобы определить когда следует выходить из цикла чтения данных
>>>из сокета. Единственное, что мне приходит на ум, сделать некий протокол
>>>обмена с завершающей командой. Но это не решит проблемы при разрыве
>>>связи с клиентом. Насколько я понял, команда recv будет ждать данных,
>>>пока не получит хоть байт.
>>>
>>смотря какой сокет используеш(блокируемый или нет), по всей видимости дескриптор на сокете
>>у тебя по дефолту а значит будет ждать хоть байта.
>>а на счет конекта на тачке, в этом поможет тебе netstat
>тоже глупости. первое что я бы сделал - это аккуратно проверял все
>возвращаемые начения и перед соединением установил опцию SO_LINGER на сокете, ну
>возможно еще что-нибудь чтоб сообщение об отсутствии связи (в случае ТСП)
>приходило как можно скорей. естественно чтобы все было более контролируемо просто
>необходимо использовать либо сигнальный ввод/вывод, либо селект, либо неблокируемый. По умолчанию
>действительно сокет тормозит рекв до первого поступившего байта. Если возникает рассоединение
>то это обнаруживается не сразу. Рецепт дан выше.
>
>WBR, Dvorkin


"Проверка связи на сокетах и проблема с доменом PF_UNIX"
Отправлено tolix , 05-Фев-04 14:22 
>виноват ... сморозил
>ошибка при выполнении unlink это нормально(её можно игнорировать).
>ошибка возникает если при удалении файла - нечего удалять, есть при первом
>старте программы, в дальнейшем если файло имеется всё нормально удаляется и
>unlink молчит


а Вы access не пытались перед вызовом unlink использовать ? ;)

if(access(file,R_OK)==0) {
    if(unlink(file)) perror("unlink");
}