А суть в его использовании

суть в том, что либо используешь, либо сидишь и ноешь, что нет надежных решений

> джс > надёжно

Просто вебсокеты не помогают ни чем в этом плане

Вот если например нужно получать значение пероидически - то да

Если нужно получать последовательность без потерь - то нет

> джс > надёжно

вообще все что создано людьми ненадежно, если хочешь увести в эту сторону

Если нужно получать последовательность без потерь - то нет

предложи другое решение

http + long polling с номером последовательности

>_>

и как по твоему в сокетах происходят потери?

Которое никак не вяжется с учебниками

Адепты RTOS в треде, все в укрытие

и как по твоему в сокетах происходят потери?

Во время дисконнекта

А если всё то же самое, но только аргументированно? =)

или нарушение порядка?

Впрочем, мне сойдут и ссылки на литературу.

Во время дисконнекта

ну это называется "сам мудак"

Да, безусловно

Адепты RTOS в треде, все в укрытие

Спс

за этим надо следить точно так же как и за обрывами в long-polling

На скоетох МОЖНО сделать все, но они просто не помогают

за этим надо следить точно так же как и за обрывами в long-polling

вот нет

вот и да

на лонг поллинге есть концепутально простое решение с номером последовательнсоти

интернет пропал

соединение оборвалось, яваскрипт об этом должен узнать и переподключиться

В лонг поллинге нет подключение, концептуально

Он stateless

последовательность - можно нарушить только самостоятельно

В общем - это концептуально разные вещи, push vs pull, условно

При pull проще делать надежно

В лонг поллинге нет подключение, концептуально

лонг поллинг - это подключение без обрыва соединения - перевод в режим ожидания

Но если оно оборвется, то пофиг

"нет подключения" - это бред

В http концептуально нет подключения, на пользовательском уровне

Но если оно оборвется, то пофиг

а вот и не пофиг, если оборвется в момент передачи

Пофиг, сделаешь ретрай

ты проверил - нет, ты забил, очевидно

потому что считаешь, что протокол может решить все проблемы

Ретрай можно делать и на сокетах.

Ретрай можно делать и на сокетах.

Если речь о чисто пуш - то нет

Там можно только на ack рассчитывать

А на уровне приложения?

Все можно, само собой

В чём проблема подписаться на уведомления, но при этом чекать переодически?

Что чекать?

Даже подписки мутить не надо, тупое такое решение

в вк изменения, кто не читал еще

Короче, суть в том, что мне нравится идея, реализацию которой делают возможной сокеты: возможность инициировать событие и забыть об этом, а не ждать ответа, как в случае с REST (ладно, как в случае с HTTP вообще). Вместо обработки ответа, можно просто подписаться на событие, которое инициирует другая сторона. На мой взгляд, это просто удобнее. А целостность данных, на мой взгляд, — это ужен совсем другая проблема.

А в чем профит? Не хочешь ждать ответа - не жди ответа

А в чем профит? Не хочешь ждать ответа - не жди ответа

Да, но результат обработать надо. Только я не хочу ждать, а хочу его обработать тогда, когда он придёт.

Ну ты и так обработаешь его когда он придет

Ну ты и так обработаешь его когда он придет

По HTTP я должен буду ждать ответа. А по сокету я просто подпишусь на событие.

▫️Какой у вас проект или где работаете? nodejs + asterisk ▫️В чём вы специалист? voip, isp, asterisk, учусь nodejs )) ▫️Чем можете быть интересны или полезны сообществу? спрашиваю глупые вопросы, повышаю ЧСВ сообществу ▫️Чем интересно сообщество вам? костер горит лучше, когда дрова вместе ▫️Откуда вы? Ижевск ▫️Как узнали про группу? ссыль в дргой группе #whois

> @bigslycat По HTTP я должен буду ждать ответа. А по сокету я просто подпиусь на событие. Так разницы то нет особой

В первом случае senRequest().then(response => …)

Во втором - sendRequest(); socket.on(‘message’, () => …)

разница в том, использовать ли костыли или готовое решение

ну в данном случае http - это готовое решение

long-polling и прочие костыли появились так как не было родного решения

long-polling не является частью протокола со всеми последствиями

ну в данном случае http - это готовое решение

Над которым нужно создавать ещё одно решение. =)

Нет, тебе не нужен и лонг поллинг

Ты просто хочешь RPC по вебсокетам делать

Это вообще не нужно

По HTTP я должен буду ждать ответа. А по сокету я просто подпишусь на событие.

Ты не в курсе про промисы что ли?))

ERROR: S client not available

Как придет так и придет

>_> кто-то в курсе что кому нужно. у нас ванга в чятике

Ты не в курсе про промисы что ли?))

Причём здесь промисы-то? =)

они тебе обещают

Ну, это да.

Промисы — не панацея. Кто-то вот вообще не любит их использовать (это я не про себя).

Их проблемы

О, они прекрасно живут. =)

Это решение

Да.

Ну кто-то и жикверью живет

сокетайо

там и вебсокеты, и лонг поллинг

и клиенты мобильные

и переподключение

Там все плохо

Лонг поллинг чисто как шим

неправда

> @chicoxyzzy и клиенты мобильные Вообще говно

его можно подефоллту

Можно, но семантика теряется

говно, не говно, а протокол один

Именно, и говно именно в протоколе

короче на сокетайо можно жить

не один проект в проде кагбе

да, сокетайо говно

Опять же, я говорю про кейсы когда нужна надежная доставка в определенном порядке

но они работают

когда надо доставить после передподключения надо заново попросить — профит

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

зависит от кейса опять же

Технологию я уже выбрал. Я ж другой вопрос задавал. =)