Re: Открытие/закрытие файлов.



Posted by Аркадий Водяник (195.206.226.9) on January 27, 2001 at 11:56:05:

In Reply to: По линии ликбеза. Открытие/закрытие файлов. posted by Александр, Киев on January 26, 2001 at 03:03:49:

Эпиграф:

-Он целовал Вас, кажется?!
--Боюсь, что это так...
-Но как же Вы позволили?!
--Ах, он такой чудак!
--Он думал, что заснула я,
-- и все во сне стерплю,
--Иль думал, что я думала:
-- что думал он: "Я сплю!"
(автора никак не вспомню...)

Приветствую, Вас, Александр!

Вы считаете меня гуру по вопросам открытия файлов? Это зря:)

Вы пишете:

>Аркадий! Пожалуйста, просветите, как можно подробней, или подскажите
>хороший источник по теме: механизм открытия/закрытия файлов.

Я уделил сегодня не менее 4-х часов на поиск хорошего источника;
ничего полезно-хорошего не нашел, хотя работал с AltaVista,
Yahoo, Yandex, etc. Лучше расскажу то, что уже знал до этого и
предполагал сам, процитирую также и кое-что из того, что написано
в Help'e по WinAPI 32...

>У Бори проблемы с UPTY у одного из заказчиков, мы вчера спорили до
>хрипоты.

Интересно бы, конечно, знать в точности предмет спора. Но попробую
и без этого.

Об этом я уже говорил в свое время, процитирую (неточно) сказанное:

Сообщение http://hdru.com/wwwboard/messages/1786.htm :


Как известно, файлсеpвеpное взаимодействие пpоисходит между двумя участниками:
Фаилсеpвеpом и Редиpектоpом. Редиpектоp говоpит Файлсеpвеpу: "ну-ка, откpой мне
такой-то файл". Файлсеpвеp отвечает: "ну, откpыл". Затем Редиpектоp захочет сделать
какое-то действие - напpимеp, пpочесть файл . Файлвеpвеp, если ему никто не помешает,
поможет Редиpектоpу в этом. Но если Редиpектоp на любом этапе "сойдет с ума" и,
напpимеp, не пpишлет очеpедную квитанцию Файлсеpвеpу - напpимеp, из-за заскока с
датой или упорного СТОЛКНОВЕНИЯ ПАКЕТОВ - Файлсеpвеp тоже может повести себя
нехоpошо: оставит, скажем, UPTI откpытым.

То есть нечеткий, ошибочный pазговоp между пpогpаммами, может повлечь за собой
какие-то нежелательнные последствия на любой из машин.

Хочу подчеpкнуть - Файлсеpвеp и Редиpектоp - это слой, лежащий ниже взаимодействия
наших Клиентов и Сеpвеpов. Поэтому пpетензии собственно к нашим пpодуктам здесь
вpяд ли могут пpедъявляться.

В этом тексте можно найти источник затруднений (как мне кажется),
он в следующем: я вник в исходный текст ФБП:Windows-Клиента,
написанный в свое время Димой Придаткиным, и рассмотрел как
он открывает файл UPTI:

он применяет такие флаги: OF_READ | OF_SHARE_DENY_READ,
дословно: "читать и всем другим нельзя читать".
Зачем понадобилось "всем другим нельзя читать", я не знаю, скорее
всего Дима написал это недодумав.

Следствие: в сети творится небольшое столпотворение, каждый
недоумевает: почему же мне DENY_READ - я же могу читать так же успешно
как и мой конкурирующий ФБП:Клиент...

Не всякая сеть хорошо переносит это столпотворение - это зависит
от трафика, от топологии; ну да я об этом писал еще в 1778.
Лучше минимизировать столкновения пакетов! Об этом же косвенно
свидетельствует и Ваш, Александр, рассказ, что замена сетевой платы
вылечила болезнь - меньше пакетов губить стала:)

Хочу выделить нашу вину: там что-то другое, чем это DENY... надо
было писать совсем не DENY...; будем исследовать, что именно...

Еще 1: это действительно зависит от версии Windows (и ФАЙЛОВОЙ СИСТЕМЫ FAT/NTFS)!

Еще 2: такой факт: в языке Perl (многие с ним знакомы, он используется
зачастую для написания CGI-скриптов) есть такая функция flock()
(блокировка файлов). Так вот, при переносе в Win 9x/NT/2000 эту функцию
перенести любителям Perl'a не удалось - разные Windows, разные программисты
Microsoft... А ведь такой важный, близкий к рассматриваемому вопрос!

Еще 3: в 1988-1990 я занимался написанием предельно компактной, но и
достаточно полнофункциональной сети - BISNET. Некоторые из наших пользователей
знакомы с ней: интерфейс RS-232, 115 Kбод, собственная схема соединений с
усилителями. По тем временам то был достаточно успешный и в техническом и
коммерческом отношениях проект.
Так вот, там использовалось не столкновение пакетов, а круговой обход
сервером клиентов с "рукопожатием" клиентов, готовых к этому. Понятно,
что в такой архитектуре:
а) столкновения пакетов не были возможны в принципе.
б) разрывов связи с оставлением одного из участников в неопределенном
положении - тоже не происходило.
в) были и свои недостатки, связанные с недостаточной нагрузочной
способностью, но пункта б) не было никогда.
Поэтому об особенностях взаимодействия редиректора и файлсервера я
могу говорить со знанием дела:)

Спасибо, Александр, за интересный вопрос.

P.S. С DENY... боремся, постараюсь поскорее сделать
подходящую заплату (PATCH)...


Пpишедшие ответы: