форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

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

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

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

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

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

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

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

	6. "Проверка связи на сокетах и проблема с доменом PF_UNIX"
	Сообщение от tolix on 05-Фев-04, 14:22  (MSK)
	>виноват ... сморозил >ошибка при выполнении unlink это нормально(её можно игнорировать). >ошибка возникает если при удалении файла - нечего удалять, есть при первом >старте программы, в дальнейшем если файло имеется всё нормально удаляется и >unlink молчит а Вы access не пытались перед вызовом unlink использовать ? ;) if(access(file,R_OK)==0) {     if(unlink(file)) perror("unlink"); }
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.