Общение на транспортном уровне TCP
 

Общение на транспортном уровне TCP. Возможно ли научить Flash/AIR приложение такому общению? Гугл не помог. Может есть ссылки на библиотеки или чтиво какое?

MOHCTEP, сообщение должно раскрывать вопрос полностью, без отсылок к заголовку.

alatar мерси)))
mooncar Вы правы. Постараюсь исправиться.
Есть кучка железок: контроллеры, счетчики, концентраторы и т.п., доступных по локалке, которые необходимо опрашивать/настраивать. Собственно это и является целью разработки.
Некоторые девайсы весьма "разумны" имеют ось и возможность общения по ftp, т.е. на уровне приложения. С ними проблем нет и ссылка, любезно предоставленная alatar, тут пришлась очень даже кстати. С другими же встала проблема, которую я не смог решить нативными средствами.
Повторюсь: здесь имеет место быть транспортный уровень модели OSI. Сокетом соединение устанавливается, однако обмен данными не получается.
Одна из причин, мне думается, это необходимость битовой синхронизации пакетов, для которой AS3, видимо, слишком "высокоуровневый".
Собственно интересует, возможно ли в принципе решить задачу. Может есть способы с какими-то посторонними библиотеками?

В этом-то и проблема. По описанию IEC 62056... и подобных стандартов нужно послать определенную байтовую последовательность со скоростью = 300 бод, со всякими оговоренными длительностями, задержками, битами четности и прочей требухой.
Сформировать нужный пакет в ByteArray несложно. Несложно и отправить его стандартными средствами сокета. Но это не решает проблему, т.к. ответа естественно не получаю.

Как я понимаю, сокет - это совсем не транспортный уровень, а прикладной.
Тут я имею в виду информацию, которую пишем в сокет. Другую не можем.
На инкапсуляцию транспортного уровня из AS напрямую повлиять возможности нет.
Но сформировать любой протокол прикладного уровня - это пожалуйста.

Для таких задач возможно одним as3 не обойтись, т.к. действительно у среды flash свой формат данных AMF и спецификация.
Существует оболочка Zinc, возможно это то, что вам нужно. В данной среде api существуют собственные методы для работы с tcp. Либо используя низкоуровневый язык C, владея таковыми навыками конечно, пишутся и подключаются к приложению внешние библиотеки dll, адаптируя интерфейс к нужной спецификации.

Очень похоже. На столь низком уровне, так и не удалось ничего путного добиться.

qweXСпасибо! Про цинк совсем забыл, а в СИ, к моему стыду, я совсем чайник.

Socket AS3 это именно транспортный уровень модели OSI. В этом можете не сомневаться.
Про AMF было вобще не в тему упомянуто т.к. Socket на уровень ниже AMF. На сокете теоретически можно построить свой формат передачи данных, в том числе и AMF.
ПС: про задержки очень интересно. Как вы их реализовывали при отправке данных?

Пропустил это сообщение. Все верно, но на инкапсуляцию вроде и не надо влиять?

Зачем Zink? Если речь идет о настольном приложении (а начиная с AIR 3.8 и о мобильном), можно взять UDP Socket и играться сколько душе угодно.

Ну, а на деле? Суем в сокет байт-дату, при этом не паримся ни о размере, ни о содержании, ни об очередности пакетов. ФТП обмен, со всеми авторизациями, сокетами обслуживается - на ура (а это ведь прикладной уровень). А вот телеграф именно транспортного уровня, с его морзянкой - засада.
Да никак. :) попытки решения "в лоб" оказались предсказуемо провальными. Таймер "отлетел" сразу, как вариант, из-за его дичайшей неточности и зависимости от частоты кадров проекта. Попытка "добрать" битами нужные длительности тоже не удалась.

alatar
Дак те-же грабли, только в профиль...

Вы случаем не путаете TCP с каким-нибудь другим простоколом не путаете? Где вы видели реализацию TCP-сокета в которой надо следить за очередностью и размером пакетов?

Добавлено через 2 минуты
Вы бы привели ссылку на спецификации того, что вы пытаетесь реализовать, было бы проще вам помочь.

Добавлено через 1 час 4 минуты
IEC 62056 и подобные описывают протоколы канального уровня, а не транспортного.

Не видел нигде, оттого и спрашиваю.))
IEC61107 один из стандартов, близкий к используемым.

Вас не насторожило, что стандарт описывает, в том числе, физический уровень, а вы пытаетесь взаимодействовать на транспортном? Ищите ane для работы с COM портами, возможно удастся подключиться через него. Или придется паять свой сервер, как промежуточное звено.

Не особо. Железки имеют возможность связи по RS485 и, как я уже указывал выше, организованы в сетку. Исполнитель, собравший эту систему, объяснил, что доступ и обмен возможен на транспортном уровне протокола TCP. Вобщем, за что купил, за то и продаю...)
Я дилетант в серверном программировании и, если ошибаюсь, так прошу: подскажите, возможно ли собрать подходящего клиента и куда копать?

Ну так это вам с исполнителем и надо обсудить. Нам же не известно как и к чему они подключены.

Мне тоже - неизвестно.))) Фрилансеру, по понятным причинам, много чего неизвестно...
С другой стороны, мне, как клиенту, по идее, и должно быть абсолютно параллельно: чего, куда и как подключено. Вас ведь, к примеру, не интересует маршрут пакетов, когда вы читаете эту запись?

MOHCTEP, часом не про TFTP речь?

MOHCTEP, вы разницу между RS485 и ethernet понимаете?
Вот у этого исполнителя и спросите, как к этим девайсам можно подключиться по TCP. Ваши датчики подключены по RS485 к какому-то серверу и показания с них вы можете считывать (если можете) через него.

alexcon314,
Спасибо! Пока не знаю, постараюсь уточнить.

Добавлено через 25 минут
alatar,
понимаю, но очень "теоретически". Видите ли, нет у меня прямого доступа ни к железу, ни к этому провайдеру. Все, что есть, это список из более сотни локальных IP, каким-то образом "привязанных" к устройствам. Почти с половиной списка мне удалось "договориться". А вот как работает остаток - непонятно, но он работает. Заказчик видит эти железки кучкой разного спец-софта. Саппорт изготовителя или молчит или хочет очень приличных денег. Моя задача, написать AIR программу, способную мониторить и управлять всем списком железок, по возможности.
Осталось узнать, есть ли эта самая возможность? :)

Производители железок (у которых нет возможности общаться по TCP) вам не помогут, да вас и не должно интересовать (кроме как для общего развития) как они работают на низком уровне. Вам необходимо выяснить, каким образом вы можете с ними общаться через тот девайс к которому они подключены и который осуществляет связь датчиков с внешним миром. Вам необходимо это выяснить с заказчиком или с тем, кто этот девайс (сервер) там ставил.

Вот и стартовал новый виток спирали "эволюции".))
alatar, Прошлое общение с персоналом аккурат и вывело на этот самый транспортный уровень... Теперь у меня появился повод к сомнению в непокоБеЛимости :) этого факта. Но, ведь и на прикладной уровень TCP IP непохоже, коль ничего не получается.
Нет ли у вас версий, какие протоколы тут могут быть задействованы теоретически?

Использование TCP ничего не говорит о взаимодействии с получателем, он просто предоставляет вам "трубу" в которую вы можете "кричать" и "трубу" из которой вы можете слушать. Вам необходимо знать какой протокол прикладного уровня используется для общения с датчиком (http, ftp, tftp, собственный протокол...).

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

Понятно. Спасибо всем! Буду заказчика пытать...))