Я уже передаю сотни мегабайт, полёт нормальный. С сокетами работаю через Poco и напрямую с буферами не общаюсь, а использую классы-обёртки, реализующие интерфейс std::stream. Просто по Poco никаких сложных примеров не нашёл и обратно читаю по С сокетам, чтобы разобраться.
Чтение-запись выполняется в отдельном потоке, поэтому настоящий асинхронный код мне не особо нужен, т.е. я могу ждать в recv хоть сколько, если это в принципе допустимо сокетами.
Т.е. при испоьзовании блокирующих сокетов можно вообще без poll/select обойтись и сразу вызывать recv и в ней сидеть и ждать?
Optimist, Визуальное и програмное разделение кнопок это немного разное. Т.е. можно сделать визуальное разделение, но нажатия проверять вплотную, можно наоборот, можно и визуально и программно с отступом проверять.
Я всё-таки советую програмно делать отступ внутрь кнопки и какое-то время понаблюдать, пропадут ли ложные срабатывания. Т.е. чтобы понять, ошибки это пользователей или аппаратная проблема с экраном или хабом, как выше пример написали. И отступ внутрь кнопки сделать не сложно должно быть, 4 числа отнять даже эмбедед справится.
> условно держите соединение то ваш сервер блокируется
Да, сейчас именно так и работает - блокируется. Чтобы совсе мне блокировать, я вызываю poll с таймером и в цикле. Вроде как если заменить poll на select с массивом сокетов, то можно слушать сразу несколько сокетов.
Пока только начал читать книжки и ничего не понятно, но, похоже, мне нужно устанавливать логическое соединение с каждым клиентом, потому что нужно двустороннее взаимодейсткие (как минимум, чтобы пользователь мог отправить запрос на прерывание расчётов). Видимо, открывать-закрывать сокет мне не подойдёт. Или подойдёт, но я ещё не дочитал до того, как именно сделать, чтобы подходило :)
res2001, СУБД усложнит в том смысле, что сейчас данные сразу сериализуются в файл в нужном формате и в качестве результата просто возвращается имя этого файла. С СУБД придётся делать лишние записи и чтение из неё, что при локальной работе не нужно. Делать отдельную версию для сетевого варианта не хочется, поэтому пока что думаем, что сумеем обойтись без СУБД.
Спасибо. Пока что буду читать и пытаться разобраться в происходящем.
res2001, Пока что читаю Снейдера, всего 300 страниц, может не запутаюсь и что-нибудь пойму... Пока точно понял, что я путаюсь в терминологии и не могу корректно сформулировать диаграму взаимодействия процессов :)
Хранить сырые сокеты мне в любом случае не подходит, т.к. после запуска Вычислительного процесса у пользователя должна быть возможность не просто закрыть соединение, но и выключить свой ПК. Т.е. результаты сохраняются на сервере до тех пор, пока пользователь не будет готов их получить. Получается, что в процессе расчёта данные о прогрессе могут как отсылатсья, так и не отсылаться и результаты могут отсылаться как сразу, так и через какое-то время.
Полноценную СУБД решили не подключать, т.к. это сильно усложнит работу в локальном режиме, когда и клиент и сервер на одном ПК, а две разных реализации делать мы не будем. И основным режимом именно работа на одном ПК является, клиент-сервер это менее востребованный функционал на сегодня.
res2001, Сейчас Виндоус7-х64 (и старше) и Линуксы не знаю пока какой версии минимум. Велика вероятность что один из "российских" вариантов из-за санкций. Я серьёзно :(
res2001, Да, я примерно так это себе и представляю. Серверный процесс нужен только для запуска вычислительного процесса и передачи клиенту порта этого процесса. Но не ясно, как они друг друга увидят, ведь порт "случайный" и в роутере не открыт. Т.е. если в вычислительном процессе порт будет пассивным и случайным, то на клиенте нужно делать активный и открывать в роутере, но тогда только один Клиентский процесс может быть запущен. Т.е. пока идут вычисления, клиент может работать с другими расчётными моделями и запустить второй расчёт параллельно, ведь его ПК при этом не загружен расчётами.
Армянское Радио, данные тупо агрегируются в файл :) На локальном ПК файл сразу в нужном месте сохраняется и его не приходится даже передавать, а вот при работе на разных ПК этот файл с результатами расчётов придётся передавать. Как Постгрэс относится к бинарному блоб-объекту размером в десятки гигабайт?
Вроде как Poco часть проблем с сокетами решает, но обработки разрыва соединения там нет...
Вот с полноценным сокетом у меня проблема, что его же надо в роутере пробрасывать, а админ только порт для сервера пробрасывать должен, а не для каждого запущенного экземпляра. Или я ещё чего-то совсем не понимаю, но без проброса портов не получается соединиться.
Нехватка ресурсов ПК будет решаться покупкой ещё одного ПК и переносом на него части клиентов. Т.е. в этом плане можно проблему игнорировать. Уже сейчас 16 поточный ПК с 64ГБ памяти одним вычислительным процессом забивается на 100% и хочет ещё... Видимо, потом будет какое-то ограничение ресурсов на каждый процесс, но сейчас об этом можно не думать.
Я немного почитал, всё непонятно, но очень интересно :) Полноценная работа через сокеты на одном ПК с одним клиентом у меня заработала, теперь пытаюсь разобраться, как это всё переделать под работу с несколькими клиентами и сервером на отдельном ПК. Понятно, что всё на порядок сложнее и то, что аработало в простейшем случае теперь и не должно работать. TCP сокеты для двустороннего обмена, на сервер передаются несколько крупных блоков данных (обычно не более гигабайта в сумме) и потом с сервера на клиент передаётся очень много мелких данных в процессе работы и крупные объёмы с результатам ирасчётов, там объём ограничен только объёмом жёсткого диска.
Армянское Радио, Встраиваемся в имеющуюся инфраструктуру и можем использовать только то, что в ней есть. И это моё первое клиент-серверное приложение, поэтому и не умею тоже (с реляционными БД умею, но в виде standalone).
Я не вижу, как использование СУБД(любой) решает проблему передачи прогресса вычислений от 0 до 100, например.
Армянское Радио, Я не могу писать в БД десятки тысяч мелких сообщений в течении нескольких минут и десятки гигабайт тоже писать не могу.
Нужна двусторонняя интерактивная связь (не в реальном времени, задержки в несколько секунд допустимы). А вот использование сторонних библиотек не желательно. Хотя бы Poco можно использовать, уже повезло, что не нужно самому под Вин и Линукс обёртки писать.
Армянское Радио, Нет, распределёных вычислений нет. Есть офисные ПК за 10 тысяч и мощный ПК за 200 тысяч. На слабеньком подготавливаются данные и отправляются для обработки на мощный. По кусочкам данные обработать нельзя, поэтому их даже распаралелить не всегда удаётся, не то что распределить.
Передавать нужно от 4 байт (не считая любого дополнительного объёма служебных данных) до любого количества гигабайт (условно, скопировать файл с сервера на клиент, пока что больше сотни гигабайт не было).
Условно, каждый клиент имеет какой-то идентификатор (например UUID) и вначале каждого блока данных я должен этот идентификатор цеплять, чтобы сервер знал, от кого пакет прилетел? Это решит проблему с получением сервером данных от кучи клиентов (у каждого экземпляра свой UUID). Как я понимаю, после каждого чтения придётся закрывать сокет и заново ждать соединения от следующего клиента, чтобы после соединения запросить адрес клиента? Т.е. ка кобратно с сервера конкретному клиенту запрос посылать?
И что делать с "третьей" программой, которая выполняет работу и должна клиенту посылать данные? Или всё это можно провернуть через один порт при помощи 'Type'?
Сейчас, в варианте "один клиент - один сервер" я держу сокет открытым на протяжении всего времени работы. Как я понимаю, этот подход не подходит для озвученных выше требований и нужно после чтения каждого сообщения сокет закрывать?
Вот примерно такого уровня ответы в интернетах и находятся. Синдром выжившего, жил 50 лет под вышкой и жив-здоров. А пятнадцать его умерших соседей ничего написать не могут :)
Ещё есть японец, который пережил оба ядерных взрыва в Херосиме и Нагасаке (но он не рассказывает о нелетальности ядерного оружия, почему-то).
Понятно, что завтра может сосулька на голову упасть и как бы всё.
VT100, По идее, в близлежащих домах периодически должны приходить и замерять. Да и разрешение на строительство не должны были бы выдавать... Но мохнатая лапа игнорирует все СанПИНы :) Пока читал интернеты, нашёл про новость о страдающих жителях, которые купили квартиры в 25 этажном доме в 30 (тридцати) метрах от телевышки. Явно дом построили с игнорированием всех санитарных норм. Тут всё-таки 400 и 600 метров до домов и ситуация совсем другая.
Александр Писарев, Собственно, почему возник вопрос, помимо паранои. В этих домах стоимость квартир заметно ниже, чем в паре километров дальше. При том, что от дома до Метро 5 минут ходьбы. Т.е. место отличное в плане доступности. Аналогичная стоимость за метр только в 30-60 минутах езды от Метро. Кроме телебашни не вижу причин для снижения цены, поэтому параноя гложет ещё сильнее.
Чтение-запись выполняется в отдельном потоке, поэтому настоящий асинхронный код мне не особо нужен, т.е. я могу ждать в recv хоть сколько, если это в принципе допустимо сокетами.
Т.е. при испоьзовании блокирующих сокетов можно вообще без poll/select обойтись и сразу вызывать recv и в ней сидеть и ждать?