supernewbie, я не думаю что будет игнорироваться размер следующего пакета, при отправке сразу нескольких, ведь если игнорируется длина следующего пакета, как тогда узнать настоящую длину при таком слиянии? =)
у меня длина пакета в проге никак не выделяется, она просто пишется в логах вместе со всем пакетом в первых двух байтах, ибо я с сокета криво читаю (т.е. читаю все, что мне дает сокет, а не то, что мне нужно), об этом мне уже все пояснил Yegor в своем посте. а что касается того, почему работает, если буфер такой загаженый, ответ прост, я обрабатываю не весь буфер, а лишь длину, которую ему задаю. (т.е. длину, которая указана в первых двух байтах)
supernewbie, да в l2clientemu этот момент упрощен, я тоже изначально по нему учился работать с пакетами и потом очень долго искал в чем ошибка когда сбивалась шифрация пакетов.
Kilatif, а на каком сервере ты тестируешь? Там точно нет доп нестандартной шифрации?
В твоих логах второй пакет начинается с 1F 00 а в заголовке указано что Length: 1231 (0x4CF), откуда взяты эти цифры?
это число взято при приеме пакета из сокета, т.е. это то самое Len, а не размер из первых 2 байт. ну и я не думаю, что на том серве есть доп шифрация, ибо l2phx видит все нормально, при этом я не использую никаких newxor.dll и даже обход смены xor. ну а вообще, это шоки =)
хм, можно тада тыкнуть пальцем где в l2clientemu при парсе пакетов логин серва идет взятие инфы о длинне из этих двух байтов?
из за того что логин сервер не посылает подряд больше одного пакета между посылками клиента (и наоборот тоже), а так же учитывая малый размер пакетов, то при общении с логин сервером крайне маловероятно получить TCP пакет (хотя TCP потоковый протокол и правильнее названить это просто порцией данных) не равный игровому пакету, а вот с геймом дело обстоит не так идеально и от него может одной порцией приходить любое, в том числе и дробное количество игровых пакетов, так что там надо обязательно ориентироваться на первые два байта перед каждым пакетом.
ЗЫ через пакетхак всё пашет потому что он разбирает на пакеты и в сокет для твоего бота пакеты попадают "правильными" порциями, а поскольку пакетхак и бот на одном компе то трафик между ними уже не обрабатывается никакими маршрутизаторами и аналогичными устройствами которые могут "склеивать пакеты"
Добавлено через 3 минуты
Цитата:
Сообщение от Kilatif
Ну и если проанализировать даже вот те логи, которые я скинул, то видно, что вроде как после той части, что я выделил жирным цветом (это в l2phx полностью второй пакет) сразу должно быть C8 00 - размер следующего пакета, а там не понятно что....
ну дык правильно, у тебя же этот размер типо "дешифровался" вот он и превратился в хз что ибо после реального конца второго пакета шифрация вся сбивается и начинает лишь корёжить данные
__________________
Я здесь практически не появляюсь!, Skype - ikskor
Последний раз редактировалось xkor, 17.07.2011 в 20:18.
Причина: Добавлено сообщение
ну дык правильно, у тебя же этот размер типо "дешифровался" вот он и превратился в хз что
Ну вот, я же говорю что скорее всего все легко решаемо. Спасибо большое за помощь.
Добавлено через 1 час 17 минут
Теперь другая проблема... Ну не столько проблема, сколько очень любопытно, что же это? В общем... После каждого второго пакета NpcInfo (и только его) приходит 8 байт непонятно чего. Причем именно после каждого второго, не больше, не меньше. Это с чем-нибудь конкретно связано?
P.S. В l2phx все также отображается нормально, размер байт все так же является 200 для NpcInfo, не смотря на эти 8 байт лишних после каждого второго пакета.
P.P.S. Пакеты я смотрел Wireshark-ом, а не своей программой.
Последний раз редактировалось Kilatif, 18.07.2011 в 00:32.
Причина: Добавлено сообщение
Kilatif, как warshark может разбивать непрерывный поток шифрованных данных от L2 сервера на пакеты?
И как отображает эти пакеты пакетхак? Вообще никак?
Yegor, пакеты от wireshark разбивал я сам, учитывая первых 2 байта каждого пакета, что это размер. в пакетхаке отображаются они нормально, никаких лишних 8 байт нет. Я бы не интересовался бы этим, но просто в моей проге эти 8 байт мне мешают нормально читать пакеты, а считать каждый второй NpcInfo как то не хочется =)
Yegor, дык я ж говорю, эти 8 байт появляются и в моей программе, вот и получается что после 2 пакетов NpcInfo моя прога ловит эти 8 байт и начинает искать там в первых 2 байтах размер пакета, а в них этого нет.
Последний раз редактировалось Kilatif, 19.07.2011 в 11:02.
Причина: Добавлено сообщение
В общем эти 8 байт моя ошибка.. Все нормально, проблема исчерпана наконец =)
Добавлено через 6 минут
У меня еще один вопрос есть... Вот есть сокет, он принял кусок данных. Этот кусок данных будет хранится в сокете до тех пор пока я его не прочитаю или он может стереться, если я его не успею прочитать? Пример:
Есть в сокете 10 пакетов я читаю из сокета 1 пакет, потом очень долго его обрабатываю, когда в следующий раз читаю сокет - он мне выдает уже 5-ый допустим, а первых 2-4 так и не выдает. Может быть такое? Или сокет будет ждать до тех пор пока я не заберу у него очередную порцию информации?
Последний раз редактировалось Kilatif, 20.07.2011 в 17:04.
Причина: Добавлено сообщение