Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Без проблем можно рассмотреть, но к сожалению я например... 23.11.06 13:17 Число просмотров: 5660
Автор: DamNet <Denis Amelin> Статус: Elderman
|
> > > Сделать проверку 2 раза:
> >
> > Задача не тривиальная. Сталкивался с подобными вещами
> -
> > где-то надо было на файлообменнике что-то с файлом
> делать,
> > как его скинут. Причем не важно ФТП или МСН.
> >
> > > При первой проверке запоминать размер, но файл не
> > начинать
> > > читать
> > > При второй проверке - если есть запомненный файл
> и
> > текущий
> > > размер на ФТП совпадает с запомненным - начинать
> > читать.
> >
> > Не тривиальность в том, что скорость передачи по сетям
> > может быть мала, а размер большой, плюс задержки в
> сети.
> > Короче какие большие задержки в скрипте не делать -
> может
> > мало оказаться, с другой стороны хочется чтоб время
> реакции
> > было минимально.
> >
> > > P.S А вообще можно и размер не проверять - просто
> > читать
> > > только со второго раза... если промежуток между
> > проверками
> > > достаточно большой
> >
> > В идеале нужен сигнал скрипту, как только заливка
> файла
> > завершается. ФТП никакие сигналы слать не умеет.
> > Один из неплохих выходов - написать свою прогу
> copy/move,
> > только чтоб она пыталась открыть файл на изменение а
> не
> > "readonly". В случае удачного открытия - делаем то что
> > нужно (копируем/с_удалением), иначе откладываем до
> > следующей попытки. В предположении того, что ФТПсервер
> или
> > любая другая выкладывающая файл прога открывает файл
> тоже
> > для записи, но не в режиме SHARED копирующей проге в
> > доступе с режимом на изменение будет отказано, пока
> файл не
> > закроется.
> >
> > В принципе может помочь и небольшая задержка в этом
> > конкретном случае. Подтверждением того, что линия
> > скоростная, без задержек и размер маленький может быто
> то,
> > что подобные баги случаются довольно редко.
> Извините, за возможно идиотский постинг. Но может
> пересмотреть бизнес правила?
Без проблем можно рассмотреть, но к сожалению я например ничего лучше придумать не смог
Условия примерно такие: есть распределенная СУБД, Пусть будет главная А и переферийная Б,
каждые N минут Б создает файл с выгрузкой. Задача в общем-то простая, как можно быстрее загрузить этот файл в базу А, и выгрузить из А ответ.
Решение задачи усложняется тем, что канал между А и Б очень и очень нестабильный, и пинг состовляет порядка 800-1000 мс
При этом конечно было бы не плохо, что бы без стороннего софта, встроенными средствами MS.
> Например, все промышленные протоколы такого рода (Блюмберг,
> Рейтерс, Томсон) требуют передачи как минимум двух файлов.
> Одном манюсенький (типа дескрипшн) . Он посылается в
> последнюю очередь. Второй(ые) - сосно файл(ы).
Действительно интересное решение и имеет право на жизнь )
|
|
|
подробно о проекте
Анализ криптографических сетевых...
