VM
у фейсбука такая штука поверх mqtt реализована, довольно круто
Size: a a a
2020 July 20
DP
почему?
потому, что SSE, все же, просто растянутый во времени ответ на запрос клиента
d
потому, что SSE, все же, просто растянутый во времени ответ на запрос клиента
вы описали лонг полинг, а там написано, что это совсем не он)
ВС
ну отличий не то чтобы много
DP
ну отличий не то чтобы много
лонг полинг предполагает запрос на каждую новую порцию инфы, а sse позволяет выдавать новые порции по инициативе сервера
вообще-то, так можно было делать и без sse, пропихивая очередной
но, в любом случае, это просто растянутый во времени ответ клиенту.
вообще-то, так можно было делать и без sse, пропихивая очередной
<script>…</script> с неким интервалом. мы так в 2010, кажется, прогрессбар рисовали на клиенте, пока данные готовилино, в любом случае, это просто растянутый во времени ответ клиенту.
АД
Но как я понимаю для sse как и для вебсокетов устанавливается непрерывое соединение, можно обрабатывать обрыв подключения, переподключаться. Это не тоже самое что отправил запрос и ждешь ответ, потому что если соединение оборвалось, клиент узнает об этом и переподключается. Не знаю как это под капотом реализовано.
DP
для обычного соединения тоже можнообрабатывать обрыв
ВС
Но как я понимаю для sse как и для вебсокетов устанавливается непрерывое соединение, можно обрабатывать обрыв подключения, переподключаться. Это не тоже самое что отправил запрос и ждешь ответ, потому что если соединение оборвалось, клиент узнает об этом и переподключается. Не знаю как это под капотом реализовано.
sse удобен тем, что в браузере уже есть готовый высокоуровневый клиент, который и переподключение сам делает и события приходящие по топикам в подписчиков отправляет
ЛА
лонг полинг предполагает запрос на каждую новую порцию инфы, а sse позволяет выдавать новые порции по инициативе сервера
вообще-то, так можно было делать и без sse, пропихивая очередной
но, в любом случае, это просто растянутый во времени ответ клиенту.
вообще-то, так можно было делать и без sse, пропихивая очередной
<script>…</script> с неким интервалом. мы так в 2010, кажется, прогрессбар рисовали на клиенте, пока данные готовилино, в любом случае, это просто растянутый во времени ответ клиенту.
1 длинный ответ экономит траффик.
Экономия есть даже между одним длинным ответом http1 и http2.
Если же сделать повторяющиеся запросы, то траффика это будет жрать очень много, оверхед на переустановку соединения, особенно есть ssl. Да, будет какой-то keep-alive, но не вечный, переконнекты будут
Экономия есть даже между одним длинным ответом http1 и http2.
Если же сделать повторяющиеся запросы, то траффика это будет жрать очень много, оверхед на переустановку соединения, особенно есть ssl. Да, будет какой-то keep-alive, но не вечный, переконнекты будут
ЛА
Так себе аналог :)
Насколько я знаю, мобильные пуши и работают так, что телефон держит постоянный коннект с сервисом и ждёт данных оттуда.
ВС
да, но делают его тоже "кто как", в мозилле json-over-ws, в гугле protobuf(+еще что-то)-over-tcp
ЕО
лонг полинг предполагает запрос на каждую новую порцию инфы, а sse позволяет выдавать новые порции по инициативе сервера
вообще-то, так можно было делать и без sse, пропихивая очередной
но, в любом случае, это просто растянутый во времени ответ клиенту.
вообще-то, так можно было делать и без sse, пропихивая очередной
<script>…</script> с неким интервалом. мы так в 2010, кажется, прогрессбар рисовали на клиенте, пока данные готовилино, в любом случае, это просто растянутый во времени ответ клиенту.
Есть вебсокет в 2020
ЛА
Звучит как баг
Перепроверил сейчас, с http.Request.Context().Done() все ок сейчас. Возможно, сбился прицел в прошлый раз
DP
Насколько я знаю, мобильные пуши и работают так, что телефон держит постоянный коннект с сервисом и ждёт данных оттуда.
там еще есть очередь на стороне сервиса, и коннект один на все пуши, и принимает их ось, а не конкретное приложение
DM
Насколько я знаю, мобильные пуши и работают так, что телефон держит постоянный коннект с сервисом и ждёт данных оттуда.
это дорого в плане батареи
ЛА
там еще есть очередь на стороне сервиса, и коннект один на все пуши, и принимает их ось, а не конкретное приложение
Так ведь в sse заложена очередь через id и last sent id. Можно понять какие ивенты надо дослать клиенту при его переподключении. Причем браузер сам запоминает эти айди и передаёт. Не надо писать джаваскрипт.
ЛА
там еще есть очередь на стороне сервиса, и коннект один на все пуши, и принимает их ось, а не конкретное приложение
По поводу что принимает ось - как раз вот для экономии, как я понимаю, этот сервис сделан глобальным уровня ос, иначе каждое приложение бы имело свой Коннект и все это жрало траффик и батарею.
Повторюсь, я говорю все же про реализацию бакенда по стандарту https://www.w3.org/TR/2009/WD-eventsource-20090421/
Это именно браузерный стандарт со своими плюсами и минусами + требованиями к бэку
Повторюсь, я говорю все же про реализацию бакенда по стандарту https://www.w3.org/TR/2009/WD-eventsource-20090421/
Это именно браузерный стандарт со своими плюсами и минусами + требованиями к бэку
ЛА
Есть вебсокет в 2020
Здесь кратко и по-русски сравниваются server sent events и websocket
https://learn.javascript.ru/server-sent-events
https://learn.javascript.ru/server-sent-events
p
1 длинный ответ экономит траффик.
Экономия есть даже между одним длинным ответом http1 и http2.
Если же сделать повторяющиеся запросы, то траффика это будет жрать очень много, оверхед на переустановку соединения, особенно есть ssl. Да, будет какой-то keep-alive, но не вечный, переконнекты будут
Экономия есть даже между одним длинным ответом http1 и http2.
Если же сделать повторяющиеся запросы, то траффика это будет жрать очень много, оверхед на переустановку соединения, особенно есть ssl. Да, будет какой-то keep-alive, но не вечный, переконнекты будут
> оверхед на переустановку соединения, особенно есть ssl
это лишь говорит о кривом клиенте/сервере
это лишь говорит о кривом клиенте/сервере