И в качестве аутпута - должны быть команды на ордер.
Потом ограничения на время. И после этого можно делать реализацию.
В твоем случае - надо еще обсудить наверное API бирж. Они все разные.
SLA (типа задержку между публикацией цен и принятием решения) Протокол
и прочее. Мне кажется что ты потонешь в технических вопросах еще даже не
доходя до алгоритма.
Скажи пожалуйста у тебя уже решены все технические вопросы?
Юрий, обычно API не различает никакого дублирования папок.
Есть mkdir. Есть копирование файлов.
Я сильно сомневаюсь что можно запретить mkdir при условии что уже
существуют где-то такие-же папки. В целом - ограничители выглядят
достаточно фантастично для generic filesystem.
Но вы наверное можете попробовать ограничить само приложение
которым пользуются пользователи. Разумеется - никаких
яндекс дисков и никаких S3 buckets. Только приложение.
Тут - организационный вопрос. Непонятно что пользователям надо разрешать и что запрещать.
Из текста ясно - что им надо редактировать файлы "везде". Мне это кажется странным.
Один пользователь выполнил работу. Другой из соседнего департамента взял и чего то отредактировал.
Короче полно всяких кейсов которые надо обсудить еще до внедрения хранилищ.
Померяй скорость между HP и ПК. Я не знаю чем меряют в Windows. Но для линукс есть куча утилит
типа
- ipperf
- nload
- speedtest-cli
Это позволит нам хотя-бы убрать из уравнения Интернет и мерять просто прямую связь. Торренты - вообще
плохой индикатор. Их скорость зависит от многих условий которыми мы не управляем вообще.
Константин, это преподаватель тебе задал такое?
Статистика сканирование портов - обще-известна. Это обычно порты http, https, ssh, ftp, pop3, imap, dns, LDAP, smb, и отдельно
порты Windows-систем такие как RDP, популярные DBMS
(MySQL, Postgresql) кеши (Redis) и клиенты торрентов.
Их списки часто публикуют на сайтах инфо-безопасности.
Сильно сомневаюсь что ты соберешь какую-то интересную информацию
которую можно обобщать. Или тебе надо собирать не на одном хосте а на сотне
и в разных странах. Тогда если складывать логи сканов в биг-дату можно
сделать какие-то исследования и понять тренды.
EugeneVKruglov, я не настраивал SQLite никогда. Не было у мен с ним задач таких.
Но вот когда Ораклы или PG настраиваешь - то там есть блочный кеш (или страничный)
и он указывает сколько под БД можно брать памяти.
szQocks, во многих DBMS существует лимит на размер текста запроса. К примеру в Oracle
он был 64К. Для MySQL я такого явного лимита не нашел. Но реально ограничения могут
сработать в других частях стека. В сети например (IP packet) или в ограничениях самого
SQL парсера-оптимизатора.
Den18, это совсем другая ошибка. И по ней можно заводить отдельный вопрос в хабр.
Но это никоми образом не меняет суть моего предложения по первому вопросу.
то сначала очень подробно описывают все инпуты. Например
И в качестве аутпута - должны быть команды на ордер.
Потом ограничения на время. И после этого можно делать реализацию.
В твоем случае - надо еще обсудить наверное API бирж. Они все разные.
SLA (типа задержку между публикацией цен и принятием решения) Протокол
и прочее. Мне кажется что ты потонешь в технических вопросах еще даже не
доходя до алгоритма.
Скажи пожалуйста у тебя уже решены все технические вопросы?