Бинарный таймер

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

Вот пример:
0 0 0 0 - это 4 байта показывающие что таймер стоит на нуле.
0101 1010100 110110 11011001 - это таймер проработал около 58 минут
В декартовом виде эти числа выглядят так:
5 84 54 217

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

Если есть тут люди разбирающиеся в вышке не сочтите за труд разьяснить что тут да как.

http://ru[dot]wikipedia[dot]org/wiki/Дво[dot][dot][dot]истема_счисления

---

Отредактировано администратором: EuGen, 09 Апреля, 2012 - 12:47:56

-----
Чем больше узнаю, тем больше я не знаю.

А в какой системе считает время-то?
За 58 минут забить 3 с лишним байта... В 4 байта с разрешением в 1 секунду время с 1970 по 2038 год помещается.

Да и про вышку вы совершенно зря думаете, не имеет эта задача к ней отношения. bin2dec да base_convert в помощь - получите количество тиков, сколько таймер отсчитал.

-----
PostgreSQL DBA

Дак все было б просто если б через bin2dec base_convert получались бы вразумительные числа.
...но они не получаются
Тут Вы совершенно точно подметили, что в 4 байта можно было вложить сумасшедшую дату но на практике выходит как-то иначе.
Очевидно , что есть определенные требования в сетевом протоколе, например что за таймер должно отвечать строго 4 байта (не больше не меньше) в определенном месте пакета, поскольку перед ними и после них идет совершенно другая информация.
Ну да с этим то уже разобрались, и необходимые байты выделили. Но непонятен сам принцып подсчета времени. Как на глаз , то второй байт меняется, в среднем, раз в 15 секунд. Но вот незадача, в начале отсчета он меняется быстрее. Вот на этом я и завис

Возможно что все эти 4 байта представляют собой одно число. Но в какой системе счисления - непонятно. Думаю что владея знаниями высшей математики ответ было бы проще найти. Но увы. Я в ней не силен. Поэтому и обратился за помощью на форум

(Отредактировано автором: 07 Апреля, 2012 - 14:51:12)

Тут меня посетила идея. Быть может эти 4 байта отображают число с плавающей запятой.
Первый байт, в таком случае, может содержать "+" и степень мантиссы. А остальные , оставшиеся биты, собственно саму мантиссу.
И опять нехватает познаний вышки.

Сделал небольшой дамп пакетов.
Слева число получившееся путем преобразования интересующих битов в DEC
Справа секунды глобального времени (взятые функцией time() ) для того , чтобы было видно сколько прошло реального времени.
Из этого дампа можно сделать вывод , что в декартовом виде , число увеличивается на 1 за определенный промежуток времени. Беда в том, что это видно только по первым 4 цыфрам (слева) а остальные пляшут как попало.
Но возможно это тысячные доли секунды и их просто не удается словить.
И еще странная вещь, которая и натолкнула меня на мысль , что это число с плавающей запятой, это то, что отсчет начинает считаться со второго байта. По достижению лимита значений (11111111) первый байт увеличивается на 1 (что возможно подразумевает степень). Когда же степень доходит до 3-4, то уже можно рассмотреть упорядоченные числа в 3 байте.
И еще одно наблюдение:
1 степень достигается приблизительно за 6 секунд.
2 - 24 секунды
3 - 96 секунд
И т.д. Видно что зависимость не прямолинейная.
Вывод: либо неправильно переводятся бинарные числа в декартовые , либо так и задумано и нужно вычислять формулу по которой можно определить время основываясь на данных этого таймера.

И снова нужна помощь математиков.

sinsir, да не при чём тут вышка. Она в реверс-инжиниринге не используется. Только теория вероятности - какова вероятность того, что это вообще время, а не рандомное значение, указывающее, что это - уже другой пакет данных?
Да и не занимается вышка такими глупостями. Вот если бы вы пытались по ускорениям по 3 осям понять, где вы в системе координат, куда вообще движетесь, да ещё и как изменить положение в пространстве и обороты четвёрки двигателей, чтобы не грохнуться и скомпенсировать западный ветер - вот тут вполне вышка.


Неочевидно. По сети может передаваться любая высокоуровневая структура. Хоть символьная, хоть бинарная.

Что вообще за сервер? Может, его уже реверсили, а то и вовсе документация есть.
(Добавление)

Ровно 4-кратная, линейная.

-----
PostgreSQL DBA

Так сервер то рабочий. Через саму программу клиента , данные получаются в нормальном (человекочитаемом) виде.
Задача стоит как получить теже данные только путем запроса на PHP через браузер.
И поскольку известно что таймер тикает (просто посмотрев через клиент) и потом сняв несколько пакетов с сервера можно выделить только одно место, где есть постоянно увеличивающееся число. Путем логики можно догадаться, что это и есть данные таймера.
Это также подтверждает и то, что когда таймер стоит то и число не изменяется. Тут сомнений нет - это байты таймера.

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

А не могли бы Вы подсказать как из этой 4-кратной линейной зависимости посчитать секунды?
Если интересно, то могу скинуть мой скрипт, который берет пакет с сервера. Может он чемто поможет решению задачи.

Киньте лучше пару сырых hex'ов этой четвёрки байтов, прямо как они в пакете есть и соответствующее время на таймере клиента.

-----
PostgreSQL DBA

01000101 11010101 00010101 00111001 ( 45 d5 15 39 ) - 1 час 53 минуты 38 секунд
01000101 11010101 01000111 10110010 ( 45 d5 47 b2 ) - 1 h 53 m 44 sec
01000101 11010101 01100011 00101001 ( 45 d5 63 29 ) - 1 h 53 m 48 sec
01000101 11010101 10001000 01100000 ( 45 d5 88 60 ) - 1 h 53 m 53 sec
01000101 11010101 10100101 00001110 ( 45 d5 a5 0e ) - 1 h 53 m 56 sec

Здесь видно , что в основном, меняется 3 байт , а первые 2 байта не изменны ( хотя ближе к началу отсчета менялся, в основном , 2 байт)
Эту инфу я получаю снифером. Незнаю насколько точно он их снимает, но вроде другая инфа (буквенная) вся точно совпадает.

О, вот и смысл.
По-видимому, это - IEEE754 Single precision 32-bit[dot]
Последние 3 значения:
6.82839501953125E3
6.833046875E3 (с прошлом метки прошло 5 секунд)
6.8366318359375E3 (прошло ещё 3 секунды)

6836 (6.836E3) секунд же - искомые 1 час 53 минуты и 56 секунд.

Осталась мелочь - из бинарного перевести во float. Но можно не мучиться, а взять из комментариев: http://www.php.net/manual/ru/lan...float.php#101318 Или соседние комменты почитайте там же.

-----
PostgreSQL DBA

А если не секрет как у Вас получилось 6.836, в общем как число такое получить из HEXa?

(Отредактировано автором: 09 Апреля, 2012 - 14:47:17)

На каком из этапов?
Загнал их в сервис по первой ссылке, для перевода силами php посмотрите функцию hexTo32Float по второй ссылке, в комментариях.
(Добавление)
http://habrahabr[dot]ru/post/112953/ - вот, наткнулся случайно. Описано, как выглядит float. И почему он такой.

-----
PostgreSQL DBA

Ура! Кажется дело близится к развязке. Число , как я и догадывался, оказалось числом с плавающей запятой.
Ваша ссылка на конвертер из бинарников в числа с плавающей запятой (да и не только в них) многое прояснила.
+ Вам, и огромное спасибо. ( а то я уже с ума начал сходить )
Теперь осталось всего 2 нерешенные позиции в этом пакете. Одна из них состоит из 5 байт , 4 последних из них постоянно изменяются. Думаю это может быть, как Вы заметили в прошлых постах, какой-то идентификатор пакета, либо же показатель пинга (этот показатель тоже есть).
Но эту задачу постараюсь решить самостоятельно.

P.S. Блин немогу плюсануть Вам. Сказано , что у меня недостаточно сообщений для этого. Подскажите что делать?

(Отредактировано автором: 09 Апреля, 2012 - 15:10:43)

Может быть задержка чисто до сервера - но это слишком эфемерная и бессмысленная величина - часы должны быть синхронны, иначе бессмысленно. Обычно пинг вычисляют на клиенте.

-----
PostgreSQL DBA

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

(Отредактировано автором: 09 Апреля, 2012 - 15:51:07)