Comments 29
Неплохо.
На сайте overbyte.eu есть ветка MIDWARE — я использовал изложенные автором идеи для реализации подобного обмена.
На сайте overbyte.eu есть ветка MIDWARE — я использовал изложенные автором идеи для реализации подобного обмена.
Да, разумеется, в сети много всего есть: есть и готовые решения. Я сразу говорю: мне была поставлена задача это всё дело реализовать без использования готовых решений. Так было нужно заказчику — не столько качество, сколько чего-то другое. Так что, мое решение в силу этого тоже далеко не самое оптимальное: тем более, заказчик по итогам всё равно от него отказался вообще. А я решил его выложить, чтоб труд за зря не пропадал. Может, кто-то найдет в этой куче кода что-то для себя полезное.
Повторюсь еще раз. На майлслотах все это делается куда проще… Описание в MSDN есть. Подробное и с примерами.
Там не требуется создание сервера, отслеживание соединения и все такое. Просто нужно создать майлслот и проверять, не закинул ли туда кто-нибудь чего-нибудь полезное (типа ножки для стола (с) :-)
В целом MailSlot и Pipe это как UDP и TCP сокеты.
Ну и ваш пример весьма показателен для современного мира — любители фреймворков живут исключительно внутри своих фремворков и очень слабо себе представляют возможности и API платформы, под которой они работают. Выход за пределы фреймворка сопровождается острым приступом агаророфобии.
Там не требуется создание сервера, отслеживание соединения и все такое. Просто нужно создать майлслот и проверять, не закинул ли туда кто-нибудь чего-нибудь полезное (типа ножки для стола (с) :-)
В целом MailSlot и Pipe это как UDP и TCP сокеты.
Ну и ваш пример весьма показателен для современного мира — любители фреймворков живут исключительно внутри своих фремворков и очень слабо себе представляют возможности и API платформы, под которой они работают. Выход за пределы фреймворка сопровождается острым приступом агаророфобии.
Я не понял, о какой агаророфобии вы говорите, и о каких любителях, так что буду трактовать ваши слова вольно. Если применить их к тем, о ком я думаю, то вы, вероятнее всего, где-то правы.
Ну попробую перефразировать. Долго работал под Win. Ну и общался с себе подобными. Среди них было немало людей, писавших на VCL (Дельфи и Билдер). Так вот значительная часть из них была ограничена исключительно рамками того, что предоставляет VCL. И если там чего-то нет, то все, «это невозможно потому что этого нет в VCL». Какие возможности предоставляет WinAPI они понятия не имеют — для них это темный лес, страшно и непонятно. Что такое MSDN (на мой взгляд, одна из лучших справочных систем) ни разу не слышали.
То, что в некоторых случаях эффективнее сделать свою библиотечку (а она получается очень компактной), содержащей UDP и TCP сокеты и TCP сервер для работы в синхроне в отдельном потоке для них просто откровение — люди не представляют что такое WINSOCKS и как с ним работать.
Про ряд интересных функций, которых нет в стандартных заголовках (но они описаны в MSDN и «достаются» через GetProcAddress) уж и говорить не стоит…
Вот это и есть агарофобия — в данном случае паническая боязнь выйти за пределы фреймворка на просторы системного API.
То, что в некоторых случаях эффективнее сделать свою библиотечку (а она получается очень компактной), содержащей UDP и TCP сокеты и TCP сервер для работы в синхроне в отдельном потоке для них просто откровение — люди не представляют что такое WINSOCKS и как с ним работать.
Про ряд интересных функций, которых нет в стандартных заголовках (но они описаны в MSDN и «достаются» через GetProcAddress) уж и говорить не стоит…
Вот это и есть агарофобия — в данном случае паническая боязнь выйти за пределы фреймворка на просторы системного API.
Значит, я правильно вас понял. Да, всё именно так и есть. У меня сложилось точно такое же представление о «делфийском народе».
Ну не только делфиском. На билдере все примерно также… Стремление быстро слепить продукт из VCL компонентов, не вдаваясь в детали. Это обратная сторона «низкого порога вхождения», о котором так часто упоминалось в обсуждениях Делфи.
Есть ощущение, что подобное и в других областях наблюдается (та же мобильная разработка — скорее схватить самый модный на текущий момент фреймворк и вперед — к монетизации своего приложения).
Я сам продолжительное время на билдере работал, но начинал еще под досом, с Turbo C 1.0 Б потом 2.0, Turbo C++, Borland C++ — 4-я версия была невозможно глючной, с нее ушел на MSVC и потом уже вернулся на билдер 6-й.
Помню что когда с доса на вин переходил, первое приложение написал на чистом WinAPI. Просто чтобы понимать как оно работает. Ну и в билдере не боялся апишные функции использовать там, где по каким-то причинам VCL не устраивала или ее нехватало.
Что касается межпроцессных и межпоточных коммуникаций, то в последнем виндовом проекте этого было много и пришлось глубоко вникать в эту тему.
Есть ощущение, что подобное и в других областях наблюдается (та же мобильная разработка — скорее схватить самый модный на текущий момент фреймворк и вперед — к монетизации своего приложения).
Я сам продолжительное время на билдере работал, но начинал еще под досом, с Turbo C 1.0 Б потом 2.0, Turbo C++, Borland C++ — 4-я версия была невозможно глючной, с нее ушел на MSVC и потом уже вернулся на билдер 6-й.
Помню что когда с доса на вин переходил, первое приложение написал на чистом WinAPI. Просто чтобы понимать как оно работает. Ну и в билдере не боялся апишные функции использовать там, где по каким-то причинам VCL не устраивала или ее нехватало.
Что касается межпроцессных и межпоточных коммуникаций, то в последнем виндовом проекте этого было много и пришлось глубоко вникать в эту тему.
Это не «низкий порог вхождения», а особенность нашего национального постсоветского программирования, распространенного в 1990-е и ранние 2000-е.
Вот-вот — эта особенность нас, старичков. (Рассыпает песочек...)
В 1990-е у нас Delphi и ее брат-близнец CBuilder были дико популярны. Мне сложно сказать, с чем эта дикая популярность была связана (может, книги по Pascal сюда завозили бесплатно, а за все остальные книги просили денежку), но отсюда берет начало эта распространенность Delphi на нашей территории. Собственно, не будь России, Абракадабра уже давно бы загнулась — в цивилизованных странах ее продукты уже давно нахрен никому не нужны. Одни мы их еще покупаем, вот она, видимо, потому еще шевелится.
Современное же поколение программеров этой Delphi-манией уже не охвачено. Они, полагаю, даже не в курсе, что сей уродец мира программирования существует.
Я сам продолжительное время на билдере работал, но начинал еще под досом, с Turbo C 1.0 Б потом 2.0, Turbo C++, Borland C++ — 4-я версия была невозможно глючной, с нее ушел на MSVC и потом уже вернулся на билдер 6-й.
Вот-вот — эта особенность нас, старичков. (Рассыпает песочек...)
В 1990-е у нас Delphi и ее брат-близнец CBuilder были дико популярны. Мне сложно сказать, с чем эта дикая популярность была связана (может, книги по Pascal сюда завозили бесплатно, а за все остальные книги просили денежку), но отсюда берет начало эта распространенность Delphi на нашей территории. Собственно, не будь России, Абракадабра уже давно бы загнулась — в цивилизованных странах ее продукты уже давно нахрен никому не нужны. Одни мы их еще покупаем, вот она, видимо, потому еще шевелится.
Современное же поколение программеров этой Delphi-манией уже не охвачено. Они, полагаю, даже не в курсе, что сей уродец мира программирования существует.
Ой ой, а сколько желчи полилось… Расскажите мне чем писать под виндовс так что бы не блевать в процессе, так что бы все в одном и в найтиве… да да С# в пролете. Да и что бы мне не надо было собирать среду из кусков так что ее невозможно потом воспроизвести на другом ПК.
Разговор не о том на чем писать (под винды есть Visual Studio, выросшая из MSVC + MFC). Вопрос о том как писать.
Хотите писать под винду? Учите прежде всего WinAPI и те системные средства, что она предлагает. Ну и просто архитектурные решения, позволяющие понимать когда и где выгоднее использовать асинхрон в общем потоке, а когда и где — синхрон в отдельном потоке.
Хотите писать под винду? Учите прежде всего WinAPI и те системные средства, что она предлагает. Ну и просто архитектурные решения, позволяющие понимать когда и где выгоднее использовать асинхрон в общем потоке, а когда и где — синхрон в отдельном потоке.
Современное поколение охвачено манией мобильной и ваб разработки. А там тоже фреймворки. И вопросы там «а вот этот фреймворк может это, а тот модет то». И мало кому (у меня такое впечатление) призодит в голову, что все «то» или «это» опирается на возможности платформы. А «может» или «не может» определяется исключительно тем, дошли у разработчика фреймворка руки реализовать «то» или «это», или нет.
И уж точно мало кому в голову приходит расширить фреймворк путем дописывания каких-то своих библиотек или функций.
Для себя я как-то пришел к тому, что когда чего-то нехватает, я просто дописываю это сам. А если этот кусок кода из одного проекта вдруг требуется в другом, он оформлаяется в виде библиотеки.
Долго жил под виндами. Писал на С и С++. Потом несколько лет назал в жищни случился крутой поворот и теперь я пишу под AS/400 главным образом на специфическом языке RPG (мало известен за пределами этой платформы, хотя у MS была попытка создать VisualRPG).
Язык специфический, ориентирован прежде всего на работу с БД и коммерческие рассчеты. И там совершенно нет такой вещи как списки. А я очень привык с ними работать. Даже больше, чем со статическими массивами. И очень мне их нехватало. В RPG есть указатели. И есть понятие структуры. Но все это как-то коряво там выглядит.
Но к счастью, С/С++ на этой платформие тоже поддерживается (более того, там есть концепция ILE — интегрированная языковая среда, позволяющая одну программу собирать из нескольких модулей на разных языках). Так что довольно скоро я (для себя в первую очередь, но разработка имела успех и у коллег) сделал сервисную программу (некий аналог виндовой dll) в которой было реализовано несколько алгоритмов на базе списков, которые достаточно легко можно использовать в RPG программах. Да, на это было потраченотнекоторое количество личного времени, но сейчас все это сильно упрощает разработку.
Потребуется что-то еще — будет что-то еще. Не проблема.
И уж точно мало кому в голову приходит расширить фреймворк путем дописывания каких-то своих библиотек или функций.
Для себя я как-то пришел к тому, что когда чего-то нехватает, я просто дописываю это сам. А если этот кусок кода из одного проекта вдруг требуется в другом, он оформлаяется в виде библиотеки.
Долго жил под виндами. Писал на С и С++. Потом несколько лет назал в жищни случился крутой поворот и теперь я пишу под AS/400 главным образом на специфическом языке RPG (мало известен за пределами этой платформы, хотя у MS была попытка создать VisualRPG).
Язык специфический, ориентирован прежде всего на работу с БД и коммерческие рассчеты. И там совершенно нет такой вещи как списки. А я очень привык с ними работать. Даже больше, чем со статическими массивами. И очень мне их нехватало. В RPG есть указатели. И есть понятие структуры. Но все это как-то коряво там выглядит.
Но к счастью, С/С++ на этой платформие тоже поддерживается (более того, там есть концепция ILE — интегрированная языковая среда, позволяющая одну программу собирать из нескольких модулей на разных языках). Так что довольно скоро я (для себя в первую очередь, но разработка имела успех и у коллег) сделал сервисную программу (некий аналог виндовой dll) в которой было реализовано несколько алгоритмов на базе списков, которые достаточно легко можно использовать в RPG программах. Да, на это было потраченотнекоторое количество личного времени, но сейчас все это сильно упрощает разработку.
Потребуется что-то еще — будет что-то еще. Не проблема.
Это не «мания», это запросы рынка. Да, сейчас 80% программирования — это написание сайтов (то есть .Net Core + тонна js, как раз зоопарк этих фреймворков), 15% — это Ведроид, и на десктоп остается 5%. Мы, старички, как вид программеров вымираем. А, может, даже уже вымерли.
Ну не знаю… В процентах мне сложно судить, но три года назад достаточно много вакнсий было именно на серьезную разработку — промавтоматицация, телекоммуникации, финтех и прочие подобные вещи. Т.е. по «разработчик С/С++» вылазит очень много чего разного.
Глянул я на эти мэйл-слоты нынче, и не вижу чем они проще и удобнее труб. И зачем в этой задаче негарантированность доставки и броадкаст?..
Есть принципиальная разница между слотом и трубой. Труба - потоковый канал, слот - датаграммный.
Представьте, что у некоего процесса есть канал для приема данных от других процессов. И в него 3-5 процессов постоянно что-то посылают. В случае трубы у вас буте сплошной поток байт и вам придется самому разбирать где начало очередного сообщения, где его конец и начало нового. Т.е. есть у вас в канале 5 сообщений по 10, 40, 30 и 50 байт соответсвенно. Вы читаете из канала 100 байт. В эти 100 байт попадет первое, второе, третье и первые 20 байт четвертого сообщения. А дальше вам надо разгребать что где. Это труба.
Со слотом все иначе. Там атомом является все сообщение целиком. В том же самом случае (сообщения в канале 10, 40, 30 и 50 байт) читаем 100 байт - оно в первый раз прочитает первое сообщение - 10 байт. Второй раз - второе сообщение 40 байт, в третий раз 30 байт, в четвертый - 50. И вам не надо разбираться где что.
На CreateNamedPipeW - Win32 apps | Microsoft Learn откройте для себя режимы PIPE_TYPE_MESSAGE и PIPE_READMODE_MESSAGE
Ну я, слава богу, под винду уже 8 лет как не пишу. Так, по старой памяти...
А там, подо что пишу, есть UNIX Sockets и очереди данных (UserQueue и DataQueue). Которые намного удобнее пайпов. Во-первых, это системные объекты, которые не привязаны к конкретному процессу и сохраняются даже когда нет процессов их использующих, во вторых, там возможно к каждому сообщению добавлять "ключ" который может использоваться для извлечения сообщения из очереди (например, имя процесса, для которого это сообщение предназначено). В третьих, очередь всегда позволяет посмотреть содержимое, не удаляя его (peek). Или просто узнать сколько в ней сейчас сообщений.
Эээ, пытаться сортировать в стринглисте
Да вы батенька извращенец
Делал давно такую интеграцию через простой бинарный протокол поверх стандартных пайпов на java/fpc/delphi/c++ для linux/windows/wine github.com/speaking-fish?tab=repositories
Описание слишком краткое чтобы понять в чем проблема.
С многопоточностью и межпоточной коммуникацией работал много. Как под 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 — он не требует постоянного соединения). Туда обработчики скидывали результаты обработки.
Тоже все работает.
С многопоточностью и межпоточной коммуникацией работал много. Как под 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 — он не требует постоянного соединения). Туда обработчики скидывали результаты обработки.
Тоже все работает.
С каких пор асинхронный вариант проще синхронного? В данном случае, лучше всего подходит как раз синхронный сервер, он элементарен в реализации.
Вот и я о том же… Зачатую асинхрон вообще не имеет смысла. Вот отдал ты в асинхронную обработку очередной блок данных и что дальше? Прежде чем начать обрабатывать следующий блок нужно убедиться что предыдущий получен адресатом. Т.е. тупо ждать подтверждения о корректном приеме, просто ничего не делая (да, можно начать обрабатывать следующий блок, но в ситуации когда истек таймаут подтверждения предыдущего, придется все отложить и перейти к обработке нештатной ситуации с предыдущим блоком, а это лишние сложности в коде).
В таких ситуациях (для себя) решил так — обработка в одном потоке, передача — синхрон в отдельном потоке, который уже сам все проблемы разруливает.
В таких ситуациях (для себя) решил так — обработка в одном потоке, передача — синхрон в отдельном потоке, который уже сам все проблемы разруливает.
Очень интересно, не забыть бы потом исходники изучить)
Sign up to leave a comment.
Передача файлов с помощью pipes и другие мелочи на Delphi