Обмен информацией между терминалами с помощью файлов и синхронизация. - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вы не поняли гениальной изобретательности 70-х. Если контрольные суммы не совпали, то произошло то, чего не должно быть по вашей версии. Просто повторите попытку чтения.
при создании\записи в файл по умолчанию у пишушей программы есть монопольный доступ к файлу. пока вы его не закроете пишушим скритом, читателям к нему доступа не будет и будет генериться ошибка открытия.
читатели пусть читают с этим флагом FILE_SHARE_READ|FILE_SHARE_WRITE и будут иметь при этом совместный доступ.
А если читатели в процессе чтения файла, а писатель в этот момент открывает файл для записи? Кто обломается?
Это лишь один из десятков вопросов, которые надо изучать и решать. Мне кажется, в столь общей постановке получить от кого-то подходящее решение не удастся. У всех есть какой-то опыт, но что требуется в этой задаче, неизвестно.
Задача передачи данных "один ко многим" вообще непростая. Разные решения возможны для случаев, когда данные дописываются или когда переписываются, велика ли цена данных (иначе, при утрате данных 6 секундной давности случится большая беда или как, то есть каковы допустимые задержки и потери), как часто и какие объемы требуется писать. Должны ли их прочесть все "читатели". Знает ли писатель список всех читателей или их состав произволен. Сколько их. Умеют ли читатели писать писателю свои сигналы о завершении чтения. В общем, нужна серъезная работа по проектированию, на этапе которого можно и забыть, что средством решения выбрана работа с файлами. Ведь возникающие вопросы прежде всего относятся к логике действий. Надо сразу зафиксировать требования. Сравните в этом смысле, например, протокол UDP, где сбои доставки пакетов не обрабатываются, и TCP, где недошедшие пакеты доставляются повторно. Они разные, хотя доставка осуществляется по тем же каналам. Ваш случай, уважаемый RickD, у меня ассоциируется с протоколом FTP. А он ведь сложный...
Конкретно у меня есть опыт создания и эксплуатации передачи данных от многих десятков отправителей (терминалов) одному получателю посредством файлов. Работает уже 320 торговых недель. Однако это решение лишь специальной, нужной мне задачи. Уточнили бы Вы, что именно хотите сделать.
Про Excel тут вообще пример не стоит рассматривать. В нутри одного процесса они могут синхронизировать доступ к файлу как угодно.
Лучше рассмотреть физический процесс записи в файл. Наверняка от пишется кусками из какого-то пользовательского или внутреннего буфера в цикле. Поэтому может возникнуть ситуация, когда часть файла уже обновилась, а часть еще нет. И в этот момент при чтении файла могут быть накладки.
Разве не понятно - что запись в файл не есть атомарная операция? :)
Я вижу ситуацию так. Пока идет процесс записи в файл - никто в этот момент не должен его читать. Пока кто-нибудь читает файл - никто не должен в него писать. В рамках одног опроцесса это рулилось бы критической секцией.
Про Excell так говоришь потому что не сталкивался так плотно с ним.
Прочти повнимательней документацию по открытию, закрытию и принудительной записи в файл.
Примечание
При выполнении операции записи в файл физически данные могут оказаться в нем только через некоторое время. Для того чтобы данные сразу же сохранились в файле, нужно использовать функцию FileFlush(). Если не использовать функцию, то часть данных, еще не попавших на диск, принудительно записывается туда только при закрытии файла функцией FileClose().
Функцию необходимо использовать тогда, когда записываемые данные представляют собой определенную ценность. При этом стоит учитывать, что частый вызов функции может сказаться на скорости работы программы.
Функцию FileFlush() необходимо вызывать между операциями чтения из файла и записи в файл.
часть данных, это именно та часть которая записывается во время последнего открытия файла для записи.
А если читатели в процессе чтения файла, а писатель в этот момент открывает файл для записи? Кто обломается?
читатели.
я в таких случаях пишу для каждого читателя отдельный файл. после того как читатель его прочитал он его удаляет.
Прочти повнимательней документацию по открытию, закрытию и принудительной записи в файл.
Было бы хорошо, если бы задача не требовала веры в возможность принудительной записи по FileFlush. Полтора года назад было объявлено https://www.mql5.com/ru/forum/151351/page11 07.05.2014 20:46, что принудительная запись по команде FileFlush не исполняется почти никогда. Это не значит, что команда перестала работать согласно документации только полтора года тому назад, просто в мае 2014 был задан вопрос о замеченной неработоспособности на русскоязычном форуме. Когда она действительно перестала работать, неизвестно. В документации это не отражено до сих пор. Ответа на вопрос, в каких же случаях принудительная запись срабатывает https://www.mql5.com/ru/forum/151351/page11 07.05.2014 20:52, нет.
Получается заменить (запись в конец файла, FileFlush) на эквивалентную последовательность операций (запись в конец файла, FileClose, FileOpen, FileSeek в конец файла). Замечу, что FileFlush в MQL5 по-прежнему работал в соответствии с документацией эти самые полтора года назад https://www.mql5.com/ru/forum/151351/page14 13.05.2014 09:22, но там эта замена оказалась выгодной просто исходя из быстродействия, 0.1 мс вместо 25 мс. Скачок скорости связан с тем, что, очевидно, сброс из буфера ОС идет не на магнитные пластины, а в буфер контроллера диска. Кто хочет проверить, как оно работает сейчас - программка в последней ссылке.
Было бы хорошо, если бы задача не требовала веры в возможность принудительной записи по FileFlush. Полтора года назад было объявлено https://www.mql5.com/ru/forum/151351/page11 07.05.2014 20:46, что принудительная запись по команде FileFlush не исполняется почти никогда. Это не значит, что команда перестала работать согласно документации только полтора года тому назад, просто в мае 2014 был задан вопрос о замеченной неработоспособности на русскоязычном форуме. Когда она действительно перестала работать, неизвестно. В документации это не отражено до сих пор. Ответа на вопрос, в каких же случаях принудительная запись срабатывает https://www.mql5.com/ru/forum/151351/page11 07.05.2014 20:52, нет.
Получается заменить (запись в конец файла, FileFlush) на эквивалентную последовательность операций (запись в конец файла, FileClose, FileOpen, FileSeek в конец файла). Замечу, что FileFlush в MQL5 по-прежнему работал в соответствии с документацией эти самые полтора года назад https://www.mql5.com/ru/forum/151351/page14 13.05.2014 09:22, но там эта замена оказалась выгодной просто исходя из быстродействия, 0.1 мс вместо 25 мс. Скачок скорости связан с тем, что, очевидно, сброс из буфера ОС идет не на магнитные пластины, а в буфер контроллера диска. Кто хочет проверить, как оно работает сейчас - программка в последней ссылке.
Про Excell так говоришь потому что не сталкивался так плотно с ним.
Прочти повнимательней документацию по открытию, закрытию и принудительной записи в файл.
часть данных, это именно та часть которая записывается во время последнего открытия файла для записи.
Я не совсем понимаю суть твоего комментария про FileFlush(). Он ускоряет запись в файл, но не гарантирует, что файл не находиться в процессе чтения.
Я думаю - копать надо в сторону эксклюзивного чтения или записи в файл каждый момент времени.
читатели.
я в таких случаях пишу для каждого читателя отдельный файл. после того как читатель его прочитал он его удаляет.
Это лишь один из десятков вопросов, которые надо изучать и решать. Мне кажется, в столь общей постановке получить от кого-то подходящее решение не удастся. У всех есть какой-то опыт, но что требуется в этой задаче, неизвестно.
Задача передачи данных "один ко многим" вообще непростая. Разные решения возможны для случаев, когда данные дописываются или когда переписываются, велика ли цена данных (иначе, при утрате данных 6 секундной давности случится большая беда или как, то есть каковы допустимые задержки и потери), как часто и какие объемы требуется писать. Должны ли их прочесть все "читатели". Знает ли писатель список всех читателей или их состав произволен. Сколько их. Умеют ли читатели писать писателю свои сигналы о завершении чтения. В общем, нужна серъезная работа по проектированию, на этапе которого можно и забыть, что средством решения выбрана работа с файлами. Ведь возникающие вопросы прежде всего относятся к логике действий. Надо сразу зафиксировать требования. Сравните в этом смысле, например, протокол UDP, где сбои доставки пакетов не обрабатываются, и TCP, где недошедшие пакеты доставляются повторно. Они разные, хотя доставка осуществляется по тем же каналам. Ваш случай, уважаемый RickD, у меня ассоциируется с протоколом FTP. А он ведь сложный...
Конкретно у меня есть опыт создания и эксплуатации передачи данных от многих десятков отправителей (терминалов) одному получателю посредством файлов. Работает уже 320 торговых недель. Однако это решение лишь специальной, нужной мне задачи. Уточнили бы Вы, что именно хотите сделать.