Страниц: 1 2 [3] 4 5
  Печать  
Автор Тема: TCP/IP over /dev/ser*  (Прочитано 38378 раз)
DigiMind
Гость
« Ответ #30 : Августа 07, 2002, 06:28:00 pm »


2.8.Вот
#time cat XXX
- меня озадачивает - времена меньше, чем по direct connect ...?

Эээ.. Компрессия?
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



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


DigiMind пишет:
Эээ.. Компрессия?

Может быть, отчасти, но я сильно грешу на то, что в выводе time нужно "значащим" считать не "real"-время, а "user". Хотя там тоже проблемы: если на низких уровнях "переть поток в порт" - там все времена будут юзеровские, то когда включается в работу целая цепочка драйверов (ресурс менеджеров) - там большая часть может отвалиться в "system"...
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



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

Сделал я таки ресурс менеджер /dev/sip - который цепляется к /dev/ser, и превращает потоковую байтовую передачу в пакетную. Т.е. например, можно:
#cp xxx /dev/sip1     ;на 1-м компе
#cat /dev/sip1 > xxx  ;на 2-м компе
... всё ОК, кроме того они мне "помогают" - сообщают: "read request - 4096 bytes" и т.д.

Цепляю теперь уже этот драйвер к devn-fd.so:
#mount -Tio-net -ofd=/dev/sip1,mac=006000000004 devn.fd.so
#ifconfig en1 20.0.0.2/24
#arp -s 20.0.0.1 00:60:00:00:00:02
... на обоих компах, естественно, на 2-м что-то похожее, даже arp принудительно прописал, чтоб всё начало "играть" с IP не посылая ARP..., ну и, конечно, всё необходимое для tcpdump делаю.

О бля-я-я-я...

После монтирование: "read request - 1498 bytes" (размер,может, я чуть-чуть и переврал - по памяти пишу - но запрашивается IP пакет со станд. MTU...) всё ОК. Но после ping tcpdump видит отправляемые пакеты ..., а драйвер /dev/sip по запросам write() - не видит ничего ... молчит как партизан в гестапо!

Возник вопрос: так какой ещё операцией кроме write() они из devn-fd.so могут "проталкивать" данные в примонтированный "файловый дескриптор" (так они сами называют)... devctl()? Зачем?

Я его гада добью - бо достал, но может у кого какие конструктивные догадки появятся?
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



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


Olej пишет:
выходные перекрутить, а выходные уже подошли...). Спасибо, посмотрел. В прямую - нельзя: devn-fd.so использует 6-ти байтные MAC-адреса, а ModBus - 1 байтовый адрес получателя (а адрес источника вообще не использует).

Что-то я совсем ничего не понял ? Что во что ты хочешь завернуть и чем это намазать ? При чем тогда devn-fd ? modbus rtu/ascii использует чистую физику серийного шнурка, без TCP и т.д. Modbus TCP - это уже из другой сказки...


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


На практике делается select() при чтении. Не знаю, из чего расчитывается таймаут, но для 57600 он равен 8333 us. (из моих расчетов получается, что ~7000 вполне достаточно - теоретически).
По срабатыванию select() считается, что пакет пришел и проверяется его CRC.

У меня ни разу не было ситуации, когда я бы отправлял пакеты чаще, чем 5-15 раз в секунду. Так уж ли это критично ?

А вообще, если не хочется (или специфика не позволяет) мучаться с таймаутами, то можно использовать MODBUS ASCII.
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



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


Olej пишет:

После монтирование: "read request - 1498 bytes" (размер,может, я чуть-чуть и переврал - по памяти пишу - но запрашивается IP пакет со станд. MTU...) всё ОК. Но после ping tcpdump видит отправляемые пакеты ..., а драйвер /dev/sip по запросам write() - не видит ничего ... молчит как партизан в гестапо!

Возник вопрос: так какой ещё операцией кроме write() они из devn-fd.so могут "проталкивать" данные в примонтированный "файловый дескриптор" (так они сами называют)... devctl()? Зачем?

Я его гада добью - бо достал, но может у кого какие конструктивные догадки появятся?


1492 наверно. А не пишет, потому как не может сделать devctl() на /dev/sip - установка четности/длины байта и т.д.-tcgetattr() &tcsetattr().Могу поковырять его, сказать, что оно вызывает.

По идее можно просто сделать один обработчик, который на все значения будет отвечать 0 (т.е. EOK), а не ENOTSUP  (возвращается по умолчанию).
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



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


Olej пишет:
#cat XXX >> XXX


Я аж икнул
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



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


dmi пишет:

Olej пишет:
#cat XXX >> XXX

Я аж икнул

Понравилось? Хорошая команда ... если зазевать, то быстро заполняет любой винчестер ... под крышку

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

Сообщений: 42



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


dmi пишет:
1492 наверно. А не пишет, потому как не может сделать devctl() на /dev/sip - установка четности/длины байта и т.д.-tcgetattr() &tcsetattr().Могу поковырять его, сказать, что оно вызывает.

По идее можно просто сделать один обработчик, который на все значения будет отвечать 0 (т.е. EOK), а не ENOTSUP  (возвращается по умолчанию).

1492 - да, наверное. По поводу того, что это devctl() установочный - хорошая мысль, свежая. Но он ведь и передавать данные (записывать) потом может по devctl()?
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



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


Olej пишет:

dmi пишет:
1492 наверно. А не пишет, потому как не может сделать devctl() на /dev/sip - установка четности/длины байта и т.д.-tcgetattr() &tcsetattr().Могу поковырять его, сказать, что оно вызывает.

По идее можно просто сделать один обработчик, который на все значения будет отвечать 0 (т.е. EOK), а не ENOTSUP  (возвращается по умолчанию).

1492 - да, наверное. По поводу того, что это devctl() установочный - хорошая мысль, свежая. Но он ведь и передавать данные (записывать) потом может по devctl()?


devctl() генерит PulseMsg(), т.е. несет 4 байта информации. Думаю, лучше писать через write...
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



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


dmi пишет:
devctl() генерит PulseMsg(), т.е. несет 4 байта информации. Думаю, лучше писать через write...

Тут у меня же затык не в том "как лучще", а в том, как (каким вызовом) devn-fd.so передаёт данные примонтированному к нему последовательному устройству (было /sev/ser, потом /dev/sop, но это может быть и заурядный файловый дескриптор). По write( fd, ...) - он этого, гад, не делает (чем им write не угодил) ... , а как?

[ Это Сообщение было отредактировано: Olej в 2002-08-13 13:03 ]
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



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


Olej пишет:

dmi пишет:
devctl() генерит PulseMsg(), т.е. несет 4 байта информации. Думаю, лучше писать через write...

Тут у меня же затык не в том "как лучще", а в том, как (каким вызовом) devn-fd.so передаёт данные примонтированному к нему последовательному устройству (было /sev/ser, потом /dev/sop, но это может быть и заурядный файловый дескриптор). По write( fd, ...) - он этого, гад, не делает (чем им write не угодил) ... , а как?


У меня есть подозрение, что сначала он пытается сделать devctl() на этот fd, который завершается аварийно ( a.e. tcsetattr() failed ). Так что надо писать обработчики _этих_ devctl().
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



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


Olej пишет:

dmi пишет:
devctl() генерит PulseMsg(), т.е. несет 4 байта информации. Думаю, лучше писать через write...

Тут у меня же затык не в том "как лучще", а в том, как (каким вызовом) devn-fd.so передаёт данные примонтированному к нему последовательному устройству (было /sev/ser, потом /dev/sop, но это может быть и заурядный файловый дескриптор). По write( fd, ...) - он этого, гад, не делает (чем им write не угодил) ... , а как?


У меня есть подозрение, что сначала он пытается сделать devctl() на этот fd, который завершается аварийно ( a.e. tcsetattr() failed ). И до write() конечно же не доходит (зачем писать, если порт отключен ?). Так что надо писать обработчики _этих_ devctl().
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



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


dmi пишет:
У меня есть подозрение, что сначала он пытается сделать devctl() на этот fd, который завершается аварийно ( a.e. tcsetattr() failed ). И до write() конечно же не доходит (зачем писать, если порт отключен ?). Так что надо писать обработчики _этих_ devctl().

Это правильное соображение, и я его проверю, только какого он хрена делает devctl() на этот, в общем случае - файловый дескриптор? Что он от него хочет. Ведь про порт, про /dev/ser - это мы придумали возиться, а у них, в общем виде, там может быть что угодно: файл, /dev/par, наконец какие-то собственные "шнурки"...
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



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

Чего я ещё вцепился "как блоха в собачью шерсть" в devn-fd.so, а точнее в связку io-net - devn-fd.so - /dev/sip - /dev/ser, так это то, что "продолбив" ЭТО я смогу с помощью devn-fd.so гнать TCP/IP через любую среду передачи, через любые "шнурки", самопальные или стандартизированные, например:
- USB кабель "комп-комп" - есть такие, стоимостью "от производителя" около $10 - там микросхема хаба "в кабле", т.е. это и не совсем кабель, а там - до 12 Мбит/сек.
- LPT кабель, мы по нему в режиме EPP гнали 650 Кбайт/сек - в некоторых, именно встраиваемых, приложениях это может быть любопытно;
- наконец, больше всего меня интересует fireware: IEEE-1394A - 400Mbit/sec & IEEE-1394B - 3.2Hbit/sec - но по нему ничего нет (т.е. есть полно - путнего описания нет), сам IEEE-1394A - к нему не доберёшься - сам IEEE его рассылает около ~$100. Может кто видел?  
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



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

Стал переписывать ресурс менеджера /dev/sip так, чтоб он поддерживал devctl() - ну, хотя бы, для начала, чтоб я мог видеть эти вызовы:
....
Could not find library libbfd-2.10.1.so
... ну ни фига себе - где он ещё это взял?
Записан
Страниц: 1 2 [3] 4 5
  Печать  
 
Перейти в: