Здравствуйте, Passerby, Вы писали:
AA>> var timeOut = new CancellationTokenSource(5_000).Token; P>Зачем?
WebSocket.ReceiveAsync
отменится автоматически если неполучит ответа через 5 секунд. цикл не нужен.
Здравствуйте, varenikAA, Вы писали: AA>WebSocket.ReceiveAsync
Это не то. Речь идет про ситуацию, когда подписались, к примеру, день назад и день данные приходили, а потом перестали. А не про возвращение ответа на команду в течение какого-то времени.
Здравствуйте, Passerby, Вы писали:
P>Это не то. Речь идет про ситуацию, когда подписались, к примеру, день назад и день данные приходили, а потом перестали. А не про возвращение ответа на команду в течение какого-то времени.
Понятно, а соединение с сервером живое, т.е. статус сокета Open? Данные могут перестать приходить только если соединение разорвано в случае вебсокета.
тут нужно не на время ориентироваться как мне кажется а на статус соединения.
Здравствуйте, varenikAA, Вы писали: AA>тут нужно не на время ориентироваться как мне кажется а на статус соединения.
Соединение может быть не закрыто, а данные не будут присылаться.
Есть хороший сайт http://websocket.org/echo.html Там можешь сделать коннект, а потом выдернуть кабель связи из ПК и нажать на дисконнект. Можешь потренироваться с работающими серверами, к примеру,
поле Location: wss://api.hitbtc.com/api/2/ws
поле Message: {"method": "subscribeTicker","params": {"symbol": "ETHBTC"},"id": 123}
И разорви связь во время приема пакетов.
Поэтому иногда серверы посылают строго периодические сигналы по одному из подписанных каналов. Которые тоже надо отслеживать, т.е. тот же цикл с задержкой времени, зависящей от периодичности сигналов.
Здравствуйте, Passerby, Вы писали:
P>Есть хороший сайт http://websocket.org/echo.html Там можешь сделать коннект, а потом выдернуть кабель связи из ПК и нажать на дисконнект.
Тут-то и нажимать ничего не должно быть надо, он сам должен убежать в дисконнект. Но такой способ не очень показательный, т.к. разрыв связи определяется однозначно.
Здравствуйте, Mystic Artifact, Вы писали: MA> Но такой способ не очень показательный, т.к. разрыв связи определяется однозначно.
Как он определяется? Выдергиваешь Lan, вставляешь и ничего не происходит, а пакеты перестают поступать. Т.е. если кратковременный разрыв связи, об этом не узнаешь, если не будешь отслеживать поступление пакетов. Могу скинуть ссылку на работающий шаблон с работающим сервером. Там и отслеживание состояние сокета есть. Только при разрыве связи ничего не происходит. Согласен, что дисконнект в таком случае нажимать излишне.
Здравствуйте, Passerby, Вы писали:
P>Как он определяется? Выдергиваешь Lan, вставляешь и ничего не происходит, а пакеты перестают поступать. Т.е. если кратковременный разрыв связи, об этом не узнаешь, если не будешь отслеживать поступление пакетов. Могу скинуть ссылку на работающий шаблон с работающим сервером. Там и отслеживание состояние сокета есть. Только при разрыве связи ничего не происходит. Согласен, что дисконнект в таком случае нажимать излишне.
И правда... я ж говорил, я с ними не дружу.
Ну, тут и помог бы пинг/понг — выдергиваешь Lan — нажимаешь Send — и через несколько секунд он сам станет disconnected.
Конечно, если ты знаешь, что у тебя события и так прилетают регулярно — то и пинг не нужен, или число их можно скоратить.
Здравствуйте, Mystic Artifact, Вы писали: MA> Ну, тут и помог бы пинг/понг
Не помог бы. Сервер может пинговаться, но перед этим произошел разрыв связи. Поэтому только отслеживание пакетов. Да и для того чтобы делать периодически пинг, тоже нужен тот же цикл. Ничего не упрощается, только меньше информации. MA> И правда... я ж говорил, я с ними не дружу.
Дело в том, что серверы по HttpClient дают устаревшие данные. Они не посылают актуальные данные, т.к. запросов огромное количество, то собирать данные для каждого было бы утомительно. Потому данные собираются с каким-то периодом, а посылаются кэшированные. К тому же задержка времени связанная с запросом. К тому же ограничение количества запросов в секунду. Но если задержка порядка секунды или несколько секунд роли не играет и запросов мало, то HttpClient.
Но заметил, что и по WebSocket есть сервера, которые делают задержку, если подписан на много каналов.
Здравствуйте, Passerby, Вы писали:
MA>> Ну, тут и помог бы пинг/понг P>Не помог бы. Сервер может пинговаться, но перед этим произошел разрыв связи. Поэтому только отслеживание пакетов. Да и для того чтобы делать периодически пинг, тоже нужен тот же цикл. Ничего не упрощается, только меньше информации.
Пинг/понг в смысле — посылка запроса/сообщения через веб-сокет. Тут смысл только в том, что бы дать ему возможность отвалиться естественным образом. Твой пример с выдернутым Lan и кнопочкой Send как раз это демонстрирует.
Про остальное, ты все и так написал, и похоже на план.
Здравствуйте, Mystic Artifact, Вы писали: MA> Пинг/понг в смысле — посылка запроса/сообщения через веб-сокет. Тут смысл только в том, что бы дать ему возможность отвалиться естественным образом.
Он и так отваливается мгновенно, если на секунду выдернуть лан.
Я уже вчера все написал без прерываний. Если во время цикла приходят данные, все ОК.
Здравствуйте, Passerby, Вы писали:
P>Он и так отваливается мгновенно, если на секунду выдернуть лан.
Ты же написал выше, — обратное, что не прерывается. Я даже попробовал — выдергиваем кабель — ничего не прырвается, при чём довольно долго. Если потушить интерфейс программно — тогда да, прерывается, мгновенно.
Здравствуйте, Mystic Artifact, Вы писали: MA> Ты же написал выше, — обратное, что не прерывается. Я даже попробовал — выдергиваем кабель — ничего не прырвается, при чём довольно долго.
Я писал, что если выдернуть lan, то ничего не происходит в смысле нет после восстановления связи сигнала дисконнект. Но пакеты перестают поступать. Сейчас проверил и на сервере, с которого поступает информация и на ранее опубликованной ссылке: на пару секунд выдергиваешь лан, вставляешь... и как в Гамлете — дальше тишина. У нас разная карма, наверное. Ты профи, поэтому тебе пакеты продолжают поступать.
Здравствуйте, Passerby, Вы писали:
P>Здравствуйте, varenikAA, Вы писали: AA>>тут нужно не на время ориентироваться как мне кажется а на статус соединения. P>Соединение может быть не закрыто, а данные не будут присылаться. P>Есть хороший сайт http://websocket.org/echo.html Там можешь сделать коннект, а потом выдернуть кабель связи из ПК и нажать на дисконнект. Можешь потренироваться с работающими серверами, к примеру,
Тут что-то другое. соединился, опустил сеть. через ~20 сек ошибка соединения. если восстановить соединение чуть раньше эхо отрабатывает нормально.
сокет предусматривает таймаут разъединения как раз на случай длительных задержек, сетевых потерь.
Вероятно это что-то в приложении сервера не так.
Здравствуйте, varenikAA, Вы писали: AA>Тут что-то другое. соединился, опустил сеть. через ~20 сек ошибка соединения. если восстановить соединение чуть раньше эхо отрабатывает нормально.
Да, сейчас проверил, действительно, если меньше секунд 20, то восстанавливается. И дисконнект приходит. Раньше спешил, не дожидался этого. Сейчас посмотрел программу, я ее наращивал из шаблона. Так оказывается там нет подписи на закрытие соединения. Есть только проверка соединения после создания коннекта. Буду исправлять. Спасибо.
