Для стирания рекомендую лампочки с али: искать по "E17 UV bulb". Выглядят как обычная лампа накаливания с 2 перекрещенными спиралями внутри. Сначала накаляются спиральки, потом между ними загорается разряд. Ту ПЗУшку, которую я пробовал ими стирать, они тёрли за 5 минут, будучи приложенными вплотную к окошку.
Но есть и особенности:
Такие лампы требуют кормить их определённым (300 ма) стабилизированным током. Можно от лаб. БП, можно от LM317 по схеме стабилизации тока, можно из розетки через гасящий кондёр или дроссель. При этом вначале (спиральки нагреваются) напряжение на них около 15-16 вольт, а потом (заряд загорелся) падает до ~12 вольт.
Эти лампочки ОЧЕНЬ сильно пахнут озоном (а как известно, если озоном пахнет, то его ПДК уже превышено), так что использовать их в жилых помещениях не очень.
Под ними не стоит загорать, т.к. они светят довольно коротковолновым УФ.
Да это ни от кого не скрывалось, процесс планирования был довольно публичным. Первые наброски делались вообще на собрании в переговорной с выводом на проектор, потом по мере развития проекта актуальные версии рассылались. Просто директор изначально хотел опенспейс — дескать, от сидения рядом проистекает синергия и повышаются открытость и вовлечённость. А я, как единственный айтишник, сказал, что у меня с менеджерами по продажам, логистиками и маркетологами синергии быть не может, что мы друг другу будем только мешать, и что в районе моего рабочего места всегда царит некоторый беспорядок из разобранных ноутбуков и клубков кабелей, которыми лучше не смущать пришедших на переговоры клиентов.
Но теперь, конечно, некоторые косятся с завистью.
Статья, конечно, старая, но только сейчас увидел. Пару лет назад наша контора переезжала в новый офис в довольно сжатом режиме, и как-то внезапно получилось так, что его план рисовал я, в Visio. В результате отдельные кабинеты с непрозрачными стенами есть у бухгалтерии и у меня. У генерального и технического директоров — отдельные кабинеты, но со стенами из прозрачных стеклянных перегородок. Остальные сидят в опенспейсе.
Как уже выше написали — там применяется Фазированная Антенна Решетка.
Количество отдельных элементов в наземном терминале может быть примерно 200+, сам же терминал (а по сути диаметр этой решетки) будет размером с коробку из под пиццы (как его описал сам Маск).
Весь их конструктив — антенные элементы + усилители + фазовращатели будут объединены в такой «бутерброд». Усилители и фазовращатели будут реализованы с помощью кастомных чипов. Интересно, что для приема и для передачи будут использоваться разные антенны, расположенные рядом в этом массиве.
Сами терминалы будут работать исключительно со спутниками находящимися выше 40 градусов над горизонтом. Это из-за того, что форма луча уже получается не такой оптимальной, если коммуницировать с низкими спутниками. Каждый отдельный спутник поддерживает лишь определенное небольшое количество клиентов, формируя для каждого отдельный луч. Ставка тут действительно делается на большое количество спутников и коммуникацию между самими спутниками, так что для клиентов будет получаться своего рода бесшовный «роуминг». Так же применяется круговая поляризация сигнала, так что проблем с ориентацией спутника нет. В такой схеме клиент всегда будет на связи с несколькими спутниками точно.
Связь с клиентскими терминалами происходит в Ku диапазоне, диапазон частот: 10.7 ГГц — 12.7 ГГц. Отличие downlink и uplink только в поляризации. Канал спутник-клиент работает с Правой круговой, а клиент-спутник — с Левой круговой.
С наземными станциями приземления трафика связь ведется в диапазоне 17.8 ГГц 0 19.3 ГГц, это уже Ka диапазон.
Есть еще канал телеметрии на 12.15 ГГц — 12.25 ГГц.
Спутников в небе сейчас действительно уже очень много лично я для отслеживания применяю связку сайтов heavens-above.com и n2yo.com (для получения орбитальных элементов) и программы GPredict, которая очень удобно отображает то что сейчас пролетает и в какую сторону + позволяет прогнозировать будущие проходы. См. скриншот в спойлере.
Я вот уже определенное (небольшое) время пытаюсь поймать хоть какие-то сигналы от этих спутников, возможно ту же телеметрию. Использую вполне бытовое оборудование Ku диапазона + самодельный контроллер LNB + HackRF SDR. Понимаю, что шансы тут стремяться к нулю, но повозиться с этим весьма интересно. Своего рода технический вызов :)
Понятное дело, что моя антенна это не ФАР и она может смотреть только в одну точку, а моторизированный трекер я пока не сделал. Расчет на то, что в поле зрения антенны обязательно попадает хотя бы несколько спутников. Я её предварительно навожу в точку траектории пролета.
Пока разумеется ничего поймать не удалось. Возможно просто не попадаю антенной куда нужно, возможно не хватает чувствительности приемника. А возможно спутники просто ничего не передают.
Теоретически они могут излучать сигналы маяков (beacons) что бы наземные станции могли их найти и начать процедуру подключения. Но делать они должны это на всех лучах во все возможные стороны. Это не сильно эффективно + может вызвать интерференцию. Так что возможно спутники ждут сигнала от наземной станции, что бы потом работать прицельно с ней. В общем этот момент не очень ясен.
В связи с этим делаю ставку на канал телеметрии, спутники должны активно передавать данные, особенно когда они еще едут цепочкой, после вывода.
Детально уже не вспомню — 15+ лет прошло. От Х&Х, Кофлина, Достала,… В основном по фотонике и ОУ (минимизация шумов, сопряжение полюсов ЛАЧХ каскадов для идеализации g(t) и т.д.). Бумажные остались в другом городе, их и в электроном виде уже 10+ Gb. For example:
Абрамов Схемотехника устройств на операционных усилителях 2008.pdf
Алексеев АГ Операционные усилители и их применение.djvu
Брюс Картер Операционные усилители для всех (Схемотехника) 2011.djvu
Грем Дж Проектирование и применение операционных усилителей.djvu
Достал И Операционные усилители.djvu
Кофлин Р Операционные усилители и линейные интегральные схемы.djvu
Ленк Дж Руководство для пользователей операционных усилителей .djvu
Марше Ж.Операционные усилители и их применение.1974.djvu
Пейтон Аналоговая электроника на ОУ 1994.djvu
Фолькенберри Л Применения операционных усилителей и линейных ИС.djvu
Щербаков ВИ Электронные схемы на операционных усилителях.djvu
Полный каталог генерить некода, да, и не стоит ним флудить этот тред. Могу, конечно, выложить библиотеку под доступ (в DirectConnect, например), но, на это тоже надо время.
У меня есть HTC Vive Pro и беспроводной адаптер к нему. Расскажу как есть.
По проводу всё шикарно, изображение забирается прямо с DisplayPort видеокарты. Проблем с динамичными сценами нет, но мешается сам провод. Правда, для игр которые только для сидения или стояния (например Moss или тот же Laser Saber) провод не сильно мешает, а вот в Alyx уже конкретно мешает, поэтому и покупал.
Беспроводной адаптер состоит из двух блоков: PCIe карточка WiGig от Intel (можете погуглить, у них там специальная серия под VR с малой задержкой) и приёмником на шлем. Играть удобно в динамичные игры, требующие постоянного движения.
Но вот есть один нюанс. Я до покупки думал, что адаптер будет брать видео коротким шнурком из видеокарты, а PCIe использовать только для управления, оказалось это не так. Адаптер обычный, видео с видеокарты берётся не с порта а через системную шину. При этом, штатный адаптер для проводного подключения не требуется вообще (но необходим для установления BT соединения с базами для обновления прошивки).
Таким образом, изображение грабится из буфера тем же методом, что и ShadowPlay, переносится по PCIe с видеокарты в ОЗУ, оттуда программа его пихает в карту. Как результат: если динамики нет то изображение отличное, если есть динамика, то изображение может иметь артефакты «желе», как у MPEG на движущихся объектах, только без кубиков. Особенно это заметно, если игра на обычном HDD, перенос на SSD решил проблему, я не знаю почему так — мешает контроллер HDD на PCIe хабе?
Ну и на закуску проседания сигнала. Я закрепил антенну достаточно высоко, однако они там используют какие-то бешеные частоты (mmWave 60GHz band), поэтому, если смотреть резко вверх или вниз «рожки» перекрываются головой и появляются уже обычные для низкого битрейта артефакты: банальные кубики. Иногда доходило до того, что даже звук начинал икать или шлем обрывал связь (голубой экран внутри) и несколько секунд перегружался. Некоторые игры это не любят и крашатся, что означает прерывание сессии игры на ручную перезагрузку SteamVR. Но большинство игр реагирует адекватно и ожидают готовности шлема.
В последнее время возникали проблемы при использовании материнских плат для AMD AM4/TR4 с беспроводным адаптером VIVE. Вместе с партнерами мы работаем над скорейшим решением данной проблемы. Если у вас установлена материнская плата для AMD AM4/TR4, мы рекомендуем повременить с покупкой беспроводного адаптера VIVE пока не решен вопрос совместимости. Пожалуйста, следите за новостями на сайте.
Мой итог: беспроводной адаптер это действительно круто. Мечтал о VR с самого первого просмотра фильма «Газонокосильщик» в 90х. Когда появился VR клуб в городе — стал постоянным членом. Когда вышла Half Life Alyx целенаправленно купил себе домой с беспроводным адаптером. И после клуба играть без проводов действительно удобно. Но он имеет определённые требования к производительности компьютера. Да и артефакты иногда появляются.
На самом деле — все это появилось с версии 8.3.14 или 8.3.15, до этой версии — нельзя было открыть мобильную конфу просто так, но с тех версий — 1с решила, что разворачивать базы долго на устройстве и лучше кидать шаблон, и таким образом — им надо было базу формировать в стационарной.
Про это проблему знают, и ей уже минимум год, и знают про нее все, кто так или иначе занимается мобильной разработкой.
Все что вы видите — это да, по моему мнению — вина 1С, так как изначально декларировалось, что исходники прочитать нельзя, и так оно и было, а потом 1с переобулись в кувырке, и стало можно, а механизма — как защитить модули, или хотябы константы — нет.
Таким образом у людей был выбор, или прекратить разработку, или рассчитывать на то, что любой может получить доступ к данным.
Люди выбрали второе, в ожидании, пока 1с решит проблему с первым.
Более крупные компании — пишут все нужные вещи в компонентах, чтобы уж точно не прочитали те, кому не надо, но такое могут позволить далеко не все.
С другой стороны, то что можно открыть конфу на компе с данными — позволяет восстановить базу, если она рухнула, или провести тестирование и разработку на реальных данных.
А с учетом того, что 1с платофрма — это система с открытыми исходными кодами (я про конфигурации), то все как то привыкли к этому всему.
Я, в первых релизах — первый просил людей удалять такие статьи, так как это был явный нежданчик для разрабов, но уже прошел год… И если воз и ныне там… То я уже даже не знаю :)
Описание слишком краткое чтобы понять в чем проблема.
С многопоточностью и межпоточной коммуникацией работал много. Как под Win раньше, так и под AS/400 сейчас.
Непонятно в чем сложность
реализация механизма передачи файла на основе первого варианта сервера (Multithreaded Pipe Server) оказывается слишком сложной.
Наиболее простой на мой взгляд подход. Правда, скажу сразу — с пайпами не работал — немного пробовал, не понравилось (под мои задачи). Под Win использовал MailSlots и сокеты (как TCP, так и UDP). Под AS/400 богаче выбор — UnixSockets, socketpair, DataQueue, UserQueue.
Наиболее простым оказалась синхронная реализация в отдельном потоке. Под Win задача была такая — с одной стороны N (около 30-ти плюс-минус) удаленных контроллеров, которые шлют некоторую информацию по UDP протоколу. С другой — M (3-5 обычно) интерфейсных клиентов, которые с этой информацией работают. Поток данных двунаправленный. Информация от контроллера должна быть некоторым образом обработана и на основе определенных признаков отдана одному или нескольким клиентам. Информация от клиента анализируется и передается (на основе анализа) на один из контроллеров.
Все это работает в режиме 24/7. Т.е. постоянно, годами.
Было три потока:
— поток контроллеров с открытым UDP портом в который все контроллеры послылают информацию
— поток клиентов в котором работал TCP сервер и был набор TCP соединений для уже подключившихся клиентов
— поток обработки и маршрутизации
Каждый из потоков создавал свой именованный MailSlot для приема входящей информации. Это оказалось проще чем обмен через память с синхронизацией. Любой поток мог послать данные любому потоку просто записав их в его MailSlot.
На AS-ке задачи другие. Там распараллеливание обработки между задачами (поток не используем т.к. у сопровождения сложности с их мониторингом). Там классическая Batch машина. Одна задача берет данные и подготавливает задания на обработку и несколько обработчиков, которые эти данные параллельно обрабатывают и отдают результат.
Коммуникация была комплексная. Для раздачи заданий использовалась UserQueue — очередь данных. Хороша тем, что в нее кто угодно может писать и кто угодно читать. Она не привязана к конкретному процессу. Головная задача выкладывала туда задания, а обработчики их оттуда разбирали по мере освобождения (выполнил текущее задание — отдал результат — взял из очереди следующее).
Для результатов головная задача держала открытый UnixSocket (DGRAM — он не требует постоянного соединения). Туда обработчики скидывали результаты обработки.
На kroks.ru к примеру. У меня пока только пару месяцев работает Kroks Rt-Pot sH. Единственное я не смог настроить ограничения скорости отдельно для каждого клиента(пишут что нужно установить пакет, но у меня он не находит такие, либо находит, но они работают/настраиваются только через командную строку).
OSMand — это единственный профессиональный навигатор на андроиде. Вместо трёх кнопок "домой" "в магазин" и "туды" (90% всех остальных навигаторов дают только эту фичу), это инструмент, с помощью которого можно решать разные задачи, т.е. инструмент универсальный.
Начиная с "записать по дороге трек, а потом повести по этому треку назад в режиме навигатора" и заканчивая многоточечной маршрутизацией. Пешие маршруты, сложные ситуации,etc.
Огромный респект. (обычный пользователь обычного платного osm'а без real-time update).
oldpc.su/lib/gsp/red89.pdf УСТРОЙСТВО ВВОДА ГРАФИЧЕСКОЙ ИНФОРМАЦИИ ПОЛУАВТОМАТИЧЕСКОЕ ТИПА СМП 6410
Предназначено для организации диалога оператора с ЭВМ и преобразования графической информации в цифровую форму. Устройство осуществляет ввод в ЭВМ координат точек чертежей, схем, эскизов, а также координат поля дополнительной информации.
Размеры поля: кодируемого чертежа 420ХХ130 мм; поля дополнительной информации 420ХХ120 мм. Разрешающая способность 0,1 мм. По-грешность считывания координат не более ±0,5 мм.Толщина носителя графической информации 1,0 мм.Тип носителя графической информации — диэлектрик. Режим вывода графической информации по-точечный и непрерывный. Дискретность вывода информации, задаваемая оператором, 0,1; 0,4; 0,8; 1,6;3,2 мм. Скорость считывания координат в непрерывном режиме 100 точек/с. Питание — от сети переменного тока: напряжение 220 В, частота 50 Гц.Потребляемая мощность 120 В-А. Габаритные раз-меры: планшета 600x550X140 мм, блока питания 170X260X220 мм. Масса соответственно 8 и 6 кг.
Для стирания рекомендую лампочки с али: искать по "E17 UV bulb". Выглядят как обычная лампа накаливания с 2 перекрещенными спиралями внутри. Сначала накаляются спиральки, потом между ними загорается разряд. Ту ПЗУшку, которую я пробовал ими стирать, они тёрли за 5 минут, будучи приложенными вплотную к окошку.
Но есть и особенности:
Такие лампы требуют кормить их определённым (300 ма) стабилизированным током. Можно от лаб. БП, можно от LM317 по схеме стабилизации тока, можно из розетки через гасящий кондёр или дроссель. При этом вначале (спиральки нагреваются) напряжение на них около 15-16 вольт, а потом (заряд загорелся) падает до ~12 вольт.
Эти лампочки ОЧЕНЬ сильно пахнут озоном (а как известно, если озоном пахнет, то его ПДК уже превышено), так что использовать их в жилых помещениях не очень.
Под ними не стоит загорать, т.к. они светят довольно коротковолновым УФ.
Появился, не очень понятно зачем, но есть https://github.com/elfmz/far2l
В линуксе все неплохо с графическими ФМ, а для консоли есть замечательных ranger.
Но теперь, конечно, некоторые косятся с завистью.
Количество отдельных элементов в наземном терминале может быть примерно 200+, сам же терминал (а по сути диаметр этой решетки) будет размером с коробку из под пиццы (как его описал сам Маск).
Весь их конструктив — антенные элементы + усилители + фазовращатели будут объединены в такой «бутерброд». Усилители и фазовращатели будут реализованы с помощью кастомных чипов. Интересно, что для приема и для передачи будут использоваться разные антенны, расположенные рядом в этом массиве.
Сами терминалы будут работать исключительно со спутниками находящимися выше 40 градусов над горизонтом. Это из-за того, что форма луча уже получается не такой оптимальной, если коммуницировать с низкими спутниками. Каждый отдельный спутник поддерживает лишь определенное небольшое количество клиентов, формируя для каждого отдельный луч. Ставка тут действительно делается на большое количество спутников и коммуникацию между самими спутниками, так что для клиентов будет получаться своего рода бесшовный «роуминг». Так же применяется круговая поляризация сигнала, так что проблем с ориентацией спутника нет. В такой схеме клиент всегда будет на связи с несколькими спутниками точно.
Связь с клиентскими терминалами происходит в Ku диапазоне, диапазон частот: 10.7 ГГц — 12.7 ГГц. Отличие downlink и uplink только в поляризации. Канал спутник-клиент работает с Правой круговой, а клиент-спутник — с Левой круговой.
С наземными станциями приземления трафика связь ведется в диапазоне 17.8 ГГц 0 19.3 ГГц, это уже Ka диапазон.
Есть еще канал телеметрии на 12.15 ГГц — 12.25 ГГц.
Спутников в небе сейчас действительно уже очень много лично я для отслеживания применяю связку сайтов heavens-above.com и n2yo.com (для получения орбитальных элементов) и программы GPredict, которая очень удобно отображает то что сейчас пролетает и в какую сторону + позволяет прогнозировать будущие проходы. См. скриншот в спойлере.
Я вот уже определенное (небольшое) время пытаюсь поймать хоть какие-то сигналы от этих спутников, возможно ту же телеметрию. Использую вполне бытовое оборудование Ku диапазона + самодельный контроллер LNB + HackRF SDR. Понимаю, что шансы тут стремяться к нулю, но повозиться с этим весьма интересно. Своего рода технический вызов :)
Понятное дело, что моя антенна это не ФАР и она может смотреть только в одну точку, а моторизированный трекер я пока не сделал. Расчет на то, что в поле зрения антенны обязательно попадает хотя бы несколько спутников. Я её предварительно навожу в точку траектории пролета.
Пока разумеется ничего поймать не удалось. Возможно просто не попадаю антенной куда нужно, возможно не хватает чувствительности приемника. А возможно спутники просто ничего не передают.
Теоретически они могут излучать сигналы маяков (beacons) что бы наземные станции могли их найти и начать процедуру подключения. Но делать они должны это на всех лучах во все возможные стороны. Это не сильно эффективно + может вызвать интерференцию. Так что возможно спутники ждут сигнала от наземной станции, что бы потом работать прицельно с ней. В общем этот момент не очень ясен.
В связи с этим делаю ставку на канал телеметрии, спутники должны активно передавать данные, особенно когда они еще едут цепочкой, после вывода.
Также существует программа Orbitron, которая позволяет узнать, где пролетает (или пролетит в указанное время) спутник.
TLE для нее беру здесь: celestrak.
— LimeSDR
— Adalm Pluto
— USRP
— BladeRF
Я покупал не в России, так что где лучше брать, не подскажу.
Есть Airspy R2, он дороже, но умеет в 10 МГц.
Абрамов Схемотехника устройств на операционных усилителях 2008.pdf
Алексеев АГ Операционные усилители и их применение.djvu
Брюс Картер Операционные усилители для всех (Схемотехника) 2011.djvu
Грем Дж Проектирование и применение операционных усилителей.djvu
Достал И Операционные усилители.djvu
Кофлин Р Операционные усилители и линейные интегральные схемы.djvu
Ленк Дж Руководство для пользователей операционных усилителей .djvu
Марше Ж.Операционные усилители и их применение.1974.djvu
Пейтон Аналоговая электроника на ОУ 1994.djvu
Фолькенберри Л Применения операционных усилителей и линейных ИС.djvu
Щербаков ВИ Электронные схемы на операционных усилителях.djvu
Полный каталог генерить некода, да, и не стоит ним флудить этот тред. Могу, конечно, выложить библиотеку под доступ (в DirectConnect, например), но, на это тоже надо время.
Настройки → Безопасность → Установка с SD-карты, выбираем файл с сертификатом, озаглавливаем по вкусу, добавляем в хранилище;По проводу всё шикарно, изображение забирается прямо с DisplayPort видеокарты. Проблем с динамичными сценами нет, но мешается сам провод. Правда, для игр которые только для сидения или стояния (например Moss или тот же Laser Saber) провод не сильно мешает, а вот в Alyx уже конкретно мешает, поэтому и покупал.
Беспроводной адаптер состоит из двух блоков: PCIe карточка WiGig от Intel (можете погуглить, у них там специальная серия под VR с малой задержкой) и приёмником на шлем. Играть удобно в динамичные игры, требующие постоянного движения.
Но вот есть один нюанс. Я до покупки думал, что адаптер будет брать видео коротким шнурком из видеокарты, а PCIe использовать только для управления, оказалось это не так. Адаптер обычный, видео с видеокарты берётся не с порта а через системную шину. При этом, штатный адаптер для проводного подключения не требуется вообще (но необходим для установления BT соединения с базами для обновления прошивки).
Таким образом, изображение грабится из буфера тем же методом, что и ShadowPlay, переносится по PCIe с видеокарты в ОЗУ, оттуда программа его пихает в карту. Как результат: если динамики нет то изображение отличное, если есть динамика, то изображение может иметь артефакты «желе», как у MPEG на движущихся объектах, только без кубиков. Особенно это заметно, если игра на обычном HDD, перенос на SSD решил проблему, я не знаю почему так — мешает контроллер HDD на PCIe хабе?
Ну и на закуску проседания сигнала. Я закрепил антенну достаточно высоко, однако они там используют какие-то бешеные частоты (mmWave 60GHz band), поэтому, если смотреть резко вверх или вниз «рожки» перекрываются головой и появляются уже обычные для низкого битрейта артефакты: банальные кубики. Иногда доходило до того, что даже звук начинал икать или шлем обрывал связь (голубой экран внутри) и несколько секунд перегружался. Некоторые игры это не любят и крашатся, что означает прерывание сессии игры на ручную перезагрузку SteamVR. Но большинство игр реагирует адекватно и ожидают готовности шлема.
А ещё, магазин HTC говорит, что есть проблемы с WiGig на платформах AMD:
Мой итог: беспроводной адаптер это действительно круто. Мечтал о VR с самого первого просмотра фильма «Газонокосильщик» в 90х. Когда появился VR клуб в городе — стал постоянным членом. Когда вышла Half Life Alyx целенаправленно купил себе домой с беспроводным адаптером. И после клуба играть без проводов действительно удобно. Но он имеет определённые требования к производительности компьютера. Да и артефакты иногда появляются.
Про это проблему знают, и ей уже минимум год, и знают про нее все, кто так или иначе занимается мобильной разработкой.
Все что вы видите — это да, по моему мнению — вина 1С, так как изначально декларировалось, что исходники прочитать нельзя, и так оно и было, а потом 1с переобулись в кувырке, и стало можно, а механизма — как защитить модули, или хотябы константы — нет.
Таким образом у людей был выбор, или прекратить разработку, или рассчитывать на то, что любой может получить доступ к данным.
Люди выбрали второе, в ожидании, пока 1с решит проблему с первым.
Более крупные компании — пишут все нужные вещи в компонентах, чтобы уж точно не прочитали те, кому не надо, но такое могут позволить далеко не все.
С другой стороны, то что можно открыть конфу на компе с данными — позволяет восстановить базу, если она рухнула, или провести тестирование и разработку на реальных данных.
А с учетом того, что 1с платофрма — это система с открытыми исходными кодами (я про конфигурации), то все как то привыкли к этому всему.
Я, в первых релизах — первый просил людей удалять такие статьи, так как это был явный нежданчик для разрабов, но уже прошел год… И если воз и ныне там… То я уже даже не знаю :)
С многопоточностью и межпоточной коммуникацией работал много. Как под Win раньше, так и под AS/400 сейчас.
Непонятно в чем сложность
Наиболее простой на мой взгляд подход. Правда, скажу сразу — с пайпами не работал — немного пробовал, не понравилось (под мои задачи). Под Win использовал MailSlots и сокеты (как TCP, так и UDP). Под AS/400 богаче выбор — UnixSockets, socketpair, DataQueue, UserQueue.
Наиболее простым оказалась синхронная реализация в отдельном потоке. Под Win задача была такая — с одной стороны N (около 30-ти плюс-минус) удаленных контроллеров, которые шлют некоторую информацию по UDP протоколу. С другой — M (3-5 обычно) интерфейсных клиентов, которые с этой информацией работают. Поток данных двунаправленный. Информация от контроллера должна быть некоторым образом обработана и на основе определенных признаков отдана одному или нескольким клиентам. Информация от клиента анализируется и передается (на основе анализа) на один из контроллеров.
Все это работает в режиме 24/7. Т.е. постоянно, годами.
Было три потока:
— поток контроллеров с открытым UDP портом в который все контроллеры послылают информацию
— поток клиентов в котором работал TCP сервер и был набор TCP соединений для уже подключившихся клиентов
— поток обработки и маршрутизации
Каждый из потоков создавал свой именованный MailSlot для приема входящей информации. Это оказалось проще чем обмен через память с синхронизацией. Любой поток мог послать данные любому потоку просто записав их в его MailSlot.
На AS-ке задачи другие. Там распараллеливание обработки между задачами (поток не используем т.к. у сопровождения сложности с их мониторингом). Там классическая Batch машина. Одна задача берет данные и подготавливает задания на обработку и несколько обработчиков, которые эти данные параллельно обрабатывают и отдают результат.
Коммуникация была комплексная. Для раздачи заданий использовалась UserQueue — очередь данных. Хороша тем, что в нее кто угодно может писать и кто угодно читать. Она не привязана к конкретному процессу. Головная задача выкладывала туда задания, а обработчики их оттуда разбирали по мере освобождения (выполнил текущее задание — отдал результат — взял из очереди следующее).
Для результатов головная задача держала открытый UnixSocket (DGRAM — он не требует постоянного соединения). Туда обработчики скидывали результаты обработки.
Тоже все работает.
OSMand — это единственный профессиональный навигатор на андроиде. Вместо трёх кнопок "домой" "в магазин" и "туды" (90% всех остальных навигаторов дают только эту фичу), это инструмент, с помощью которого можно решать разные задачи, т.е. инструмент универсальный.
Начиная с "записать по дороге трек, а потом повести по этому треку назад в режиме навигатора" и заканчивая многоточечной маршрутизацией. Пешие маршруты, сложные ситуации,etc.
Огромный респект. (обычный пользователь обычного платного osm'а без real-time update).
УСТРОЙСТВО ВВОДА ГРАФИЧЕСКОЙ ИНФОРМАЦИИ ПОЛУАВТОМАТИЧЕСКОЕ ТИПА СМП 6410
Предназначено для организации диалога оператора с ЭВМ и преобразования графической информации в цифровую форму. Устройство осуществляет ввод в ЭВМ координат точек чертежей, схем, эскизов, а также координат поля дополнительной информации.
Размеры поля: кодируемого чертежа 420ХХ130 мм; поля дополнительной информации 420ХХ120 мм. Разрешающая способность 0,1 мм. По-грешность считывания координат не более ±0,5 мм.Толщина носителя графической информации 1,0 мм.Тип носителя графической информации — диэлектрик. Режим вывода графической информации по-точечный и непрерывный. Дискретность вывода информации, задаваемая оператором, 0,1; 0,4; 0,8; 1,6;3,2 мм. Скорость считывания координат в непрерывном режиме 100 точек/с. Питание — от сети переменного тока: напряжение 220 В, частота 50 Гц.Потребляемая мощность 120 В-А. Габаритные раз-меры: планшета 600x550X140 мм, блока питания 170X260X220 мм. Масса соответственно 8 и 6 кг.