Этот вопрос тебе наверняка не известен.

Зачем тебе именно _определенная_ архитектура?

Это твой домысел, и вообще, не очень вежливо.

— Двач, ем с ножа, постоянно порезан рот, как лечить? — Просто не ешь с ножа — НЕ УЧИТЕ МЕНЯ ЖИТЬ, Я СПРОСИЛ КОНКРЕТНЫЙ ВОПРОС

Когда тебе говорят, что твоё решение неоптимальное, ты говоришь, что ты не про это спрашивал

Эу... Так ты не в курсе мой задачи. Я её хочу сам решить. А сюда пришёл с конкретным, узким вопросом.

— Двач, ем с ножа, постоянно порезан рот, как лечить? — Просто не ешь с ножа — НЕ УЧИТЕ МЕНЯ ЖИТЬ, Я СПРОСИЛ КОНКРЕТНЫЙ ВОПРОС

Не, это явно не тот случай. Я спросил совета по ножевому бою, а мне советуют кунг-фу. =)

Короче, перебои со связью неактуальны. Нужно реализовать максимально однородную, прозрачную и простую событийную систему на фронте и на бэкенде. Нафиг мне рест, если эта абстракция будет стоять между одинаковыми сущностями по обе стороны от неё. Эта прослойка здесь будет только создавать оверхэд.

Правильно, а вебсокеты — не оверхед))

Перебоев не будет, т.к. клиент и сервер — одна машина.

Молчу-молчу

Короче, ты делаешь микросервисы

?

Правильно, а вебсокеты — не оверхед))

Нет. Мне всё равно нужно будет реализовать медиатор. Если событие будет попадать ещё и в сокет инстанс, архитектура не так усложнится, как это было бы в случае с рестом.

Короче, ты делаешь микросервисы

Нет. Там будет взаимодействие с аппаратной частью машины.

...

Я весь тред не читал

Но откуда у http преимущества в плане сорханности перед ws?

Если сохранность обоих регулируется tcp

.. a TCP не гарантирует доставку сообщений …

udp не гарантирует

tcp как раз гарантирует

В отличие от датаграм

А какова необходимость над этим париться при доставке сообщений на localhost и обратно?

Перепутал наверное

Но это ключевое отличие udp vs tcp

Есть ещё вриант tcp over udp

Гугл что-то такое делали

Неважно, localhost или нет, я не понял доводы людей, который топят в треде за лонгполинг и какую-то там доволнительную сохранность (щито?)

Протокол UDP но есть проверки

Я теперь вообще запутался. Никто не привёл ни пруфов, ни хинтов, куда мне копать. =)

tcp гарантирует доставку пакетов и то при условии наличия соединения, а не сообщения.. если я отправил сообщения 10-и ресипиентам - а один из них отпал - он это сообщение не получит и все. Даже никогда не узнает что его должен был получить

Ну да, он же отпал.

Ну и не страшно.

Ну да, он же отпал.

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

Если клиент стейтлес, то логично, что при старте нового соединения, он запрашивает своё состояние у "источника правды".

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

Не пойму, к чему вы придираетесь? Я апеллировал к выссказываениям выше, что лонгполлинг даёт больше сохранности, чем вебсокеты.

Не пойму, к чему вы придираетесь? Я апеллировал к выссказываениям выше, что лонгполлинг даёт больше сохранности, чем вебсокеты.

Я не придераюсь, я наоборот за вас :)

Ок =)

Если клиент стейтлес, то логично, что при старте нового соединения, он запрашивает своё состояние у "источника правды".

Если клиент стейтлес, то тут и tcp не нужны, если можно использовать udp (ибо сам udp будет содержать состояние)

Если клиент стейтлес, то тут и tcp не нужны, если можно использовать udp (ибо сам udp будет содержать состояние)

>udp будет держать состояние Што

У меня мало понимания о том, что там происходит на низком уровне. Суть в том, что использование сокетов — вовсе не выстрел себе в ногу?

А что непонятного-то? Если на клиенте нет стейта, то весь стейт в сообщении и => нет смысла контролировать доставку

Соб-но, в играх потому udp и используют чаще всего

Ну, в общем, да.

Так. А с вебсокетами, всё-таки, кто-нибудь здесь работал? =)

Все, наверное, работали.

> @bigslycat Короче, перебои со связью неактуальны. ахахаха

Но как раз в играх стейт есть и на клиенте и на сервере, и udp там применяется из-за скорости и низкой ценности каждого кадра синхронизации состояний Если речь идёт скажем о сообщениях на форуме, то udp применять нельзя

https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing

> @bigslycat Короче, перебои со связью неактуальны. ахахаха

Не, ну а какие перебои могут быть на локалхосте?

Да на локалхосте никаких.

Ну и я о том ж.

Ну про это никто не говорил

Перебои сами по себе не страшны. Страшно, если контрольная сумма сойдётся при испорченных данных

Верно

Страшно применить апдейты не в том порядке

В ситуации когда локалхост, неважна надежность, порядок и т д - да делай что хочешь, как хочешь

Добрый день. Довольно такой дуратский вопрос, но как получить размер файла из POST запроса? Отправляю multipart. Получаю content_type, но размер там немного больше чем размер файла. Поэтому и хочется узнать как получить именно размер файла

Либо теряются данные, либо там учитывается размер всего http заголовка и прочего

Страшно применить апдейты не в том порядке

Ну, тут как раз сильно маловероятно испорченность. Это прям повести должно конкретно, чтобы у двух пакетов симметрично биты поменялись.

И при этом контрольные суммы сошлись бы

биты порядка*

Имеется в вижу не испорченность пакетов, а испорченость результата, расчитаного на клиенте

Так вот, мой вопрос, с которого всё это началось, заключался в следующем: вот для HTTP придумали REST, RPC, SOAP... Потом JSON-API, RPC-JSON и т.д. И я хотел узнать, не придумали ли что-нибуть такое для вебсокетов? Не хочу писать велик. Особенно, не имея опыта. Хочу ознакомиться с соглашениями, если таковые уже есть.

Так задача какая?

А что ты хочешь-то?

RPC по вебсокетам? это бессмысленно

Ну почему-же.

Ну почему-же.

Есть теоритеский профит от мультиплексирования

Но и только

Что в данном контексте мультиплексирование?

Я знаю только одно мультиплексирование — select/poll.

Логических каналов на tcp сокеты

Аа

т е нет head of line блокировки

Ну, что такое RPC? Это определённое соглашение, если в общем? Протокол над HTTP? Верно? Возможно, что-то более высокоуровневое есть и над веб-сокетами.

RPC это когда ты посылаешь запрос и получаешь ответ

Не обязательно это похоже на перечисленные мною вещи. Скорей всего, не похоже, вовсе.

Использую websocket'ы в продакшене уже 5 лет на разных проектах. Написаны обертки на все случаи жизни. Работает как часы, плюс онлайн обновления, нотификации и тд Ничего не течет. Возвращаться на http не хочется совсем

Хотя, я слышал, что есть рест овер сокетс.

Все можно, но просто это не НУЖНО

Можно и через webrtc сделать