Соб-но, в играх потому 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 сделать

Что значит не нужно?

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

Владимир. Я не ставлю под сомнение твою квалификацию и авторитет. Но "не нужно" — это просто мнение. Я хочу в конкретном вопросе разобраться. Я потом сам решу, нужно это мне или нет. =)

не нужно делать rpc поверх вебсокетов, когда можно сделать поверх http

Что значит не нужно-то?)

это оверинжинирг в чистом виде

это не решает задач

Ну да, подумаешь будешь 500 байт вместо 50 слать, когда тебе пару байтиков отослать и пару байтиков получить

ws создавались именно для этой проблемы.

они все таки для pub sub и всякого такого

Я ещё раз повторяю, мне не нужно конкретно RPC, ё-моё. Я просто привёл пример известной мне абстракции над HTTP. Я хочу знать, существуют ли абстракции или соглашения над сокетами. =)))

500 байт это я, конечно, лажанул. С куками меньше 3киб явно не получится.

они все таки для pub sub и всякого такого

Ну, это мне и нужно, если что. =)

Это отлично решает задачу: я на ноде трекаю пользователей которые подключены сейчас, вывожу по ним статистику, отпавляю им что надо, обновляю, нотифицирую. В админке это показываю Что не нужно в этом случае - это городить огород чтобы сделать тоже самое через http самому

Только сервер становится stateful

Усложняется проксирование

Только сервер становится stateful

Чёэт вдруг?

Ломается балансировка

Только сервер становится stateful

Ну и хорого, это может быть не весь сервер, а один микросервис, который торчит наружу

Да ничего не ломается

nginx прекрасно балансирует

выключаем сервер - все отключаются

включаем - ребалансировки нет, сервер пустой

Сервер может быть просто источником данных и ACL.

Балансировать по сессиям надо

А не по запросам

nginx балансирует сокеты, а нет запросы

Короче. Я так понимаю, ответ на мой вопрос — "нет, не слышали"?

ERROR: S client not available

Это приводит к неравномерности нагрузки, по карйней мере временной

500 байт это я, конечно, лажанул. С куками меньше 3киб явно не получится.

http://www.websocket.org/quantum.html Тут ресерч, сколько гигабайт сервер будет экономить на хедерах

Короче. Я так понимаю, ответ на мой вопрос — "нет, не слышали"?

Ответ на твой вопрос: есть нормальные решения (например, dnode, если речь по rpc), но в большинстве случаев ws именно для голых данных, когда протокол ты сам прорабатываешь

в socket.io в принципе это есть

http://www.websocket.org/quantum.html Тут ресерч, сколько гигабайт сервер будет экономить на хедерах

thx

Только сервер становится stateful

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

это понятно, просто когда этого можно избежать - стоит этого избегать

Ответ на твой вопрос: есть нормальные решения (например, dnode, если речь по rpc), но в большинстве случаев ws именно для голых данных, когда протокол ты сам прорабатываешь

Спасибо. =))

это понятно, просто когда этого можно избежать - стоит этого избегать

Согласен.

я лично очень люблю stateful подход, но для нужна серьезная инфраструктура

Объясните пожалуйста в двух словах отличие stateless от stateful

Объясните пожалуйста в двух словах отличие stateless от stateful

http://stackoverflow.com/a/5468831

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

Я вас опечалю, но сообщений в tcp нет

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

Нет в tcp пакетов. tcp - это bytestream.

Угу. И по сети оно тоже не пакетами, а стримом идёт. Ну-ну

Угу. И по сети оно тоже не пакетами, а стримом идёт. Ну-ну

Какое вам дело как оно в проводах? Пакетов в tcp нет и приложение работает с потоком байт для которого гарантирует очередность.

Я ничего про провода не говорил

Если в в tcp запишите серию сообщений по 64 байта, то на той стороне прочитается как угодно: хоть все разом, хоть по 1.5 сообщения.

Угу. И по сети оно тоже не пакетами, а стримом идёт. Ну-ну

Я про это.

Ну пакеты в tcp есть, но с нижней стороны

Со стороны интграции с ip

Ну пакеты в tcp есть, но с нижней стороны

Приложению до них не дотянуться.

само собой, просто фраза tcp-пакет имеет смысл

само собой, просто фраза tcp-пакет имеет смысл

tcp-сегмент :)

Не пойму о чём идёт разговор

В стандарте есть слово пакет, есть дефиниция для него

Но тут речь про другое: вы в tcp сокет можете положить несколько сообщений, но на той стороне их могут не получить.

Не могут

Я хочу стек, в котором я смогу использовать и CommonJS и AMD модули на клиенте. При этом, AMD модули могут быть на внешних ресурсах. Куда копать? Вебпак умеет только внутренние AMD-модули. К Browserify нужно прикручивать RequireJS (через глобал скоуп). Может быть, ещё что-то есть?

При сильном везении могут получить испорченными, конечно. Но либо получают, либо сокет закроется по таймауту

Не могут

С

Не могут

С чего бы вдруг? Запись в сокет не означает немедленную отправку.