Добро пожаловать! Это — архивная версия форумов на «Хакер.Ru». Она работает в режиме read-only.
 

игнорирование управляющих символов

Пользователи, просматривающие топик: none

Зашли как: Guest
Все форумы >> [Компилируемые языки] >> игнорирование управляющих символов
Имя
Сообщение << Старые топики   Новые топики >>
игнорирование управляющих символов - 2012-04-19 12:54:58.840000   
ii_sour_ii

Сообщений: 14
Оценки: 0
Присоединился: 2012-03-07 12:19:17.586666
Доброго всем времени суток.
Занимаюсь тут одной очень "увлекательной" штукой, и столкнулся со следующего рода проблемой:
Пишу своего рода "брандмауэр", который должен обрабатывать определенного рода трафик. Для этого пользуюсь уже готовой либой netfilter, которая позволяет перехватывать трафик на уровне приложения, как-то его обрабатывать и передавать дальше в канал. Причем пользуюсь её оберткой под .NET (приложение пишу на шарпе, т.к. это выгодно с точки зрения обработки трафика). Соответственно проблема вот в чем: протокол, по которому передается необходимый мне трафик, включает в себя некоторые сообщения, в которых ближе к концу встречается пресловутый управляющий символ "/r", а после него идет некоторая последовательность критичных для протокола обмена байт. Только вот эта либа, как только встречает символ "/r", обрезает остаток сообщения и передает получившийся буфер в обработку. Соответственно, на стороне приема, происходит повторная обработка, но, поскольку этих "критичных" символов в буфере не находит, говорит "дазззвиданья!!!", то бишь ACK | RST. И все.
Соответственно вопрос: можно ли как нибудь не копаясь в исходниках либы, заставить компилятор обходить этот пресловутый "/r"?
Post #: 1
RE: игнорирование управляющих символов - 2012-04-19 13:17:46.723333   
_SaZ_

Сообщений: 4329
Оценки: 398
Присоединился: 2008-01-30 02:18:05.553333
Не знаю, какие там типы стримов используются, но нужно явно указать, чтобы они обрабатывались как бинарные (тогда символы \r\n\t и прочие будут проходить "как есть"). А вообще - очень мало информации, сложно что-то посоветовать.

P.S.
quote:

(приложение пишу на шарпе, т.к. это выгодно с точки зрения обработки трафика)

Улыбнуло… Я бы сказал C# выгоден как язык с достаточно мощным набором базовых классов и как язык с низким порогом обучения.
Post #: 2
RE: игнорирование управляющих символов - 2012-04-19 13:26:12   
ii_sour_ii

Сообщений: 14
Оценки: 0
Присоединился: 2012-03-07 12:19:17.586666
хм.. дальнейшее копание выявило следующее: при отключенной обработке "отправляющая" сторона (та, которая отправляет буфер с символом "/r") видит буфер в длину на 4 байта меньше (которые идут за /r). Но отправляет все сообщение, поскольку на приеме уже высвечивается полная длина буфера (соответственно при приеме из канала разрбор идет правильный, т.к. берется вся длина). Думаю, стОит написать разрабам…

З.Ы.: на шарпе, т.к. именно хороший набор классов для решения требуемой задачи по обработке =)
Post #: 3
RE: игнорирование управляющих символов - 2012-04-19 14:48:02.493333   
ii_sour_ii

Сообщений: 14
Оценки: 0
Присоединился: 2012-03-07 12:19:17.586666
Также, для большего кол-ва информации:
Либа представляет собой открытый пользовательский интерфейс, в котором определяются функции-обработчики событий, связанных с сетевым обменом, а также запускает свой поток, прослушивающий интерфейс. Из всех обработчиков мне необходимы только 2 из них: это tcpSend и tcpRecieve, в параметры которым передаются из глубины либы (судя по описанию на офф сайте - дровина TDI) полученный от приложения буфер и его длина. Как раз при тестовой печати этой длины получается недостача 4 байт…
Post #: 4
RE: игнорирование управляющих символов - 2012-04-19 21:02:54.060000   
ii_sour_ii

Сообщений: 14
Оценки: 0
Присоединился: 2012-03-07 12:19:17.586666
[sm=cn.gif] Чет я совсем того… Совсем забыл про nagle… Вот и результат.. В общем вопрос снят.
Post #: 5
Страниц:  [1]
Все форумы >> [Компилируемые языки] >> игнорирование управляющих символов







Связаться:
Вопросы по сайту / xakep@glc.ru

Предупреждение: использование полученных знаний в противозаконных целях преследуется по закону.