Мастера флуда на общие темы, слушай суды, берем Ethereal (модемы ищут спец. библиотеку) или там сетевой монитор дампим именно UDP (а то тут некоторые говоря про убогость протокола всуе TCP поминают) и смотрим. У меня при скорости 56кб данных в пакетах более чем на 300 БАЙТ не было, а есть и по 15 - 20 (что хреново MTU не настроишь). Возможно что это поток, передаваемый дискретно (частота дискретизации зависит от выставленной в настройках скорости связи-это и ежу понятно), возможно что с ACK (черт знает, смотреть надо, а времени нет) Но тогда на сервак ложится задача выравнивать скорости и усекать "лишние" данные из толстых "потоков" в "тонкие" Вот чудится мне там поток сообщений... и возможно такой:
1, ID пилота или объекта (не по никам же вас разводить в потоке)
2. X - точность их можно косвенно определить по логу и они похоже флоаты, точность до сотых милиметра гы!
3. Y
4. z
5. Крен
6. Тангаж - из 2-6 и растет стрельба по пингу
И больше там вроде нафиг ничего не надо (вроде бы), если учитывать тот факт что все остальное считается на клиенте, НО это относительно объекта. А исчо не забывайте что надо бы установить соединение, т.е. передать начальное состояние окр. среды. Это кокрази происходит при заходе на сервак (вот тут-то серваку и плохеет
ибо это надо раздать всем) Тоже просто. Но еще надо организовать мониторинг состояния окружающей среды - получаем служебные сообщения, которые сначала уходят от клиента (принасекоившего, ну к примеру Пака - очень редкий тип сообщения
), а с сервака всем (кроме клиента, про split horison девелоперы должны были что-то слышать) Формат служебного сообщения может быть такой:
1. ID объекта - кто
2. ID объекта - связанный объект (к примеру, вирпил помнял самоль, о чем всем надо рассказать)
3. Состояние - если пришло такое сообщение, то состояние поменялось - мне рисуется что то типа EventLog - номер события и его параметры
По идее, служебные сообщения о событиях можно запихать, при такой схеме, и в первый тип, но на кой ляд мне все время рассказывать где стоит корапь или зена, с другой стороны, получение служебынх сообщений должно быть надежным, следовательно, нужны ACK (от всех, и даже клиенту от сервера, что получил) тоже плохо, но что делать...
В общем, рисуется мне этакая базочка данненьких, периодически подновляющаяся.
Вот что мерещится моему, воспаленному перед экзаменом, сознанию
Сферы счиать может только сервер (клиенту не из чего), а если считать сферы, то почему бы и вообще все не отдать серверу? Пущай загнется родимый. Если правда то, что все обсчитыается на клиентах, коду для такого решения переписывать и переписывать - все заново и серверную часть и клиентскую - проще будет. И хито этим будет заниматься для почти вымирающих модемщиков?
ЗЫ. Реализовывать на серваке 64 массива, а потом их пустые гонять по всему интернету - зря вы так плохо думаете о МГ, я в это почему-то не верю
ЗЗЫ при таком решении очень обидно осознавать, что зена оторвавшая тебе полморды живет на твоей же машине, а не на каком ни будь мифическом сервере.
ЗЗЗЫ При такой схеме можно экономить полосу пропусания на координатах, не так часто их передавать (что и наблюдаеся) а так же второстепенных событиях ну типа там подмигивание пилота, повороты рулей, стриптиз в исполнении зенитчиц...
ЗЗЗЗЫ Паку: Истинный азимут передавать - излишества, достаточно хранить Х и У из предыдущего пакета