as3 + сокет
 

пишу as3 сокет клиента
сервер на java

подскажите как обычно для многопользовательской игры делают с помощью сокетов непрерывный обмен данными

я имею ввиду общий философский подход

то есть 10 раз в секунду от as3 идет запрос на сервер

или делается какое либо событие

или как то по другому?

Добавлено через 4 минуты
в частности если на java сервере происходит какое либо событие
то как as3 об этом узнает = постоянно опрашивая сервер
или будет брать данные по факту какого либо as3 события?

Если что-то произошло на сервере - сервер должен отослать сообщение об этом флешке, и наоборот. Сокет-соединение непрерывно, по этому (в случае с java) нет необходимости что-то отсылать каждые 2 секунды. Только по событию. Правда в java нет такой модели событий как во flash, но сути это не меняет

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

не пользуйте подход "сериализации" данных, передаваемых серверу или обратно, как это делает протокол AMF. Протокол был придуман голодным программистом и продан за 1 рупию голодному менеджеру

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

Т. е. сериализованные данные в командах передавать ну вообще не труъ?

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

Ну, сериализация - это же не обязательно XML. Можно и в свой формат.

Если вы пишете свой сервер и юзаете свой сокет на АС3, то не гут пользовать AMF.
Если вы пользуетесь средствами АС3, то выбора нет - придется пользовать :)

Сериализация команды connect в AMF0 выглядит примерно так 0x03 0x00 0x07 'C' 'o' 'n' 'n' 'e' 'c' 't' .
т.е. байт, обозначающий тип данных + 2 байта длина данных + сами данные.
(плюс 12 байт заголовка к пакету)
Идею Коннекта можно передать на другую сторону меньшим числом байт.


Нормальный программер бы уложил все в 2 байта (1 байт тип данных=команда + код команды 1 байт) или в 3 байта (если бы хотел сделать запас на 65 тысяч команд)

придумайте свой протокол (это не сложно) и вперед.
Опишите все, что должен знать сервер о клиенте и наоборот. Каждой команде назначьте отдельное значение от 0 до 255 (или от 0 до 65535). В зависимости от команды (по вашей задумке) ее будет сопровождать некоторое количество данных (или не будет). Т.е. если например пришла команда 0x01, а мы знаем что за этой командой не должно быть данных, стало быть следующий байт в сокете - новая команда :)
Если команду сопровождает N байт, то за кодом команды пишем 2 байта - длина данных, затем сами данные.
И так далее

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

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

а какая организация команд на as3 будет слушать сокет?
как это будет выглядеть?

тут все подробно описано
http://help.adobe.com/ru_RU/ActionSc...0204-7cf7.html

Crenth, это всё понятно, непонятно только, причем тут вообще сериализация. Сериализовать можно с тем же успехом и в байтики.

Crenth интересный подход, изучаю
про "не думайте, что у всех мегабитный анлим"
факт - особенно в нашей стране

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

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

я думаю, что у адоба такой неоптимальный подход применен во всем. ибо он встречается уже в базовых вещах. например, из RFC RTMP "The protocol supports up to 65597 streams". Вы можете себе представить ситуацию, когда написанный вами на АС3 медиаплеер одновременно получает от сервера 65597 видеопотоков ? Понятно, что серверу надо поддерживать много коннектов одновременно. Но для чего такая избыточность в р2р протоколе ?

или, например, для передачи значения Stream ID в RTMP кое-где используется представление 32-bit little endian, а кое-где 32-bit big endian и даже 64-bit floating point number.

или, например,по умолчанию при передаче аудио адоб использует 2 frames per packet. Родной кодек Nellymother пакует звук микрофона в 64 байта. Два фрейма по 64 байта плюс 1 байт заголовка = 129 байт. Упс: по умолчанию (цитата из RFC) "The default chunk size is 128 bytes". Стало быть дефаултная передача будет юзать в 2 раза больше пакетов: потому как надо же один лишний байтик передавать тоже

или (цитата RFC) "The maximum chunk size can be 65536 bytes and minimum 128 bytes"
а в команде изменения chunksize для передачи нового значения chunk size используется 4 байта
Упс опять :)

и так далее :)

говорю же, вся проблема в том, что пипл забыл, что такое процессор i8086 с 1 Мб памяти и 20 Мб HDD и как на такой комп втиснуть задачу, чтобы она летала

заколоть их вилами за неоптимайзенный код :)

P.S. у меня на винте 140 тысяч файлов. из них 110 - от адоба :) после установки одного из продуктов

AMF такой потому что до этого был AMF0 и в нем не было понятия шаблона класса. Т.е. сериализовать свойства по индексам было нельзя. С другой стороны - там есть небольшая оптимизация при пересылке больших объемов однотипных объектов. Т.е. строки записываются в "словарь" и потом используются алиасы. Но для коротких сообщений это бесполезно... Как бы, если не хочется изобретать велосипед, то есть protobuf, он пожалуй будет по-продуманнее и по-оптимальнее в смысле трафика, но его AS3 часть, и особенно генератор малость корявые, и их надо зачистить напильником. Кроме того, в нем по спецификации есть типы данных, которые AS3 не поддерживает. Хотя, конечно, решения заточеные под конкретную задачу в любом случае заборят любое даже очень хорошее решение более общего плана.