YK
спасибо
Size: a a a
2019 February 03
ŹR
Знаю. Но если сервер упадёт. С http запрос перенаправится на свободный сервер. А в веб сокетах он просто собьётся
Феник из коробки поднимает PubSub на PG2, а это значит что если ноды соединить в кластер, то канал будет работать сквозь кластер
ŹR
И broadcast будет залетать на все ноды, соответственно при сокет-подключению. к любом серверу в кластере будет все работать
MA
в общем решили на фениксе проектик попробовтаь написать
но без темплейтов фениксовских а фронт в отдельном СПА
но без темплейтов фениксовских а фронт в отдельном СПА
https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript
вроде феникс по другому пути идет
вроде феникс по другому пути идет
PS
Про веб сокеты. Если у нас есть http сервер, то два последовательных запроса могут попасть на 2 разных сервера, клиент этого не заметит. То есть масштабировать в ширину мы можем сколько угодно.
Например если первый сервер перегружен.
В случае же с веб-сокетами это невозможно? Что будет с соединениями к серверу, который перегрузился?
Например если первый сервер перегружен.
В случае же с веб-сокетами это невозможно? Что будет с соединениями к серверу, который перегрузился?
вебсокетам свойсвенно рваться, переподклатся
PS
https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript
вроде феникс по другому пути идет
вроде феникс по другому пути идет
LiveView не замена SPA
PS
что-то легкое через него, вроде валидаций, будет норм, но если перетянуть всю ыронтовую логику на сервер, начнется очень интересное приключение
v
В том и прикол, что http не держит connect. А с веб-сокетами connect с сервером устанавливается, и все запросы далее идут только на этот сервер
С чего вы взяли, что http не держит соединение?:)
M
С чего вы взяли, что http не держит соединение?:)
Он отдал ответ и потух
v
Он отдал ответ и потух
веб-сокеты - это надстройка поверх http, а про "отдал ответ и потух" - почитайте про long pooling - вполне вероятно, что вам и не потребуются веб-сокеты, ибо все это можно реализовать нативным js и на http
v
просто держите коллекцию соединений на своем веб-сервере, и когда необходимо - отправляете что нужно клиенту.
(
веб-сокеты - это надстройка поверх http, а про "отдал ответ и потух" - почитайте про long pooling - вполне вероятно, что вам и не потребуются веб-сокеты, ибо все это можно реализовать нативным js и на http
> веб-сокеты - это надстройка поверх http
Эм, нет? HTTP и веб-сокеты работают поверх TCP, но одно никак не связано с другим
Эм, нет? HTTP и веб-сокеты работают поверх TCP, но одно никак не связано с другим
YT
YT
Связаеы же
YT
Сейчас проверю
F
веб-сокеты - это надстройка поверх http, а про "отдал ответ и потух" - почитайте про long pooling - вполне вероятно, что вам и не потребуются веб-сокеты, ибо все это можно реализовать нативным js и на http
я не читал сначало что вы там писали в переписке но WS это надстройка поверх TCP-соединения WS имеет свой запрос и ответ, и да они разные чутка от http
YT
в ну да в самом деле
v
Я отвечал на замечание, что http "не держит соединение" - на самом деле все держит:) И удивительно наблюдать, когда гуру с 20-летним стажем спрашиваешь "как работает простой чат" - многих этот простой вопрос ставит в тупик почему то. Все, что делается на WS, может быть реализовано на http.
M
Я отвечал на замечание, что http "не держит соединение" - на самом деле все держит:) И удивительно наблюдать, когда гуру с 20-летним стажем спрашиваешь "как работает простой чат" - многих этот простой вопрос ставит в тупик почему то. Все, что делается на WS, может быть реализовано на http.
Вообще что значит держать соединение? Не обязательно http.
Клиент открывает сокет. В linux это файл. Пишет туда данные - это исходящий запрос.
Пишет с помощью системного вызова write().
И читает тоже с помощью системного вызова read().
Когда клиент понимает что пришел ответ который можно прочитать - я хз.
Затем системным вызовом close() закрыается соденинение.
Значит открытое соединение - это просто открытый сокет, в который можно записать что-то, и потом отправить это через tcp/ip.
А закрыть соединение - значит закрыть сокет, и больше не ждать ответа сервера.
Если моя логика верна, то да, http можно держать сколько угодно долго открытым
http://programming-lang.com/ru/comp_programming/metyu/0/j639.html
Клиент открывает сокет. В linux это файл. Пишет туда данные - это исходящий запрос.
Пишет с помощью системного вызова write().
И читает тоже с помощью системного вызова read().
Когда клиент понимает что пришел ответ который можно прочитать - я хз.
Затем системным вызовом close() закрыается соденинение.
Значит открытое соединение - это просто открытый сокет, в который можно записать что-то, и потом отправить это через tcp/ip.
А закрыть соединение - значит закрыть сокет, и больше не ждать ответа сервера.
Если моя логика верна, то да, http можно держать сколько угодно долго открытым
http://programming-lang.com/ru/comp_programming/metyu/0/j639.html
M
тишина... ) так глубоко наверное никто не копает