TcpClient.Client.Connected свойство

@Cupko · Регистрация: 17.07.2012

Студворк — интернет-сервис помощи студентам

Здравствуйте, господа.

Возникла довольно странная ситуация: проверка состояния сокета занимает ощутимое время. StopWatch показывает от 0 до 1700! мс. (только на if (TcpClient.Client.Connected) {})

Тем не менее, даже визуально заметны подвисания с проверкой по сравнению с выполнением без проверки.

Может мне кто объяснить данную ситуацию, и подсказать как всё-таки проверять состояние сокета?

@ksk · 25.01.2014, 21:33

Если связь потеряна, то при попытке чтения / записи сразу же вылетает исключение. Может быть при дальней связи исключение случится только по истечении таймаута, который задаётся в свойствах сокета, я дальней связи не пробовал.

Пример того, как я это делал:
Чтение осуществлял в бесконечном цикле в отдельном потоке, тогда мы если что сразу узнаем о потере связи и сможем переконнектиться. Читал в трукаче, в случае исключения вызывал делегат, подписчик которого пытался заданное настройками количество раз восстановить соединение и возвращал результат обратно в цикл. Если соединение не удавалось восстановить таким образом, я выходил из цикла чтения и соответствующим образом менял статус объекта.

@Cupko · 27.01.2014, 08:32 **[ТС]**

У меня изначально отсутствовали проверки, было просто обвёрнуто в try-catch.

Но ситуация следующая:
На машине запускается несколько экземпляров приложения (что-то типа прокси), и когда, например, пропадает соединение с интернетом - на всех приложениях вылетает SocketException - и ОС уходит в BSOD.

После того как я добавил проверку, всё стало нормально, но сама проверка занимает ощутимое время.

Новые блоги и статьи Все статьи Все блоги /
Оптимизация кода на разграничение прав доступа к элементам формы Maks 13.04.2026 Алгоритм из решения ниже реализован на нетиповом документе, разработанного в конфигурации КА2. Задачи, как таковой, поставлено не было, проделанное ниже исключительно моя инициатива. Было так:. . .	Контроль заполнения и очистка дат в зависимости от значения перечислений Maks 12.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: реализовать контроль корректности заполнения дат назначения. . .	Архитектура слоя интернета для сервера-слоя. Hrethgir 11.04.2026 В продолжение https:/ / www. cyberforum. ru/ blogs/ 223907/ 10860. html Знаешь что я подумал? Раз мы все источники пишем в голове ветки, то ничего не мешает добавить в голову такой источник, который сам. . .	Подстановка значения реквизита справочника в табличную часть документа Maks 10.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: при выборе сотрудника (справочник Сотрудники) в ТЧ документа. . .
Очистка реквизитов документа при копировании Maks 09.04.2026 Алгоритм из решения ниже применим как для типовых, так и для нетиповых документов на самых различных конфигурациях. Задача: при копировании документа очищать определенные реквизиты и табличную. . .	модель ЗдравоСохранения 8. Подготовка к разному выполнению заданий anaschu 08.04.2026 https:/ / github. com/ shumilovas/ med2. git main ветка * содержимое блока дэлэй из старой модели теперь внутри зайца новой модели 8ATzM_2aurI	Блокировка документа от изменений, если он открыт у другого пользователя Maks 08.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в конфигурации КА2. Задача: запретить редактирование документа, если он открыт у другого пользователя. / / . . .	Система безопасности+живучести для сервера-слоя интернета (сети). Двойная привязка. Hrethgir 08.04.2026 Далее были размышления о системе безопасности. Сообщения с наклонным текстом - мои. А как нам будет можно проверить, что ссылка наша, а не подделана хулиганами, которая выбросит на другую ветку и. . .

@Cupko 658 / 595 / 171 Регистрация: 17.07.2012 Сообщений: 1,682 Записей в блоге: 1

	TcpClient.Client.Connected свойство 24.01.2014, 21:57. Показов 963. Ответов 2 Метки нет (Все метки) Здравствуйте, господа. Возникла довольно странная ситуация: проверка состояния сокета занимает ощутимое время. StopWatch показывает от 0 до 1700! мс. (только на if (TcpClient.Client.Connected) {}) Тем не менее, даже визуально заметны подвисания с проверкой по сравнению с выполнением без проверки. Может мне кто объяснить данную ситуацию, и подсказать как всё-таки проверять состояние сокета? 0

@ksk 624 / 495 / 43 Регистрация: 05.07.2010 Сообщений: 1,589
	25.01.2014, 21:33
	Если связь потеряна, то при попытке чтения / записи сразу же вылетает исключение. Может быть при дальней связи исключение случится только по истечении таймаута, который задаётся в свойствах сокета, я дальней связи не пробовал. Пример того, как я это делал: Чтение осуществлял в бесконечном цикле в отдельном потоке, тогда мы если что сразу узнаем о потере связи и сможем переконнектиться. Читал в трукаче, в случае исключения вызывал делегат, подписчик которого пытался заданное настройками количество раз восстановить соединение и возвращал результат обратно в цикл. Если соединение не удавалось восстановить таким образом, я выходил из цикла чтения и соответствующим образом менял статус объекта. 0

@Cupko 658 / 595 / 171 Регистрация: 17.07.2012 Сообщений: 1,682 Записей в блоге: 1
	27.01.2014, 08:32 [ТС]
	У меня изначально отсутствовали проверки, было просто обвёрнуто в try-catch. Но ситуация следующая: На машине запускается несколько экземпляров приложения (что-то типа прокси), и когда, например, пропадает соединение с интернетом - на всех приложениях вылетает SocketException - и ОС уходит в BSOD. После того как я добавил проверку, всё стало нормально, но сама проверка занимает ощутимое время. 0