Или отправлять и помечать что за схема

Или отправлять и помечать что за схема

как

вот это интересно

Типа шлешь первым символом число и потом из raw message его читаешь, отбрасываешь и потом конвертишь

Но лучше по одному коннекту одну схему гоняй

Можно схему тип, объект, а в структуру долбишь тип и кучу объектов

Но лучше по одному коннекту одну схему гоняй

и если у меня 5 разных сообщений что 5 коннектов? 1 новый игрок подключился 2 ему приходит массив игроков 3 пакет в котором координаты новые

и т.п.

type Message struct { Type string, Person, Car }

Типа шлешь первым символом число и потом из raw message его читаешь, отбрасываешь и потом конвертишь

ну не, это через чур уже. в заголовки HTTP загнать свой кастомный и там написать что приезжает сейчас, потом те варианты что я предложил - впихнуть в одну структуру эти две это первый и по эндпоинтам разнести это второе а-ля http://—/message и http://---/person

Ну по эндпоинтам я и предлагаю как лучшее решение

Но он одним сокетом хочет

ааа там веб-сокет. ну тогда в одну структуру все варианты сгоняет а-ля Packet и потом проверяет все варианты на nil - тот что не nil тот и пришел

или доп поле прям указание типа как Майк привел

Я б тип слал

Чтоб не проверять, а свич

да я тоже тип всегда слал в таких случаях, последний раз в protobuf

Мало ли, просто хочется без тела что-то кинуть, все Нил будут

Но да, про заголовки забыл

Тоже идея хорошая

Но не для сокета)

(могу ошибаться правда, но в них же нет заголовков)

для вебсокета не хорошая идея, это если без него - тогда применимо, делал один раз так, но не для разных сущностей, а для разных форматов сериализации - тип сереализации передавал и принимал в заголовке http

ааа там веб-сокет. ну тогда в одну структуру все варианты сгоняет а-ля Packet и потом проверяет все варианты на nil - тот что не nil тот и пришел

а не будет ли это оверхедом?

а не будет ли это оверхедом?

будет конечно. как минимум две фигурные скобки и запятая - 3 символа, целых 6 байт в UTF-16 или 3 байта в UTF-8

ну пробелы мож там еще -)

если у тебя сериализованные данные, и разные структуры - всегда парсить придется в два приема

1. распарсили тип сообщения

2. распарсили payload

никаких вариантов

и это не топорно, это так, как есть

выше описан вариант, где в два прохода ничего не нужно парсить

это который?

А не пытаешься ли ты сэкономить все теоретические оверхэды в ущерб здравому смыслу или даже реальности?

а не будет ли это оверхедом?

в структуру Packet вложить структуры Person, Message и добавить числовое поле Type

А не пытаешься ли ты сэкономить все теоретические оверхэды в ущерб здравому смыслу или даже реальности?

Возможно

в структуру Packet вложить структуры Person, Message и добавить числовое поле Type

но когда я буду отсылать такую структуру в джесоне я буду отправлять лишние данные инициализированные

но когда я буду отсылать такую структуру в джесоне я буду отправлять лишние данные инициализированные

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

но когда я буду отсылать такую структуру в джесоне я буду отправлять лишние данные инициализированные

В курсе про невозможность 100% КПД? Похожая ситуация

в структуру Packet вложить структуры Person, Message и добавить числовое поле Type

тогда вторым этапом пойдет создание специфической структуры из общей. все равно два этапа

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

я определяю по полю Type а зачем мне отсылать к примеру Message если я отправляю только Person

В курсе про невозможность 100% КПД? Похожая ситуация

ЛАдно я понял

я хочу нереального

Не

Ты отправляешь тип

слать надо всегда специфическую структуру

И мессадж

А персон будет нил

нил - это я, если кто не в курсе :)

А персон будет нил

а точн, она не будет инициализированна

нил - это я, если кто не в курсе :)

ТЕБЯ НЕТ?!

короче

протоколы вроде json rpc 2.0 парсят в два прохода.

самосборный протокол можно собрать и на общей структуре (пока разные по типу поля не пересекутся по именам)

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

делайте специфическую копированием, и передавайте ее

мы тут сделали ошибку нечаяно, передавали общую

выпиливали с матами - некоторые компайл-тайм проверки перестали работать, и это нас огорчило

про оверхед

это как спор про динамическую и строгую типизацию

вы помните, что там у вас ssl на входе?

он ест достаточно проца, чтобы ваш оверхед не был особо заметен

Я поддерживаю не слать невнятности

протоколы вроде json rpc 2.0 парсят в два прохода.

я вообще хотел комбинировать для больших данных протобаф

джсон для разовых

Огребешь потом по полной

вот и я топлю за статику и за явность везде, с неявностью пару раз наелся выше крыши

джсон для разовых

и еще msgpack для чего-нибудь возьмите. будет радость пидораса

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

и еще msgpack для чего-нибудь возьмите. будет радость пидораса

чем плох формат сериализации? отличный формат

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

не забрасывайте камнями, я просто хочу попробоват ьпереписать вот это https://github.com/Edisoni/uWebsocketServer

любой один - хорош

там на UWS

больше одного по одному соединению - горите в аду

больше одного по одному соединению - горите в аду

тут такой вопрос никто не поднимал

+100500

Ну у вас то не бесит этот json unmarshall ?

Но да, у нас формат один, схемы разные

msgpack очень хороший формат, очень подходит для стримов - быстрый и никаких лишних аллокаций если на стримах юзать