клиент-сервер, вопрос по экономии траффика.

[SeregaZ]

сижу ваяю... и сам в шоке клиент-сервер с кентубасом уже потестировали - танки ездят я просто жутко доволен... однако дальнейшее развитие упрется в необходимость передавать тонну информации.
сейчас на каждый пиксель перемещения посылается пакет типа:
***<x>***<y>***<a>***<xH>***<yH>***<aH>xx

*** это понятно цифры.

<x><y> это понятно, типа указатель что перед этим была цифра координаты х или у

<xH><yH> - это координаты башни (тут из-за моей немного туповатой системы просчитать местонахождения башни по углу поворота кузова не получается)

<a> угол поворота кузова, <aH> угол поворота башни

xx - длинна всего пакета. типа если длинна не совпадает, то значит пакет пришел битый, и тогда его игнорить, иначе программа не верно разберет битый пакет и вылетит с критом.

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

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

также в целях оптимизации траффика думаю нужно добавить элемент предсказания для клиента. в этом случае трафик можно будет сократить в 2-3 раза. типа если скорость танка 50км в час, то клиент продолжает рисовать его перемещение на несколько метров, а потом делает поправку.


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

[n1ghtmare]

***<x>***<y>***<a>***<xH>***<yH>***<aH>xx

Это ты что ли в текстовом формате посылаешь? Если да то зачем???

Посылая такой пакет в бинарном формате, скажем взяв по 4 байта на каждое значение + длинна (1 байт) + идентификатор (1 байт) имеем 26 байт. Возьмем худший случай когда посылаем по 60 пакетов в секунду (больше даже фпс не смысла делать, не то что обновление состояний). Имеем 2160 байт/с. К примеру скорость GPRS интернета (ага, это мобильный, который даже не EDGE, молчу про 3G а тем более кабельный интернет) 56–114 kbit/second.

Вот. Неужели так сложно посчитать.

[SeregaZ]

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

после будет активное движение 15 танков 15 х 26= 390 байт. спам подобного большого пакета это нормальное явление?

и что лучше - много маленьких пакетов но чаще, или раз в секунду например но большооооооой.

и если этот 390 байтный еще предварительно сжимать? стоит ли игра свеч? в какую сторону сделать уклон - процессорное время (без сжатия) или облегчение трафика (сжатие)?

[n1ghtmare]

Передавая в текстовом ты передаешь слишком много лишней информации, к примеру одно число вместо 4 байт занимает 8 (если оно в хексе конечно) + эти <x> <y> тоже ни к чему.

Как не крути а посылать много пакетов тебе придется. Человеческий глаз видит 24 кадра в секунду, а обновляя раз в секунду у тебя будет слайдшоу а не игра.

Как ты планируешь их "сжимать" ? Советую хотя бы подумать и почитать как это делается перед тем как пытаться "сжимать" 26 байт. Я не уверен что это вообще возможно, так как избыточности практически нет.

[SeregaZ]

есть там в наборе команд некая PackMemory

Syntax

Result = PackMemory(SourceMemoryID, DestinationMemoryID, SourceLength [, CompressionLevel])
Description

Pack the content of the SourceMemory area into the DestinationMemory area. The destinatation area must be at least the length of the Source area + 8. If Result equals 0, the compression has failed (or the file is not compressible with this alogrythm), else it's the compressed size of the Destination area. The compressed data can be unpacked with UnpackMemory(). For advanced users, a callback can be added to follow the packing progress with PackerCallback(). A memory area can be easily allocated with the AllocateMemory() function. 'CompressionLevel' is an optional value which can range from 0 (fastest, least compressed) to 9 (slowest, most compressed).

Note: The compression algorithm is relatively slow, however it produces excellent results (e.g. superior to .zip format) and decompression is extremely fast (faster than .zip).

[n1ghtmare]

Я без понятия что там за алгоритм, но точно знаю что для сжатия нужна избыточность сообщения, которой в простых числах практически нет. Долго объяснять как это работает, но можешь просто проверить, и убедиться что врятли ты сможешь существенно сжать 26 байт, если там конечно нет сплошных нулей, или еще каких длинных последовательностей. Возьми и проверь в конце концов.

[SeregaZ]

а причем тут 26 байт? я говорил о 360 - передача одним пакетом всех движений сразу 15 танков. не думаю что там большая разница с обычным рар архиватором - текстовой файл в 360 байт архиватор жмет до 150 байт. экономия в 2 раза.

точней 390... парюсь 15х26

[n1ghtmare]

Я уже 2 раза написал про избыточность, в 3 раз писать не буду. Спроси у википедии к примеру.