ок. по пунктам:
1.
согласен. имя файла - на свое усмотрение. расширение файла обязательно либо .pkt либо .raw.
2.
Header,
bytes[3] (R,A,W; P,K,T
HeaderVersion,
word (3.0)
ClientBuild,
uint, (число)
ClientLanguage,
uint
DevelopersData,
uint64
SessionKey,
bytes[40]
несколько слов о полях:
- HeaderVersion. в дампе это должно выглядеть "младший байт, старший байт", т.е. так:
Код:
0000000000: 50 4B 54 00 03 CB 2D 89 │ 9D 6F C4 9B 85 20 75 6D PKT☺☻╦-ЙЭo─ЫЕ um
- ClientLanguage. раньше это можно было легко вытащить из авторизационного трафика, там был дамп байтов enGB, enUS, буквы прямо. сейчас это переехало соттветственно в батлнет-трафик. в реалм-трафике на сколько я знаю таких данных не ходит. есть мысли, как мы будем добывать эту информацию?
3.
(byte) Direction; для серверных чанков 0хFF, для клиентских 0хСС.
(uint) UnixTime; UnixDateTime(Now).
(uint) TickCount; GetTickCount();
(byte) ChunkDevelopersData; нам точно одного байта хватит? мы же хотели переменную длину заюзать?
(uint) PKT.Length; длина данных, ВКЛЮЧАЯ Opcode
(uint) PKT.Opcode
(byte[]) PKT.Data
несколько слов о полях:
- ChunkDevelopersData
существуют два варианта реализации - с переменной длиной и с фиксированной. лично я за фиксированную длину, читать данные проще. т.е. давайте выберем один из вариантов:
1.
(uint64) ChunkDevelopersData (8 байт нам точно должно хватить на долго, учитывая что разработчиков сниферов по пальцем можно пересчитать)
2.
(byte) ChunkDevelopersData.Length
(bytes[])ChunkDevelopersData.Data
второй вариант представляется мне гиморным в плане пробегания по снифу. представьте, что бы прочитать следующий чанк нужно
1. по первому варианту:
- прочитать хидер, 1+4+4+8+4+4 байт
- прочитать PKT.Data размером PKT.Length-4 байт
2. по второму варианту:
- прочитать часть хидера, 1+4+4+1 байт
- прочиать ChunkDevelopersData.Data размером ChunkDevelopersData.Length байт
- дочитать хидер, 4+4 байт
- прочитать PKT.Data размером PKT.Length-4 байт
в общем я за первый вариант с фиксированной длиной ChunkDevelopersData. вопрос только в ее длине. 4 или 8 байт?
- PKT
формат записи пакета я
настоятельно предлагаю в естественном и привычном исполнении:
- длина,
включая опкод
- опкод
- данные опкода
только сделать длину поля опкода не переменной, как сейчас 2 или 4 байт, а фиксированной 4 байта. это позволит
вам избежать трудности чтения невыравненных данных (подобный пример у ChunkDevelopersData с переменной длиной).
еще предлагаю ввести поле SnifferID в заголовок снифа.
все вы прекрасно понимаете, что поля DevelopersData каждой командой могут быть использованы на свое усмотрение. и если бы мы собрали такую информацию, то SnifferID помог бы понять, что именно находится в DevelopersData. и на стадии утверждения документа принять разработать и принять эти ID. ну например:
1 - WoWCore
2 - TOM_RUS
3 - Konctantin, LordJZ and Co.
и так далее.
теперь по поводу утверждения формата несколько слов.
"
Если ответа не будет, то думаю можно закончить данную дискуссию и утвердить данный формат". ничего личного, Костя, но так не делают. предлагаю более цивилизованный вариант, как это делается в больших софтверных компаниях, наших, европейских и американских.
в кратце обычно план такой:
- создается документ, описывающий некую функциональность и удовлетворяющий все стороны.
- создается ревью документа с длительностью на какой то срок. скажем, на неделю. вот тут да, можно говорить, если за ревью ничего не было, то документ принимается и присваивается статус "релиз".
а у нас пока что первый пункт не выполнен. то что мы долго это обсуждаем - это не долго, поверьте
конечно, в бизнес-процессе существуют некие чекпоинты. давайте тоже будет цивилизованными и сделаем их. мое видение такое:
- в срок до 31 июля включительно мы должны разработать и утвердить документ, описывающий формат 3.0, который всех бы удовлетворил.
- в срок до 7 августа включительно будет проходить ревью документа.
- 8 августа состоится релиз документа.
- и еще один момент. ревью проводится среди каких то людей. кто у нас будет ревьюить?
всем по моему пофигу, кроме 2-3 человек. но все же я хотел бы пригласить на ревью следющих людей:
- Konctantin
- LordJZ
- TOM_RUS
- RomanRom2
- VDm
- Deamon
- Nomad
- abdula123
- user456
- Aven
- йоха
это те люди, которые я знаю, что они сделали в своей жизни снифер, активно его использовали и обрабатывали снифы, в том числе и от других "производителей". приветствуется дополнение списка ревьюверов.
на самом деле многие сейчас могут сказать, чо вы ерундой страдаете, что бы создать какой то сраный формат из 10 байт. быстренько обсудили и сделали.
давайте попробую ответить:
во первых, ключевая фраза "быстренько". вот у нас всё так, быстренько тяп ляп и погнали. нет четких процессов. и потом получается, тут сказал, тут не сказал, тут слышал, тут не слышал. денег уже нет, а дорога еще не построена. а где деньги то? ну и так далее. да, мы в данном случае быть может стреляем из пушки по воробьям, но блин, это нужно делать!
во вторых, "быстренько" мы сделать не можем, по очень простой причине - мы не собираемся каждый день вместе в своем офисе. было бы так, все было бы гораздо быстрее и легче.
итак,
один из финальных вариантов документа.
1. RAW.
1.1. заголовок снифа.
- Header,
bytes[3]
R,A,W
- HeaderVersion,
word
3.0
Код:
0000000000: 50 4B 54 00 03 CB 2D 89 │ 9D 6F C4 9B 85 20 75 6D PKT☺☻╦-ЙЭo─ЫЕ um
- ClientBuild,
uint
число, актуальная на данную сессию версия клиента. билд может быть добыт из VersionInfo экзешника, из бинарных данных экзешника, из сетевого трафика, иными способами
- ClientLanguage,
uint
enGB, ruRU. актуальная на данную сессию локализация клиента. может быть добыта из VersionInfo экзешника, из бинарных данных экзешника, из сетевого трафика, иными способами
- DevelopersData,
uint64
вспомогательные данные на усмотрение разработчика. это поле не может быть использовано для хранения данных, которые могут влиять на чтение снифа.
- SessionKey,
bytes[40]
ключ текущей сессии.
1.2. заголовок чанка
- Direction, byte
для серверных чанков 0хFF, для клиентских 0хСС.
-UnixTime, uint
стандартная функция UnixDateTime(Now).
- TickCount, uint
стандартная функция GetTickCount().
- ChunkDevelopersData, bytes[8]
вспомогательные данные на усмотрение разработчика. это поле не может быть использовано для хранения данных, которые могут влиять на чтение снифа.
- RAW.Length, unit
длина данных, которые были "пойманы" снифером и подлежат записи в файл.
- RAW.Data, bytes[]
пойманные данные
2. PKT.
2.1. заголовок снифа.
- Header,
bytes[3]
P,K,T
- HeaderVersion,
word
3.0
Код:
0000000000: 50 4B 54 00 03 CB 2D 89 │ 9D 6F C4 9B 85 20 75 6D PKT☺☻╦-ЙЭo─ЫЕ um
- ClientBuild,
uint
число, актуальная на данную сессию версия клиента. билд может быть добыт из VersionInfo экзешника, из бинарных данных экзешника, из сетевого трафика, иными способами
- ClientLanguage,
uint
enGB, ruRU. актуальная на данную сессию локализация клиента. может быть добыта из VersionInfo экзешника, из бинарных данных экзешника, из сетевого трафика, иными способами
- DevelopersData,
uint64
вспомогательные данные на усмотрение разработчика. это поле не может быть использовано для хранения данных, которые могут влиять на чтение снифа.
- SessionKey,
bytes[40]
ключ текущей сессии. для PKT может быть равно нулю.
2.2. заголовок чанка
- Direction,
byte
для серверных чанков 0хFF, для клиентских 0хСС.
-UnixTime,
uint
стандартная функция UnixDateTime(Now).
- TickCount,
uint
стандартная функция GetTickCount().
- ChunkDevelopersData,
bytes[8]
вспомогательные данные на усмотрение разработчика. это поле не может быть использовано для хранения данных, которые могут влиять на чтение снифа.
- PKT.Length,
unit
длина игровых данных, ВКЛЮЧАЯ Opcode.
- PKT.Opcode,
unit
значение опкода, выравненное до 32х бит.
- PKT.Data,
bytes[]
игровые данные опкода