Канал для непрерывного обмена данными с сервером - Страница 2

dimarik · 05.01.2009, 22:45

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

DarkLight · 05.01.2009, 22:53

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

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

dimarik · 05.01.2009, 23:06

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

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

BlooDHounD · 05.01.2009, 23:10

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

DarkLight · 05.01.2009, 23:16

Ну возможно, сама java.nio клеит в один пакет 2 мессаджа

так как серверсайд на уровне своих классов рапортует, что пропихнул данные в сокет 2 раза по отдельности.

dimarik · 05.01.2009, 23:29

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

TimID · [+1 18.01.09]

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

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

dimarik · 06.01.2009, 22:15

Цитата:

Сообщение от TimID

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

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

Цитата:

Сообщение от Flash CS3 Help

The following request headers cannot be used...
<skipped>
..Keep-Alive,

Но это неважно, так как HTTP соединение для FP так и останется сеансовым, будь оно с keep-alive или без оного.

TimID · [+1 18.01.09]

Цитата:

Сообщение от dimarik

Но это неважно, так как HTTP соединение для FP так и останется сеансовым, будь оно с keep-alive или без оного.

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

BlooDHounD · 07.01.2009, 21:33

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