Страниц: 1 [2] 3 4 5
  Печать  
Автор Тема: TCP/IP over /dev/ser*  (Прочитано 39824 раз)
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #15 : Июля 29, 2002, 04:02:00 pm »

И теперь, оглядываясь на сделанное, можно подвести некоторые промежуточные итоги.

1.Если кому нужно организовать взаимодействие по /dev/ser 2-мя крмпами, не пудрите мозги, для этого оптимально используется PPP, не надо ничего мудрить. Тем более, что эффективность такого обмена будет заведомо выше, чем с любыми механизмами, подобными devn-fd.so или что-то такое. Почему?

1.1.pppd не требует никакой MAC-адресации концов канала, это безадресный протокол тунелирования на линии "точка-точка" - просто информация гонитсяв трубу: в один конец втекает - в другой вытекает. Нет никаких накладных расходов по перелопачиванию MAC-адресов (при чём, при параллельном подключении нескольких устройств к линии, см.ниже - перелопачивание делается на всех хостах, и на всех, кроме одного - в холостую).

1.2.pppd в QNX реализации (или это BSD или OSF реализация?), похоже, делает уплотнение или исключение избыточной информации из IP-пакета, я пока не берусь утверждать, мне много непонятно, но вот dump одного ICMP пакета, пересылаемого по "ping 20.0.0.2" по PPP:

0x00: 1F 0D E8 78 08 1F 3B 0A | 18 0B 08 08 C9 89 18 D8
0x10: 7C 4C 09 18 18 39 39 5A | 5A 7B 7B 5A 5A 7B 7B 18
0x20: 18 39 39 18 18 39 39 5A | 5A 7B 7B BA FF 0D

а вот он-же, приводимый мною ранее при обсуждении devn-fd.so (т.е. не он-же, а пакет, передаваемый в аналогичной ситуации через devn-fd.so, и это мне гораздо понятнее: нормальный IP-пакет, в теле которого содержится ICMP-сообщение).

0x0000 4500 0054 3836 0000 ff01 5b70 1400 0001
0x0010 1400 0002 0800 8113 2c00 0000 68a2 413d
0x0020 b109 0500 0809 0a0b 0c0d 0e0f 1011 1213
0x0030 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
0x0040 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
0x0050 3435 3637                              

Пока это всё предварительно, но посмотрите 0x2E (+/-один, может я не совсем там обрезал) байт вместо 0x54. С этим ещё нужно разобраться. Как я получил этот PPP пакет (дамп) - если кто захочет повторить и покопаться? Это не совсем очевидно: ppp соединение устанавливается только с 2-х концов одновременно, его нельзя надурить как devn-fd.so, посылая пакеты "в никуда", tcpdump не работает с установленным интерфейсом ppp0... Получал я ppp пакеты так:
-устанавливаю ppp-соединение по всем правилам, с 2-х сторон, согласованные режимы и скорость...
-убиваю на одной стороне pppd по kill;
-некоторое время могу посылать пакеты на "живой" интерфейс (пока pppd не почувствует, что канала не стало, ну по ping это длится до бесконечности);
-на конце "убитого" pppd можно канализировать поступающие ppp-пакеты в файл: cp /dev/ser1 file.

1.3.можно открывать несколько PPPx для соответствующих /dev/serx - там кто-то об таком спрашивал, можно создать дублирующие линии между одной парой хостов: по /dev/ser1 & /dev/ser2, по идее - можно на эти PPP каналы надстроить qnet, если, конечно, кому-то удасться доподлинно запустить qnet с bind=ip - пока это только разговоры...

2.Теперь об devn-fd.so. Это совсем другая история - здесь пытаются программно моделировать MAC-уровень и обработку MAC-адресов. Эта модель имеет хоть какие либо реальныее основания для применения, когда электрически на канале находятся несколько устройств с отличающимися MAC адресами. Это физически вполне реализуемо в стандарте RS-485 (умельцы от электроники делают это и нестандартно используя RS-232, но это годится только как макет). Кстати, есть простейшие адаптеры RS-232<->RS-485, т.е. различия только электрические: дифференциальный сигнал по 1-й паре, а программист может рассматривать такой канал абсолютно как привычный /dev/ser (RS-232), на котором висит "много" (>2) хостов.

2.1.Формат (протокол) MAC-уровня. Может быть произвольный, разработчик может его выдумывать абсолютно произвольно, важно, что в MAC-заголовке должны обязательно содержаться 2 MAC-адреса - источник и получатель (я там выше спрашивал - какой их порядок. Это опрометчивый вопрос - любой! Это может быть формализован Ethernet MAC-формат, TokenRing MAC-формат и т.д. ... а здесь - devn-fd.so посылает и devn-fd.so принимает). Раз уж они у нас есть, рассмотрим дампы MAC-пакетов посланные devn-fd.so, и перехваченные на ответном /dev/ser.

Вот дамп ARP-запроса (его я ещё не приводил):

0x00: FF FF FF FF FF FF 00 60 | 00 00 00 02 08 06 00 01
0x10: 08 00 06 04 00 01 00 60 | 00 00 00 02 14 00 00 01
0x20: 00 00 00 00 00 00 14 00 | 00 01

А вот дамп ping-запроса (его я уже несколько раз рисовал, только не путайте - иногда он фигурирует как MAC-пакет, как здесь, а иногда, как IP/ICMP-пакет - тогда всё тоже, но начиная с 14-го байта):

0x00: 00 60 00 00 00 04 00 60 | 00 00 00 02 08 00 45 00
0x10: 00 54 38 36 00 00 FF 01 | 5B 70 14 00 00 01 14 00
0x20: 00 02 08 00 81 13 2C 00 | 00 00 68 A2 41 3D B1 09
0x30: 05 00 08 09 0A 0B 0C 0D | oE 0F 10 11 12 13 14 15
0x40: 16 17 18 19 1A 1B 1C 1D | 1E 1F 20 21 22 23 24 25
0x50: 26 27 28 29 2A 2B 2C 2D | 2E 2F 30 31 32 33 34 35
0x60: 36 37                                            

Вот это и есть формат MAC-пакетов, используемый devn-fd.so - первые 14 байт - это MAC-заголовок:
- 6 байт - адрес получателя;
- 6 байт - адрес источника;
- 2 байт - это, похоже, "тип сервиса", у ARP (который является чисто пакетом MAC-уровня, не IP) - он 0806, у IP (я не думаю, что этот MAC-уровень мог бы различать что-то "под" IP: ICMP, UDP, TCP) - 0800. Хорошо видно, как ARP-запрос посылается по широковещательному MAC-адресу FF:FF:FF:FF:FF:FF, и это всё работает (напомню, работает на последовательной байтовой линии /dev/ser, которая ни сном ни духом не знает ни о MAC-адресации, ни о широковещании, и, тем более, об IP - всю эту обработку берёт на себя devn-fd.so).

Мне кажется, что беда devn-fd.so в том, что QSSL в этом своём формате MAC-пакета упустила одну очень важную вещь, без которой всё это не может устойчиво работать в принципе: длину (то-ли всего MAC-пакета, то-ли последующего за MAC-заголовком тела пакета, не важно), но об этом - чуть попозже.

2.2.Было бы очень хорошо, если бы в качестве MAC-формата QSSL пошла по пути использования чего-то более стандартного, того же ModBus, о котором много упоминали здесь в форуме, и который является фактически стандартом (одним из) передачи уровня MAC, и физическая модель обмена RS-485 как раз и опирается на некоторую подобную модель MAC. Но так QSSL не сделала, и сейчас посмотрим, что ж из этого получается.

2.3.Что делает devn-fd.so? И что делает не так? Делает что-то вроде следующего:

int fd=open( "device", ... );
while( true ){
  читать MAC-пакет;
  if( MAC.dst == собственный MAc || MAC.dst == широковещание ) {
     выделить пакет, инкапсулированный в MAK;
     обработать в зависимости от типа пакета;
  }
}

А как сделано "читать MAC-пакет"? По поведению - несомненно что-то вроде:
read( fd, MAC_buf, mtu );
- поскольку mtu он знает, он его сам может даже устанавливать при запуске (может ли? что-то к QSSL никакого доверия нет...).

Почему это работает. Потому, что QSSL определили devn-fd.so в документации как-то так (как помню, под рукой нет, но смысл точный): "интерфейс обмена с устройствами, представленными файловыми дескрипторами", да и само имя devn-fd.so - об том же говорит. Вот эти "файловые дескрипторы" QSSL и подвели: отлаживались они, почти наверняка, на файле, в который "ручками" вогнали MAC-пакет ... и в этом случае всё работает. Я уже писал, что для QSSL такое понятие, как "программа тестирования" - пустой звук (поймите меня правильно, программа тестирования - не утверждённая гербовыми печатями, а в голове, когда вся последовательность тестов должна прогоняться в полном объёме и с самого начала при внесении любых изменений в код). Работает - "ура" - и в поставку.

Что происходит с /dev/ser? Выписанный выше read() - возвращается при поступлении 1-го же байта в /dev/ser - вот вам пакет, и тут же отбраковывается, и так ... while( true ). И, в общем, всё правильно - на момент read() - в буфере только 1 байт, а следующий ... прийдёт скоро - это в файле - всё в порядке, весь MAC-пакет целиком лежит!

2.4.Чем ему можно помочь? Я уже писал - установить stty или другим средством параметры ввода для /dev/ser в raw-моде, когда минимальная порция ввода (блок) будет равен mtu, и тайм-аут, равный времени считывания mtu-байт на той скорости, на которую настроен /dev/ser.

Будет это работать? Почти: любой пакет, короче mtu будет буферизироваться, и поступать на обработку по истечении тайм-аута. Будет это хорошо? Нет, это будет очень плохо: приём пакета, обычная длина которых редко >100 байт будет занимать время mtu=1500 байт (и всё это ещё в черепашьем масштабе времени скоростей /dev/ser). Будет это надёжно? Нет, не будет, по 2-м причинам:
-если после короткого пакета последует ещё один, с интервалом меньше времени передачи mtu байт - то они сольются, в лучшем случае 2-й пакет потеряется;
-если какой-то пакет будет сегментирован (например 2-й пакет в предыдущем пункте), то синхронизация на начало пакета не будет восстановлена никогда!

2.5.Как делу помочь? Идея devn-fd.so - заманчивая, задумана красиво, да реализована кривыми ручками. Попользовать его, чтоб посмотреть как оно работает - можно. Использовать в приложениях, тем более критических - ни в коем разе.

Тут затык принципиальный, он даже не в особенностях чтения /dev/ser (или /dev/par и т.д.), а в том, что это устройства потоковые байтовые (в отличии от Ethernet адаптера, который знает формат MAC-пакета и ориентирован на приём пакета). Эти устройства не могут определить границу пакета, а не зная длины пакета, программный обработчик MAC не может его выделить. Здесь нужно или дополнять MAC-заголовок длиной, или (альтернативно) - использовать разделитель-ограничитель пакетов в потоке (Скажете - там любой байт может быть в потоке, нечего использовать как разделитель? Не страшно - можно использовать технику экранирования, выделить для этого 2 символа - экран и разделитель - и предобрабатывать при передаче. Так, кстати, где-то на аппаратном MAC-уровне делают, не помню, чтоб не FDDI).

Я пока не вижу другого пути исправления ситуации, как взять и переписать. Если бы были исходники devn-fd.so - там работы на 2 дня. Никто не смотрел: в сорсах на исходном CD, или в Network DDK - нет???

А переделать нужно бы вот что:

- поменять формат заголовка MAC так, чтоб он обязательно содержал актуальную длину инкапсулированного в MAC пакета, а заодно, раз уж менять, привести его к соответствию одному из стандартов, применяемых в пром-интерфейсах;

- чтение переделать как-то так:

while( true ){
  читать заголовок MAC-пакета;
  if( MAC.dst != собственный MAc && MAC.dst != широковещание ) continue;
  int nPkgLen = <актуальная длина пакета>;
  установить тайм-аут приёма = передаче пакета такой длины;
  if( read( ,, nPkgLen ) <= 0 ) continue;
  обработать в зависимости от типа пакета;
}

Здесь read хоть тоже в каких-то случаях искажения пакета может его пропустить, так хоть синхронизация на начало пакета будет каждый раз восстанавливаться. Кстати, эта схема чтения в тосности соответствует схеме MsgReceive()-MsgRead(), везде применяемой и описываемой QSSL для чтения сообщений от микроядра, а здесь ... Но чтение сообщений в системе, наверное, эксперт писал, а devn-fd.so - студент...

P.S.Появилась тут ещё идея, это больше из задрочек, или кому быстро нужно результат получить: сделать перед /dev/ser промежуточное потоковое устройство (какой-нибудь /dev/sep), которое при отправке пакета допишет перед ним его длину, а при считывании - прочитает длину, сосчитает указанной длины пакет, и только после этого вернёт его по read(). Коротко и сердито, маленький такой ресурс менеджер, который знает только 2 операции: write() & read(). А devn-fd.so уже к нему монтировать. При этом фактически и произойдёт автоматом изменение MAC-формата в такой:
- 2 байта - длина пакета;
- 6 байт - адрес получателя;
- 6 байт - адрес источника;
... ну а дальше - всё как и было ...
В "плюсах" такого решения могло бы быть то, что этот драйвер /dev/sep мог бы без труда навешиваться на любой (по номеру) /dev/ser, /dev/par, да и на любую другую линию побайтовой потоковой передачи, например, на какую-то вашу совсем уж необычную самоделку (инфракрасную там линию передачи или ещё что).


[ Это Сообщение было отредактировано: Olej в 2002-07-29 13:28 ]
Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #16 : Июля 29, 2002, 04:25:00 pm »


1.2.pppd в QNX реализации (или это BSD или OSF реализация?),

AFAIK BSD - отпочковавшаяся от ранней OSF 2.3.5. В BSD все снесли в ядро для netgraph а в linux начали городить клиентскую часть ...

похоже, делает уплотнение или исключение избыточной информации из IP-пакета, я пока не берусь утверждать, мне много непонятно, но вот dump одного ICMP пакета, пересылаемого по "ping 20.0.0.2" по PPP:

vj по умолчанию включена, надо указать опцию -vj для отключения компрессии заголовков ...
Записан

DigiMind
Гость
« Ответ #17 : Июля 30, 2002, 06:01:00 pm »


И теперь, оглядываясь на сделанное, можно подвести некоторые промежуточные итоги.

Ну наконец-то! Мои поздравления .
Черт. Читал взахлеб, как хороший детектив .
И это огорчает... Почему вместо нормального пользования системой приходится заниматься банальным хаком? Эх..
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #18 : Июля 30, 2002, 08:16:00 pm »


DigiMind пишет:
И это огорчает... Почему вместо нормального пользования системой приходится заниматься банальным хаком? Эх..

Нет худа без добра!
Подумалось мне, что вот такая прослоечка между devn-fd.so & /dev/ser (читай: любое потоковое устройство) - это не так уж и худо, т.е. только и исключительно для /dev/ser - это чрезмерно и наворот, а вот для более широкого класса устройств - даже дополнительная функциональность. Попробую за выходные сделать...
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



Просмотр профиля
« Ответ #19 : Июля 31, 2002, 05:26:00 am »

Шаман!
Я до этого не дошел... Остановился где-то на [!ether] и даже не подумал, что дело может быть в этом.

Олег, огромная просьба: можешь оформить это в виде статьи или публикации в FAQ. Важность материала, я думаю, осознаешь сам
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #20 : Июля 31, 2002, 01:20:00 pm »


dmi пишет:
Олег, огромная просьба: можешь оформить это в виде статьи или публикации в FAQ. Важность материала, я думаю, осознаешь сам

Чуть позже: я хочу как-то довести это до ума (оно ведь "уже намазывается"), а потом уже всё разом...

А ещё мне вспомнилось сообщение dmi, кажется, что QSSL в приватной беседе "обещали посмотреть devn-fd.so, запустить через него qnet для убедительности, и показать..." - это не точно, но смысл я, кажется, не переврал. Ну как мне нравятся всё больше эти ... из QSSL. "Конкретные пацаны ... типа...": у них devn-fd.so принципиально в таком виде работать не может, ну ладно, они об этом могут и не знать, но то, что к реализации qnet FLEET bind over IP они ЕЩЁ НЕ ПРИСТУПАЛИ (см. где-то в форуме новость от dmi) - об этом они должны хотя бы догадываться???
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #21 : Августа 02, 2002, 02:20:00 pm »

Киньте в меня кто-то спецификацией ModBus или его URL ... для этих дел.
Записан
ed1k
QOR.Moderator
*****
Offline Offline

Сообщений: 739


Просмотр профиля WWW
« Ответ #22 : Августа 02, 2002, 04:49:00 pm »


Olej пишет:
Киньте в меня кто-то спецификацией ModBus или его URL ... для этих дел.


Нафига он тебе?
http://www.modicon.com/techpubs/toc7.html
Если есть вопросы по протоколу - спрашивай в аське/мыле. Комплетели офтопик в QNX форуме.

Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #23 : Августа 02, 2002, 09:13:00 pm »


ed1k пишет:
Нафига он тебе?
http://www.modicon.com/techpubs/toc7.html

Раз уже протокол devn-fd.so перекручивать - хотел посмотреть, нельзя ли его перекрутить приближённо к ModBus: они функционально для одного и того же (я же обещал там кому-то за выходные перекрутить, а выходные уже подошли...). Спасибо, посмотрел. В прямую - нельзя: devn-fd.so использует 6-ти байтные MAC-адреса, а ModBus - 1 байтовый адрес получателя (а адрес источника вообще не использует). Но одна там интересная фича обнаружилась: ModBus в RTU Message Frame моде (бинарной) для разделения пакетов (в чём и есть проблема devn-fd.so) использует не передачу длины тела пакета, и не байты разграничители, а: временную задержку (паузу в трафике) не менее 3.5 периодов передачи байта (требуют "не менее", а реально везде ставят 4 периода). Интересно... К тем, кто этим занимается и ковыряется: какие могут быть соображения?


Записан
lestat
QOR.Moderator
*****
Offline Offline

Сообщений: 985


I don't trust anything


Просмотр профиля WWW
« Ответ #24 : Августа 02, 2002, 09:23:00 pm »


Раз уже протокол devn-fd.so перекручивать - хотел посмотреть, нельзя ли его перекрутить приближённо к ModBus

Кстати на сколько я могу себе представить внутренности devn-fd - он очень простой, как показывает практика 70% кода драйвера аппаратно-зависимая, остальное - это оформление точек входов, callback'ов и т.п. мелочей. Остается совсем мало. QNX в плане общения между драйверами через точки входа в файловую систему вроде проще чем какая-нибудь из известных ОС. Остается только написать хороший обработчик последовательно порта и можно городить свой драйвер.
Записан

DigiMind
Гость
« Ответ #25 : Августа 04, 2002, 10:14:00 pm »


Интересно... К тем, кто этим занимается и ковыряется: какие могут быть соображения?

Все равно не понятно, зачем городить туда ModBus.
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #26 : Августа 05, 2002, 01:16:00 pm »


DigiMind пишет:
Все равно не понятно, зачем городить туда ModBus.

Формат пакетов MAC может быть любым, так? Если его всё равно перекраивать, то почему бы не перекроить под что-то специфицированное? Посмотрел - ни под что подобное ModBus выкроить формат пакетов MAC не годится. Всё, вопросов нет.

А по поводу соображений, что я спрашивал: есть 3 варианта выделить (ограничить, "огородить") пакет MAC-уровня в байтовом потоке /dev/ser:
1.включением поля явного спецификатора длины в пакет;
2.использование символа разграничителя (с экранированием) конца пакета;
3.исвользование гарантированной временной паузы в потоке (время передачи 4-х байт) для ограничения пакета - вот это я позаимствовал из ModBus (так что не зря время потерял).

По 1-му варианту пробное решение у меня почти готово, и в отладке. А вопрос, кому интересно, такой - как каждый из вариантов видится из соображений устойчивости к ошибкам, и, особенно - к потере синхронизации: сбою к определению места начала очередного MAC-пакета?
 
Записан
DigiMind
Гость
« Ответ #27 : Августа 05, 2002, 02:14:00 pm »


1.включением поля явного спецификатора длины в пакет;
2.использование символа разграничителя (с экранированием) конца пакета;
3.исвользование гарантированной временной паузы в потоке (время передачи 4-х байт) для ограничения пакета - вот это я позаимствовал из ModBus (так что не зря время потерял).

По 1-му варианту пробное решение у меня почти готово, и в отладке. А вопрос, кому интересно, такой - как каждый из вариантов видится из соображений устойчивости к ошибкам, и, особенно - к потере синхронизации: сбою к определению места начала очередного MAC-пакета?

Был бы специалистом в данной теме, обязательно высказался бы развернуто.
А так, только чайниковское имхо .
Могу сказать, что п.3 мне совсем не нравится.
На скорости 115200 время передачи символа составляет <100 мкс. Уж кому как не тебе знать тему измерения времени в QNX .
Опыт возни с ModBus'ом показал, что протоколы с синхронизацией по времени, мне не нравятся.
Записан
ed1k
QOR.Moderator
*****
Offline Offline

Сообщений: 739


Просмотр профиля WWW
« Ответ #28 : Августа 05, 2002, 08:37:00 pm »


DigiMind пишет:
 Olej пишет
...
3.исвользование гарантированной временной паузы в потоке (время передачи 4-х байт) для ограничения пакета - вот это я позаимствовал из ModBus (так что не зря время потерял).
...
Был бы специалистом в данной теме, обязательно высказался бы развернуто.
А так, только чайниковское имхо .
Могу сказать, что п.3 мне совсем не нравится.
На скорости 115200 время передачи символа составляет <100 мкс. Уж кому как не тебе знать тему измерения времени в QNX .
Опыт возни с ModBus'ом показал, что протоколы с синхронизацией по времени, мне не нравятся.

А мне выбирать не приходиться. В данный момент ковыряю (но на нашем железе, очень далеко от qnx и pc) следующее при приеме пакета:
1) запрещаю передачу на линию
2) приняв байт cntr=3 и передаю байт на той же скорости (но не в люнию, как понятно, я надеюсь)
3) в обработчике прерывания "передача SCI закончилась" смотрю флаг, если идет прием пакета:
cntr--;
if (cntr==0) {
         посылаю сообщение обработчику пакетов, что пакет принят;
          выход из обработчика;
  }
  else {
         посылаю байт-пустышку;
          выход из обработчика;
  }

иначе (то есть если передача пакета) - все как обычно и передача в линию разрешена, выгрузил буфер и будь здоров.
Работает, так как модбас запрос/ответный по природе - вначале приходит запрос от мастера, потом идет ответ от слэйва. И так как у нас дальше RS485 - направление передачи тоже моя забота. Удачи.
По синхронному интерфейсу мы все же толкаем длину пакета в заголовке - проще и надежней ИМО. Но модбас пакет оказывается внутри нашего пакета с фирменным лого



Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #29 : Августа 07, 2002, 04:35:00 pm »


я там выше писал:
P.S.Появилась тут ещё идея ... сделать перед /dev/ser промежуточное потоковое устройство (какой-нибудь /dev/sep), которое при отправке пакета допишет перед ним его длину, а при считывании - прочитает длину, сосчитает указанной длины пакет, и только после этого вернёт его по read().

Занялся я сейчас этим делом, почти готово, сделаю - покажу. Спасибо 2-м предыдущим корреспондентам за советы - если не прямо, то косвеноо они подсказали любопытные соображения.

Но пока я ковыряюсь с devn-fd.so, тут попутно вылезли такие соображения, которыми я счёл нужным тут-же поделиться. Итак:

1.Как только заработает "примочка" к /dev/ser (или, точнее, к devn-fd.so - сама примочка, т.е. маленький ресурс менеджер /dev/sip - он уже примонтируется к devn-fd.so, но ещё не вылизаны вопросы тестирования и анализа передаваемых пакетов) - то, подумалось: ничего не видно, что препятствовало бы запуску qnet поверх канала devn-fd.so через /dev/ser, ведь это канал не только IP, но и MAC уровня. Что никак нельзя сделать с PPP, который тунель только IP, и до тех пор, пока QSSL не сделает bind=ip (или кто из нас быстрее сделает?) - это невозможно.

Что это даёт:
- возможность "поковыряться" с qnet тем, у кого нет сетевого оборудования вообще (автономные, домашние компьютеры...) - организуя связь между /dev/ser1 & /dev/ser2 (см.ниже);
- изучить такие свойства qnet, о которых так сладко поют QSSL, как: устойчивость, перераспределение трафика, восстановление соединения... без использования специального макета и обрудования (2 Ethernet карты). Достаточно соединить 2 компа по 2-м сериальным линиям: /dev/ser1-/dev/ser1 & /dev/ser1-/dev/ser1 и всё ... поехали, можно получить тестовые результаты;

2.В развитие соображения использовать локальный компьютер для сетевой отладки (или написания и отладки сетевых приложений без живой сети), подумалось: а чего бы не попользовать для этого и PPP (кроме FLEET, конечно - только IP). Сделал. Очень коротко, кому интересно - можете повторить:

2.1.Для начала, приведу общеизвестную распайку 3-х проводного нуль-модемного кабеля (бывают ещё 5-ти и 7-ми), чтоб не искать:
DB9 - DB9
2   -  3
3   -  2
5   -  5
(для DB25 "5" заменяем на "7").
2.2.Соединили проверили:
#cp XXX /dev/ser1
#cat /dev/ser2
2.3.Проверим скорость:
#stty 115200 < /dev/ser1
#stty 115200 < /dev/ser2
делаем достаточно длинный файл XXX, можете воспользоваться для любого (лучше символьного) файла:
#cat XXX >> XXX
^C
- только "вовремя" давите ^C - файл растёт экспоненциально . Дальше:
#time cp XXX /dev/ser1
#cat /dev/ser2
У меня для файла 15156 байт время (общее, как видно будет дальше - может это и неправильно: нужно юзеровское брать, см. ниже) - 1.270 сек. - т.е. вот вам и сетка на ~13Kb/s - для отладки вполне годится.
2.4.Строим серверный (это очень условно) интерфейс ppp0:
#pppd /dev/ser1 passive 19.0.0.1:0.0.0.0 netmask 255.255.255.0 updetach
2.5.Строим 2 клиентских интерфейса ppp1, ppp2:
#pppd /dev/ser2 19.0.0.2:19.0.0.1 netmask 255.255.255.0 updetach
#pppd /dev/ser2 19.0.0.3:19.0.0.1 netmask 255.255.255.0 updetach
2.6.
#ifconfig -a
..............
#ping 19.0.0.1
#ping 19.0.0.2
#ping 19.0.0.3
..............
2.7.А таперь на них - telnet:
#inetd
#telnet 19.0.0.2
.....
#mqc
..... вот вам "медленный" старт ...
2.8.Вот
#time cat XXX
- меня озадачивает - времена меньше, чем по direct connect ...?


[ Это Сообщение было отредактировано: Olej в 2002-08-07 15:04 ]
Записан
Страниц: 1 [2] 3 4 5
  Печать  
 
Перейти в: