Проверка существования подключения к Socket Server со стороны клиента

Сбросил.

Цитата medved_68 @ 15.04.13, 12:11

Цитата apprentice @ 15.04.13, 11:36

Только не сочтите за наглость но не могли бы Вы выложить текст данного юнита целиком.

Мыло в приват - сброшу.

Спасибо за то что показали правильно решение

medved_68 ознакомился с Вашим юнитом - осознал свою никчёмность ; Но когда я сегодня забрал дивайс под который я писал софтину осознание никчёмности усилилось. Этот сервер работает только с одним клиентом . А у меня в проге как раз один клиент из нитки проверял подключение, а другой ждет события в не блокируемом режиме. Да и реакция на отключение сервера секунд 30. Ваш код не проверял хочу спросить Вашего разрешения или если Вы считаете что результат будет тот же подскажите как еще можно проверить связь. Благодарю за то что дочитали этот текст до конца .

Цитата apprentice @ 16.04.13, 14:22

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

А вот отсюда по подробнее. Клиенты на разных портах сидят? Или на одном, сначала отработает один, закроет сокет, потом другой?

medved_68 Да нет они на одном порту висят но один в потоке, а второй просто висит. Тот что в потоке в синхронном и просто подключался отключался (тестил связь). Второй в асинхронном просто ждет события онРиад. Когда связь обрывалась и появлялась поток на это реагировал переподключая асинхронный сокет. Ну вощим пока я писал эту софтину и не было дивайса я сокет сервер держал на компе и все работало. И реагировало почти моментально, а сейчас увы.

Цитата apprentice @ 16.04.13, 16:00

Да нет они на одном порту висят но один в потоке, а второй просто висит.

Весьма занятно. Занятно то, что система не позволит корректно открыть второй сокет на занятом порту, вернув код либо 10048, либо 10056. Поэтому вариант может быть только один - ты не проверяешь результат выполнения функции.

Цитата apprentice @ 16.04.13, 16:00

Когда связь обрывалась и появлялась поток на это реагировал переподключая асинхронный сокет.

Зачем? Первая же операция запись/чтение в/из сокета при обрыве связи вернет ошибку. Необходимо ее корректно обработать и переподключиться. Или дождаться восстановления линка и переподключиться. Зачем ты так "завернул"?

Цитата medved_68 @ 16.04.13, 17:02

Зачем? Первая же операция запись/чтение в/из сокета при обрыве связи вернет ошибку. Необходимо ее корректно обработать и переподключиться. Или дождаться восстановления линка и переподключиться. Зачем ты так "завернул"?

сокет кдиент тока принимает

Цитата apprentice @ 16.04.13, 17:08

сокет кдиент тока принимает

Он и отправлять данные тоже может. А если он работает только на прием, то что мешает периодически (по таймеру) отправлять что то? И анализировать, сколько байт отправлено... Ведь если нет канала (ну обрыв, всяко бывает) - ошибка отправки гарантирована и можно принимать решение - как жить дальше.

Цитата medved_68 @ 16.04.13, 17:12

Цитата apprentice @ 16.04.13, 17:08

сокет кдиент тока принимает

Он и отправлять данные тоже может. А если он работает только на прием, то что мешает периодически (по таймеру) отправлять что то? И анализировать, сколько байт отправлено... Ведь если нет канала (ну обрыв, всяко бывает) - ошибка отправки гарантирована и можно принимать решение - как жить дальше.

Дык говорю же там дивайс. Не надо ему было сообщения слать. А я как то об этом не думал чтоб так тэстить или он включён. Попробую. Сработает не сработает не знаю но все равно Вам спасибо

Цитата apprentice @ 16.04.13, 17:19

Дык говорю же там дивайс. Не надо ему было сообщения слать.

Ты не ему сообщения шлешь. Стэк TCP/IP так устроен, что пришлет подтверждение ДОСТАВКИ пакета с флагом АСК. А твой девайс просто пакет проигнорирует и все. Но подтверждение получения пакета на той стороне ты получишь, а значит можно сделать вывод, что канал жив. Таким же образом работает и keep-alive пакеты. Таким же образом "проламывают" для ВХОДЯЩЕЙ связи NAT всякие Астериски и Скайпы...

Цитата medved_68 @ 16.04.13, 17:31

Цитата apprentice @ 16.04.13, 17:19

Дык говорю же там дивайс. Не надо ему было сообщения слать.

Ты не ему сообщения шлешь. Стэк TCP/IP так устроен, что пришлет подтверждение ДОСТАВКИ пакета с флагом АСК. А твой девайс просто пакет проигнорирует и все. Но подтверждение получения пакета на той стороне ты получишь, а значит можно сделать вывод, что канал жив. Таким же образом работает и keep-alive пакеты. Таким же образом "проламывают" для ВХОДЯЩЕЙ связи NAT всякие Астериски и Скайпы...

ну по поводу просто проигнорирует то не совсем он плюнул в ответ. а о том что дивайс отключён я узнал через 20 сек примерно. Снизу привожу код отправки. Отправляю служебные коды дивайся поэтому выглядят чутка дико.

procedure TKpp.ding(Sender: TObject);
  var Bufs:array[1..14] of byte;
begin
  bufS[1]:=30;
  bufS[2]:=5;
  bufS[3]:=5;
  bufS[4]:=0;
  bufS[5]:=0;
  bufS[6]:=0;
  bufS[7]:=0;
  bufS[8]:=0;
  bufS[9]:=0;
  bufS[10]:=0;
  bufS[11]:=0;
  bufS[12]:=0;
  bufS[13]:=0;
  bufS[14]:=0;
 
  output.Socket.SendBuf(BufS,14)
 
end;

событие онИррор возникло спустя 20 сек
код события онИррор. Можно ли как то ускорить проверку?
Скажу честно раньше делал пингом. Было чуть быстрее но пинг со времинем при длительном отключении залипал и переставал реагировать да и там был только один дивайс а тут в теории их может быть до 15

Цитата medved_68 @ 16.04.13, 17:02

Занятно то, что система не позволит корректно открыть второй сокет на занятом порту, вернув код либо 10048, либо 10056.

C чего бы это? Он же про удаленный порт (входящий на девайсе) говорит, а не локальный (исходящий на компе)

Добавлено 17.04.13, 06:01

Цитата apprentice @ 17.04.13, 05:49

событие онИррор возникло спустя 20 сек

Это когда по таймауту отвалилось, видимо. А еще можно проверять результат Send, либо при отправке взводить флаг и ожидать события OnWrite (не помню точно, как в этом классе сокета зовется событие отправки данных). В таймере проверять, если события отправки не происходит некоторое время - связь оборвана.

Цитата Fr0sT @ 17.04.13, 05:56

Добавлено 17.04.13, 06:01

Цитата apprentice @ 17.04.13, 05:49

событие онИррор возникло спустя 20 сек

Это когда по таймауту отвалилось, видимо. А еще можно проверять результат Send, либо при отправке взводить флаг и ожидать события OnWrite (не помню точно, как в этом классе сокета зовется событие отправки данных). В таймере проверять, если события отправки не происходит некоторое время - связь оборвана.

Сейчас попробую порыть

Цитата Fr0sT @ 17.04.13, 05:56

А еще можно проверять результат Send,

Именно это я предлагаю делать:

Цитата medved_68 @ 16.04.13, 17:12

то что мешает периодически (по таймеру) отправлять что то? И анализировать, сколько байт отправлено...

Но, видимо, как то не так предлагаю... А 20 сек. для сети - это ерунда, можно смело забить. Весь вопрос в том, предусмотрена ли буферизация отправляемых пакетов пользовательским протоколом, чтобы можно было повторить отправку при восстановлении канала и без потерь данных.

Добавлено 17.04.13, 10:07

Цитата Fr0sT @ 17.04.13, 05:56

Он же про удаленный порт (входящий на девайсе) говорит, а не локальный (исходящий на компе)

Неужели?

Цитата apprentice @ 16.04.13, 16:00

Да нет они на одном порту висят но один в потоке, а второй просто висит.

Весьма трудно ClientSocket представить на удаленном девайсе в контексте процитированного.

Цитата medved_68 @ 17.04.13, 10:04

Неужели?

Ну, я понял эту фразу как "Они к одному порту присоединены", поскольку локальный порт в контексте задачи тут вообще не пришей кобыле хвост.

Добавлено 17.04.13, 10:44

Цитата medved_68 @ 17.04.13, 10:04

20 сек. для сети - это ерунда, можно смело забить

Ага, особенно в realtime приложениях