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 минутах езды от Метро. Кроме телебашни не вижу причин для снижения цены, поэтому параноя гложет ещё сильнее.
Но ведь цифровое телевидение на бОльших частотах вещает? Там ещё и радио и куча всяких антенн (но они направленные, думаю, их можно не учитывать).
Вроде как там магнитные поля высокие, но мне образования не хватает, чтобы в цифрах понять вредность конкретных значений. Хочу с детектором там прогуляться и померять величину электро-магнитных полей, но не знаю, что потом с цифрами делать :) Тем более, что прибор даже от приближения к системному блоку начинает истерично пищать о высоких значениях электро-магнитного поля.
Немного всё усложнил, слишком много кнопок написал.
Достаточно зажать Ctrl и ткнуть в слой, чтобы выделить по интенсивности цвета в слое. Либо Ctrl+Alt+3/4/5 для выделения по R/G/B каналу активного слоя.
Либо Ctrl+Alt+2, чтобы сделать выделение по яркости слоя (аналог переключения на Lab цвета и выделение по L слою).
За такую сумму только с маленьким экраном (не больше 15 дюймов). Можно сэкономить, покупая ноут без дискретной видеокарты, а только со встройкой. VS потянет любой двухъядерный процессор, с редктированием кода всё будет в порядке, а вот компиляция может быть в разы дольше, чем на взрослом ПК. Лучше брать с SSD, думаю, объяснять не надо почему. Программами для проектирования плат не пользовался, нужно смотреть в требования этих программ.
Выбирай ноут с 8ГБ памяти и возможностью добавить вторую плашку на 8ГБ, чтобы было 16ГБ в двухканальном режиме. Ещё лучше 16ГБ+16ГБ, но это уже заметно дороже будет. 4+4 тоже хватит для VisualStudio, но уже будет не комфортно с большими проектами. Лучше, чтобы сразу в магазине вторую плашку поставили и проверили совместимость-работоспособность.
Евгений Шатунов, Это потому что: Первое - я был не прав, Второе - я забыл про существование priority_queue. Не прав, потому что не подумал про сохранение порядка сортировки, а stable_sort уже делает ручную сортировку не такой производительной идеей.
но я на 99% уверен, что любое решение на основе deque (priority_queue или ручной вариант) будет самым быстрым, с учётом малого объёма данных и более частого попадания в кэш, чем при использовании деревьев (вставка-удаление заявлены редкими, поэтмоу временем на перестройку очереди можно пренебречь, независимо от её реализации).
Хранить сырые сокеты мне в любом случае не подходит, т.к. после запуска Вычислительного процесса у пользователя должна быть возможность не просто закрыть соединение, но и выключить свой ПК. Т.е. результаты сохраняются на сервере до тех пор, пока пользователь не будет готов их получить. Получается, что в процессе расчёта данные о прогрессе могут как отсылатсья, так и не отсылаться и результаты могут отсылаться как сразу, так и через какое-то время.
Полноценную СУБД решили не подключать, т.к. это сильно усложнит работу в локальном режиме, когда и клиент и сервер на одном ПК, а две разных реализации делать мы не будем. И основным режимом именно работа на одном ПК является, клиент-сервер это менее востребованный функционал на сегодня.