Канал для непрерывного обмена данными с сервером
 

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

Меня интересует возможность пересылки пакетов в обе стороны по таймингу (до 10 в секунду). В одну сторону (от клиента) "управление", в другую (от сервера) - "снимок мира".

Цель - сетевая игра.

Используйте Socket либо XMLSocket класс.

О, мерсибо всем.

2d, в TZ используется пакетная передача? Или у вас сеансовый протокол?

TimID, везде пакетная. "не пакетной" не бывает.

XMLSocket лучше не использовать для нагрузок типа 10 сообщений/секунда, Socket оптимален

TimID, в TZ используется постоянное соединение. Простите, не очень втыкаю в термин "пакетная передача". Т.к. что в сеансовой, что в "пакетной" передаются именно пакеты-дейтаграммы. Только в первом случае сокет закрывается (при определенных условиях может оставаться открытым). А лучше проштудируйте ISO-OSI.

DarkLight, на чем такая уверенность основывается?

На личном опыте: частые отправки сообщений приводят к возможности попарной склейки при передаче, и дропа 2го из склеившейся пары при работе с XMLSocket. На локалхосте может и не возникать, по локальной сети и при работе через Интернет баг стабильно воспроизводился. И еще некоторые проблемы возникали с XMLSocket. Пришлось писать свою реализацию поверх Socket.

Т.е. из-за бага в реализации XMLSocket для AVM2? Под AVM1 такого никогда не наблюдал.

Под AVM1 не проводил нагрузочного тестирования. Под AVM2 большие мессаджи разваливаются на 2 части с дропом 1ой из них, частые маленькие - склеиваются парами и даже при большой частоте в единичных случаях тройками, бывало и то и то сразу (дропается 1ая половина большого сообщения, 2ая полвина склеивается с последующим маленьким, в результате чего дропается и маленькое). О надежности оставалось только мечтать. По ощущениям, xmlsocket базируется в avm2 на тупом вызове чтения строки при наличии в сообщении нулевого символа. Все, что оказалось после нулевого символа, игнорируется. Извраты со склейкой/распадом - не вина клиентсайда или серверсайда и происходят при передаче по Сети.

Вы меня прямо пугаете. Из ваших "ощущений" прослеживаю, что виновата именно среда передачи, т.к. "не вина клиентсайда или серверсайда". Линейка игр от территории работает на хмлсокет, может как-то Вы не так что делали?

Есть баги в XMLSocket при обработке искаженных в процессе передачи сообщений. Искажения я перечислил. Происходят они лишь при высокой частоте отправки сообщений (для случая отправки нескольких сообщений с малым интервалом, точнее). Серверсайд отправляет 2 сообщения по 300 байт, допустим, с интервалом в несколько мс. На сокет приходит одно в 600. Обратная схема тоже верна, но flash-клиенту отправлять с таким малым интервалом практически никогда не нужно.

P. S. Неправильно использовать XMLSocket - это надо постараться:)

1. Искажений при передаче посредством TCP/IP быть в принципе не может.
То, что принялось якобы искаженным было отправленно искаженным, либо искаженным трактовалось. Среду передачи отбрасываем сразу. Сообщение либо доставлено то, каким отправлялось, либо системный стек протоколов его не смог доставить. Точка.

Предполагаю, что "серверсайд" сам запихивет два zero-ended string'а в один пакет. Может быть в этом бага при разборе.

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

Ну возможно, сама java.nio клеит в один пакет 2 мессаджа:) так как серверсайд на уровне своих классов рапортует, что пропихнул данные в сокет 2 раза по отдельности.

Если мне встретятся непонятки с XMLSocket, то вооружившись любимым Microsoft Network Monitor'ом, можно легко определить кто неправ =)

2dimaric, хм, неудачно выразился. Я имел ввиду соединение по http с keep-alive (как сеансовый) или "свои пакеты" через постоянное соединение.

2All.
Кстати, никто не пробовал http метод CONNECT использовать для организации соединения? Сделать псевдо SSL, так сказать.

Keep-alive реализуется на уровне приложения (браузера) для уменьшения издержек, связанных с ресурсоемкостью создания сокета. Flash Player не может управлять режимом keep-alive напрямую. Нам даже запрещено создание такого заголовка (request header).
Но это неважно, так как HTTP соединение для FP так и останется сеансовым, будь оно с keep-alive или без оного.

Вообще-то важно, можно не ожидать выполнения запроса (ответа сервера), делая запрос PUT или подобный для передачи только "управления" от клиента.
Я полагаю, что для пользователя главное - непрерывность передачи управления на сервер, чем fps передачи кадров с сервера. Чтобы скорость соединения не сказывалась на возможностях игрока. Это исключит "закликивателей".

TimID, трафиком со стороны клиента можно вообще пренебрегать, ибо он минимален в 99% случаев. по простой теории вероятности, если каждый пользователь делает постоянные монотонные действия, то соотношение трафика output/input будет равно 1/количество_пользователей. пользователю наплевать на "непрерывность передачи". он вообще не знает, что это такое. ему главное, видеть реакции Приложения на его действия, и адекватность этих реакции.

2BDHD, не согласен. Вы, видимо, не играли в DOOM первых версий по сети. Медленный компьютер заведомо обрекает игрока на проигрыш из-за "ощутимой дискретности" движения. Например, выстрел в стрейфе между "шагами" был невозможен. Если бы физическое и графическая подсистема были "развязаны", то можно было бы двигаться в слепую, видя только результат.

В нашем случае, мы говорим не о монотонности действий, а о "быстрой последовательности управляющих действий" (combo, например). большой fps для этого не нужен, нужна возможность передать их адекватно серверу.
В ответ я согласен не видеть анимацию огненного шара, достаточно "отлетающего врага" ;)

Это и есть "адекватность реакций", по моему.

Угу, кстати в MMORPG (не браузерных, а mainstream, вроде WoW, LA) сначала решает Ping/latency, а потом уже скил=)

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

на сколько мне известно Дума первых версий по сети не было.

я профессионально играл в кваку 2/3. если пинг был больше 30-40, я даже не пытался играть, ибо моя рельса не попадёт:
1. делаю выстрел ибо вижу юзера "там".
2. рельса проходит через этого юзера.
3. я не попадаю! почему?
4. потому, что рельса нарисовалась когда я выстрелил, а пользователя там не было, так как я об этом узнаю только через 60мс.
5. насрать мне на анимацию шара. верно. я ж всё равно не попал!

так вот адекватным действием приложения было бы не показывать мне пользователя "там".

ещё обьясните мне как двигаться "в слепую" и при этом "видеть результат". такого не бывает в принципе :)

попробую объяснить ещё раз. слово "монотонность" я использовать, что бы показать статистические данные. типа пример идеального газа.

у нас в играх output-трафик составляет меньше одного процента. например команда "идти туда-то" занимает приблизительно 9 байт. собрать такое "огромное" количество данных и отправить их на сервер занимает такой мизер, что мы даже замерить не можим. меньше 0.5 миллисекунды. доставка команды на севрер занимает ping миллисекунд. тоесть в большинстве случаем >50 миллисекунд.

если разделить на обработку комманд на временные процессы, то получится 3 части:
1. отправка клиентом
2. пересылка
3. обработка севрером

по вермени это занимает так:
1. 0.01%
2. 99.98% (безконтрольное время)
3. 0.01%

BlooDHounD, я конечно извиняюсь, но в Q3 довольно хороший сетевой код и хорошо играть (читай: попадать из ррейлгана) вполне можно умудряться порой даже на 700ms. В Q3 клиент пытается предсказать движения и таких проблем обычно не возникает. Можете говорить сколько хотите, но факт остается фактом - посмотрите любой дуэльный сервер с модом excessive plus.

Кстати, ни в одной другой сетевой игре такого хорошего предугадывания перемещений не видел.

Так что нельзя сваливать все на медленную передачу данных. Часто просто код не доведен до ума.

AL.exe, гы ... порадовало. 700 мс в 3й кваке, это очень много. оооооочень.

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

Chas, ну извините :) я уже подзабыл, а во времена когда у нас появилось такое открытие, это была квака первая. поэтому в дум я играл только сингл, и не помню. но в целом к вопросу это мало относится. я лишь высказал свою осведомлённость о наличии там мультиплэйера.

У нас в клубе, был парень, который легко на клаве делал многих играющих (в кваку) на мышке. Руки при этом он держал крест на крест, за что получил прозвище "пианист".

Ну, если на то пошло то в кваке мышью вообще не целятся.

По теме:

BlooDHounD, 700 ms действительно большой пинг, но играть в ку3 в большинстве случаев он не мешал. Да хоть сейчас загрузите и посмотрите на каком-нибудь из таких серверов - все игроки двигаются гладко и без дерганий, как, например, в каком-нибудь S.t.al.k.e.r, где игроки "мелькают" уже после 100-120ms. Просто в q3 предугадывается расположение противника по какому-то гибкому алгоритму. Да, не идеально и да, с косяками, но приноровится игроку позволяет. Проблемы не всегда нужно сваливать только на сервер.

Эээ, а чем там целятся? На консолях да целятся аналоговыми стиками=) а на компах только мышкой, щас пойду проверю.


700 мс это нифига не большой пинг, это офигенно огромный, у меня один раз в FaCry был пинг 500ms+, но только на полминуты.

2Chas - а мы еще на "сопле" думили. Кстати, некоторые клоны w3d, вроде, тоже по "прямому кабельному" работали. Один-на-один.

Ping от игрока не при чем. Нужен просто достаточно большой fps на сервере. И хороший алгоритм сглаживания команд управления от пользователя. Предсказуемый.

Пример - Porcshe Unleashed - я играл на 166ммх + 3dfx. В некоторых местах fps доходил до 1сек при скорости под 300км/ч - но играть было можно: Между кадрами жмешь "поворот". Управление считывается гораздо чаще чем происходит отрисовка, поэтому машина поворачивает вовремя. И следующий кадр уже видишь в "контролируемом заносе".
По ощущениям - как управление машиной "на рефлексе" в "жутком перепое". Но ехать-то можно!

Отсуюда и вывод, главное - передавать управление от игрока как можно чаще, а картинку получать "по возможности". Игрок сможет приноровиться.

AL.exe, слушайте: я не знаю, что у вас за Ку3, но мой говорит мне, что если не стоять на месте то играть низя. дальше можете меня не убеждать ибо, я так понимаю, вы играть толком в шутеры не умеете, и не понимаете, что как не предсказывай действия, за 700ms человек может 2 раза "застрэйфиться" в разные стороны, и "рокетджамп", и я честно не понимаю, как можно предсказывать такие действия, не зная о них. добиться плавности движения и отобразить реальные события - это совсем разные вещи. для меня большим пинг считается >40, дальше рельса начинает врать, если враг не стоит.

TimID, о каком Вы фпс на сервере постоянно говорите? и зачём он нужен?

FPS на сервере? Это что то новое=)

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

fps - FramesPerSecond - кадры в секунду. Не графические картинки, что Вы видите на экране, а кадры "обсчета мира". Если основной поток успевает обсчитать 50кадров в секунду (не рисунков, а положений всех объектов на сцене), то физика в FPS (FirstPersonalShooter) будет практически идеальной.
С какой частотой клиентский канал "от-сервера" позволит выбирать (извлекать) кадры - не важно, важно чтобы частота передачи пакетов с управлением была близка к "серверному fps".
Пинг - это время "туда-обратно" и почти всегда "туда", гораздо быстрее, чем "оттуда". Если слать все без подтвержения (UDP) было бы вообще хорошо, но с flash это не пройдет. Мне так кажется. Архитектура не та, чтобы UDP протокол использовать успешно.

Что я непонятно говорю? Или у вас у всех "тормоза" начались и вы "мыслями по древу растекаетесь в ожидании пинга?"

Тему видели?
Расшифровываю:
Нужно передавать управление от клиента, структуру размещения объектов (сцена) и дополнительные данные (текстуры, модели и т.п.). Как организовать взаимодействие с сервером из flash.

TimID, объясните мне смысл быстрой передачи информации о действиях на сервер, если эти действия основаны на устаревших данных с экрана, а?

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

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

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

второй обзац это такой вид хамства?

вы всё понятно говорите, только как-то бредова :)

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

А кто говорил о шутере?

Я копаю в направлении он-лайн симулятора.
Там временной лаг между поворотом штурвала и реакцией корабля может быть довольно большой. И секундные задержки - не проблема.

Ээээ, мне даже как-то неловко цитату из предыдущего вашего поста приводить:

Так шутер или нет?

Добавлено через 2 минуты
И да, плюсик за «тормоза».

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

Бывают переодические события обновление (TEN_MS, HEART_BEAT и тд и тп), но это совсем другие вещи.