Мануал Передача данных server<->client

[FuzzY]

FuzzY добавил(а) новый ресурс:

Передача данных server<->client - Передача данных server<->client через json

Всем привет, часто ищу решение своих проблем на форуме, и решил поделится своим решением тоже)

В общем суть проблемы, нужно было как то наладить общение client<->server без реализации новых пакетов ( екстенды делать не умею, а кто делает берут как за новую однушку в Москве)

По гайдам форума нашел 2 полезных для меня пакета

0x19 - RequestPCCafeCouponUse - через него можно послать на сервер строку размером в 1024 символов

ExSendUIEvent - им можно передать клиенту 3 int параметра и 6...

Узнать больше об этом ресурсе...

 

[MrThirtyOddSix]

Если вам нравиться JSON и вы уже должны делать парсер под него на клиентскок стороне, почему бы не использовать MessagePack? Он меньше по размеру и парсеры можно взять на различных языках (ну и править все для клиента). Но я так думаю что в конце концов если вы уже парсите то какую дату, может быть все сжать в бинарный формат (кстати тот же MessagePack будет соревноваться если у вас будет много текста) если у вас модель данных (поля и тип данных не изменяються) ?

Я про то что формат JSON не сможет много данных передавать с сервера. Конечно, нужно определить что нужно передавать и потом оптимизировать. Нo я просто хотел указать на другие возможности форматов.

 

[FuzzY]

Если вам нравиться JSON и вы уже должны делать парсер под него на клиентскок стороне, почему бы не использовать MessagePack? Он меньше по размеру и парсеры можно взять на различных языках (ну и править все для клиента). Но я так думаю что в конце концов если вы уже парсите то какую дату, может быть все сжать в бинарный формат (кстати тот же MessagePack будет соревноваться если у вас будет много текста) если у вас модель данных (поля и тип данных не изменяються) ?

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

 

[MrThirtyOddSix]

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

A как в клиенте будет обрабатываться полученный текст, после получения пакета? Текст то ведь и есть бинарные данные, только представленны в другой обвертке (ну например те же операции с текстом, это то как можно с такими данными работать в клиенте, скорее вопрос в том как клиент позвоит такой текст нам перевести во что-либо другое).

 

[FuzzY]

A как в клиенте будет обрабатываться полученный текст, после получения пакета? Текст то ведь и есть бинарные данные, только представленны в другой обвертке (ну например те же операции с текстом, это то как можно с такими данными работать в клиенте, скорее вопрос в том как клиент позвоит такой текст нам перевести во что-либо другое).

не совсем понял вопрос, в интерфейсе в методе OnEvent уже приходит строка , она тоже имеет структуру похожую на json и из нее уже получаем те данные которые отправили с сервера, как то изменить это я думаю без ковыряния в dll ничего не сделать с этим

 

[MrKirill1232]

Я вот после 286 протокола могу подцепиться к какому-то интерфейс пакету, и обрабатывать информацию напрямую с буффера. Ну и слать их конечно тоже могу.
+ Размером пакета в 1048 символов не ограничен, там уже будет 32к

 

[FuzzY]

Я вот после 286 протокола могу подцепиться к какому-то интерфейс пакету, и обрабатывать информацию напрямую с буффера. Ну и слать их конечно тоже могу.
+ Размером пакета в 1048 символов не ограничен, там уже будет 32к

268-273 можно так же делать?

 

[MrKirill1232]

268-273 можно так же делать?

ну это протоколы лет так на 10 отстают от 286, о котором я говорю.

 

[FuzzY]

ну это протоколы лет так на 10 отстают от 286, о котором я говорю.

а каким оброзом там можно подключится сразу к буфферу? или там есть функции с uc скриптах?

 

[MrKirill1232]

а каким оброзом там можно подключится сразу к буфферу? или там есть функции с uc скриптах?

по сути - это сделано екстендером самими корейцами.
можешь через .uc управлять наполнением буфера (writeInt \ writeByte), ноги которых уходят в .dll

 

[Gaikotsu]

Вобще никто же не мешает слать нужные данные порциями в пакетах, хоть целые мегабайты данных. Главное суметь их в клиенте собрать обратно.

 

[FuzzY]

Вобще никто же не мешает слать нужные данные порциями в пакетах, хоть целые мегабайты данных. Главное суметь их в клиенте собрать обратно.

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

 

[MrKirill1232]

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

а почему.
Условно клиент достаточно быстро данные такие обработает. Главное обозначить пакет с общим колличеством данных.

Условно первый пакет - информация сколько блоков данных будет по итогу;
Остальные пакеты - индекс блока данных - информация блока.
На стороне интерфейса их сувать в масив и при получении последнего пакета - распарсить уже.

 

[Gaikotsu]

Можно и не слать заголовочный пакет - просто в каждом пакете отсылать "это часть такая-то из стольки-то".
Офф пакеты такие есть, как минимум парочка, связанных с эмблемой клана - она то уже давно как не крути не влазит в один пакет (полноцветный dds 256х256) и приходится порциями его слать.
или те же мультиселы, да и вобще ща многие пакеты связанные с предметами можно слать кусками.

 

[MrKirill1232]

Можно и не слать заголовочный пакет - просто в каждом пакете отсылать "это часть такая-то из стольки-то".
Офф пакеты такие есть, как минимум парочка, связанных с эмблемой клана - она то уже давно как не крути не влазит в один пакет (полноцветный dds 256х256) и приходится порциями его слать.

ну для емблем у клиента есть представление сколько всего байт получать будет.
Когда шлешь данные условно для заполнения менюшки - у тебя есть неизвестное "какой обьем памяти следует выделить";

 

[lvlkoo]

MessagePack

Поддерживаю автора поста, если имеем небольшое ограничение в размере, и не нужно иметь открытого апи с понятными контрактами - json не лучшее решение, можно использовать альтернативы типа MessagePack, а если уже решились сами писать парсеры\форматеры то может и вовсе что-то свое

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

С Ваших слов получается что весь TCP протокол - набор костылей?

 

[Rolo]

Я как увидел

Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация

, вообще перестал себе отказьівать в костьілях, с тех пор я, кажется, стал повелителем интерлюда (во всяком случае, в своих самоощущениях, как минимум). Так что всем советую пересмотреть пару раз.

 

[Bankir]

Я как увидел

Вы не можете просматривать ссылку пожалуйста воспользуйтесь следующими ссылками Вход или Регистрация

, вообще перестал себе отказьівать в костьілях, с тех пор я, кажется, стал повелителем интерлюда (во всяком случае, в своих самоощущениях, как минимум). Так что всем советую пересмотреть пару раз.

Sarcasm:

Ты про єто?

 

[Fern]

Мне кажется, что некоторые люди слишком мудрят. Чисто ради бафера делать всё это? Понятно, что это только пример, но иногда не обязательно заходить так далеко.

 

[FuzzY]

Мне кажется, что некоторые люди слишком мудрят. Чисто ради бафера делать всё это? Понятно, что это только пример, но иногда не обязательно заходить так далеко.

у меня нет возможности реализовать свои пакеты, у меня все сервисы сделаны таким образом , когда уже все настроено реализовать новый сервис через UI куда проще стало чем делать убогий html c bypass