? уважаемый, какой ioctl в tls? я могу еще допустить мысль, что tls-не часть ядра линуха и ее тупо по этой причине не замечают. но виртуальную память не заметить в ядре - просто невозможно.
неофитом вы назвали человека, проработавшего 35 лет в разработке и аналитике it. возможно, вы чего-то не поняли? такая мысль вас не посещала?
комментируют те, кто хочет. никто никого не заставляет и тем более не собирает.
fifo и сокеты - это НЕ КЛАССИЧЕСКИЕ файлы. вы читаете не внимательно. в той же винде сокет не рассматривается как файл. только линух пытается работать с сокетами как файлами. классический файл имеет размер. точка.
разницу уже показал, но вы упорно ее не замечаете. ваш пример - это хафдуплекс. вы дуплексный пример мне покажите при работе с сокетами через файловые хендлы. коментировать вашу ссылку по этой причине нет смысла.
вы можете в какой-нибудь файловой системе никса поместить часть видеофайла на локальный hdd, а часть - в облако? ну или хотя бы в другую файловую систему на другом физическом диске того же компа? если спросите зачем, значит комменты вы не читали. или читали не внимательно. повторяться не буду.
на уровне ядра: поясните мне, пожалуйста, каким образом файловый ввод-вывод относится к виртуальной памяти?
про documentum - на вкус и цвет. однако, такая система есть и стабильно продается. ваш доход выше, чем у компании, продающей documentum? ну так и держите свое фи при себе
т.е. oob сокетов вы тоже причисляете к файловым механизмам?? а в каком толмуде написано, что по одному ФАЙЛОВОМУ дескриптору можно передавать параллельные потоки данных в одну сторону? А где написано, что файловые дескрипторы могут использовать дуплекс (одновременную передачу в разные стороны)? а где сказано, что при файловых операциях данные могут изменить длину и состав (tls и архивирование)?
не многовато ли нагрузок вы накладываете на понятие файла?
ну, ладно, а виртуальная память у вас тоже через файлы работает? это базовый механизм ядра.
банальная описка. смешно видеть снисходительные отзывы "гуру" абстрактного мышления. вы сами за деревьями леса не видите. столько примеров привел и ни одного контр-аргумента по теме.
такие попытки были. но бд не справились с объемами. практически все мега-хранилища документов терабайтных объемов используют бд только для хранения ссылок на файловую систему и метаинформации типа наследования документов. сами доки хранят в фс ос. что конкретно там произошло я не в курсе, но с тех пор попытки поутихли.
впрочем, я тоже недоумеваю, поскольку хранить терабайты документов обычному юзеру и не надо. и современные бд вполне могут хранить все файлы с машины среднестатистического пользователя.
возможно, тут действуют какие-то штатовские законы о конкуренции. т.е.получится, что какая-то одна бд получит конкурентное преимущество.
нет, речь о том, что вы покупаете дорогущий медиасервер. а завтра контора-разработчик помахала вам ручкой и забила на техсуппорт. и вы идете покупать следующий дорогущий медиасервер. я не предлагаю решение, а всего лишь указываю на проблему
вспомните принципы файлового ввода-вывода. сперва открывается файл с каким-то именем. всегда! это либо реальное имя файла, либо файла-устройства.
при открытии получаете дескриптор файла, который используете для операций записи и чтения.
виртуальная память работает совсем по-другому. сам процессор (на примере intel) поддерживает специальные структуры-таблицы gdt и ldt, которые описывают страницы-куски памяти дескрипторами (записями) этих таблиц. в дескрипторе есть бит- загружена страница в ram или выгружена на диск. когда ваша прога обращается к куску памяти по адресу, она использует не только адрес, но и селектор, в который помещен номер дескриптора gdt/ldt. например прочитать байт по ds:[edi]. в edi содержится смещение байта от начала области памяти. а сам физический адрес памяти проц определяет по номеру дескриптора в ds, затем лезет в gdt/ldt и оттуда определяет физический адрес начала блока памяти, который складывает со смещением из edi.
далее процессором происходит попытка чтения по рассчитанному адресу. ввиду того, что дескриптор пометил блок памяти выгруженным, генерируется аппаратное исключение(int). обработчик этого исключения разгребает проблему: определяет, что страница памяти выгружена и ее можно загрузить. освобождает кусок ram(возможно, выгружая другие страницы памяти), подгружает нужный блок с диска и возвращает управление на адрес кода, который читал этот байт. т.е. команда проца как бы рестартует заново с новым состоянием системы. теперь чтение байта проходит успешно.
Вот этот механизм очень похож на файловый ввод-вывод? Да даже не рядом..
файлы-устройства, вроде обсудили. том всегда ограничен. даже рассмотрел пример виртуальной памяти и сокетов. привел конкретные примеры, что файлом не является. ну я уж не говорю про объекты без состояния, кои к файловому вводу-выводу вообще отношения не имеют.
и если пайпы можно посчитать за файловый ввод-вывод, то блокировки вы к нему как отнесете?
машину состояний ни разу не делали? ей хранение практически никогда ненужно. если нужно, то это уже процесс.
а в случае tls/ssl иостилами не обойтись. там хендлы сертификатов и ключей нужно хранить, состояние сервера и клиента. и еще кучу мутотени. и непонятно при чем здесь криптооперации, когда файловый ввод-вывод - это что получил, ровно то и отдал. а в криптооперациях даже длина может поменяться, не говоря уже о содержимом.
если все это реализовать через иостилы, то получится корова на бане. это вам говорит человек, который расковырял исходники openssl.
давайте еще раз резюмирую. даже если трактовать фразу "все есть файл" как "все состоит из файлов", а разница, согласитесь, есть, то это - все-равно не так.
файловый ввод вывод не поддерживает дуплексные операции. сокеты-поддерживают. ускорение в 2 раза не является причиной для перехода на дуплексный обмен вместо файлового?
stdin, stdout и stderror- это стрим, искусственно разбитый на 3 файловых хендла. был бы дуплекс, потребовался бы один хендл. в winapi, например, количество системных хедлов ограничено в районе 64к или менее на процесс. делить это число на 2 или 3 в реальных условиях не есть хорошо. именно по этой причине в delphi ушли от графических оконных хендлов в визуальных компонентах. то есть, скроллбар в окне винды имеет свой хендл субокна, а в delphi есть только хендл всего окна. скроллбар отрисовывается внутри основного окна. т.е. проблема количества хендлов не надумана мной.
виртуальная память ядра ни разу не является файловой операцией. даже по той причине, что она дробнее файла и действует на уровне страницы памяти. каждая страница, сгружаемая на диск не имеет своего имени файла. и то, что в той же винде оно хранится в своп-файле тоже ничего не означает. потому что этих файлов может быть несколько на разных дисках. где-то из драйвера виртуальной памяти все это дело пишется в некое место, условно зарезервированное за файлами свопа. файл свопа нужно организовать только затем, чтобы на это место никто ничего другого записать не мог. и заметьте, пишется своим способом, а не файловым вводом-выводом ос.
бд предоставляют альтернативный вариант организации хранилища, нежели файлы. т.е. можно выделить бд целый том и она будет его использовать своим образом. как-то много ранее я сравнивал производительность db2 с хранилищем из файлов и с хранилищем на томе. с разгромным счетом файлы проиграли.
в указанных случаях где тут файловый ввод-вывод? в 1-нет, во 2ом- 3 файла и программа ими управляющая, извините, это не чисто файл. в 3-ем опять нет файлового ввода-вывода.
и что же я придумал? от нас скрывают правду, Карл..
пример фантазии на эту тему я озвучил несколько выше в комментариях, не хочу повторяться. конечно, это не решает полностью проблему циклической записи, но облако поджимать видеоконтент может более качественно, чем ваша локальный видеорегистратор. а заодно распознавать лица и номера авто. а это означает, что вместо 2 недель записей у вас могут храниться 3 на тех же ресурсах. кроме того, проц на клиенте может быть слабее. уже интереснее. вся описанная мной схема сейчас может быть реализована только путем заказной разработки. подобных коробочных продуктов я не видел. хотя я не очень хорошо знаю возможности современных медиасерверов. это очень дорогая игрушка, чтобы в нее просто играться.
но тут дело, скорее, в концепции и программной архитектуре. вот недавно появился, а потом исчез коммент про стандартные консольные потоки stdin, stdout, stderror. прекрасная иллюстрация моей идеи. все три потока составляют один объект "консоль". Файловые дескрипторы, в отличие от тех же сокетов, не способны к дуплексной передаче данных. Иначе бы stdin и stdout реализовали на одном дескрипторе. Другими словами, вы не можете и читать из файла и писать туда одновременно. С точки зрения файла - это бессмысленно и труднореализуемо (блокировки). С точки зрения стрима - очень даже полезно.
Иными словами. стандартная консоль - это НЕ файл. Это 3 файла. И обьект управления над ними. Что и требовалось доказать.
нет, это архитектурно другой подход. в варианте с чистым стримом вы никогда eof не проверяете. просто послали в все. если хранилище не готово, оно вернет ошибку и клиент-программа может ее игнорировать, например. а то может, и вообще не вернет, как в случае с udp. там вообще соединений нет. послал и забыл.
клиент, формируя контент, хочет работать только с ним. т.е. х265 и сотоварищами. вы предлагаете такой клиент нагрузить работой по мониторингу и управлению файловыми ресурсами. Но если мы говорим о коммуникационных слоях, то зачем работу одного слоя перекладывать на другой, более высокий? Это как tcp попросило бы поуправлять своими соединениями верхний протокол http.
задача клиента - сформировать и отправить контент. облачный сервер же не просит поуправлять своими файлами клиента? Так почему же на одной машине вы это допускаете?
т.о. задача формирования и отправки контента должна лежать на медиасервере. а задача управления сохранением этого контента должна лежать на файловом/стримовом сервере. И здесь уже речь о хранении структурированного контента. ну, в теории, оба сервера могут располагаться на одной машине. и сейчас происходит сериализация структурированного контента в один файл. зачем? это оверхеды.
согласен, это лишь показывает, что ms давно уже готовится к переходу на стримы. но все вот что-то никак.
Однако! Командами командной строки обычные юзера не пользуются. Не все файл-менеджеры, включая проводник, поддерживают отображение файловых потоков. файловое winapi тоже стримы не видит, их там несколько. Плюс к тому же, здесь мы видим стрим как атрибут файла. И его содержимое предстоит разбирать каждой программе отдельно. Это не очень удобно, поскольку формат файла получается закрытым и никакой сторонний плеер не сможет проиграть видео из такого стрима. Только свой. И невозможно, какой-то стрим показать, а какой-то скрыть. Либо все, либо ничего. Ну так и живет.
Не все современные фс поддерживают понятие стрима. А unix так и вообще стрим выводит в коммуникационный протокол, хотя это давно уже не так: в rfc описывают не только контракт и протокол, но и последнее время начали описывать основы реализации - сервер ДОЛЖЕН или НЕ должен делать то-то, клиент в таких случаях делает -то-то.. Чисто коммуникационный протокол - это контракт +схема взаимодействия. все. А когда вам начинают расписывать состояния клиента и сервера, да еще по маршрутам (напр. в tls по варианту psk или без), то это что ни на есть уже реализация. Не протокол взаимодействия.
И если говорить про паттерны хранения(см. тут рядом в комментах), то у такого стрима (а точнее его дорожки хранения) должно быть api выбора конкретного объекта с этой дорожки. Например, дорожка стрима хранит аудиосэмплы. Должна быть возможность сказать: "а подайте мне вот тот сэмл с перламутровыми пуговицами". Или видео за номером 2. Такого в ntfs и винде сейчас нет. Но! есть подобная фича в структуре pe-файла, к которому можно привязать бинарные ресурсы. Однако, файл имеет конечную длину и размещен на внутреннем носителе. Переместите, скажем, на ftp/http- стримы потеряются.
Сейчас же для каждого аудиосэмпла игры придется делать свой стрим. Или свой файл. Или делать свою БД для этих целей.
Так что стримы ntfs - это лишь полшага. Над ним можно много чего надстроить. но хотелось бы это в виде стандарта в ОС. Тогда отпадет необходимость делать самописные файлы-бд для хранения ресурсов и контента. Это достаточно объемный кусок работы, надо сказать.
Ну и в итоге, не цель статьи была сказать как делать. Цель статьи - озвучить, что файл в настоящем виде исчерпал свой потенциал. Идея многодорожечного стрима дает гораздо больше интересных вариантов для хранения, передачи и главное - параллельной обработки данных.
с таким подходом вы систему с высоким уровнем надежности не сделаете.
Допустим, у вас ранее был веб-сервис на порту 80. Ныне это считается небезопасным, поскольку данные авторизации и sessionid передаются в открытом виде. И вы решаете приспособить к веб-сервису tls на 443 порту. а на 80 порт просто вешаете редирект на 443.
Что получается? Если ранее вы использовали oob, то теперь - никак. Это раз. И все упирается в концепцию файла-единого потока. К слову, медиасервисы реально открывают несколько соединений для своих нужд. Это я к тому, что их УЖЕ не устраивает концепция единого файла-потока.
И что делать, если ваша система высоко нагружена, а память исчерпалась? отказывать в запросе? я как раз и веду речь, что tls-у нет необходимости держать все поступившие запросы в памяти. Если их слишком много, то часть можно кешировать/сохранить на диск. Получается, что смысл хранения на диске для tls потока - временное кеширование.
Растить память на сервере бесконечно вы не сможете. Такой подход может быть выходом из ситуации. И рассматривать сетевые протоколы только как коммуникационные - это тоже устаревшая идея, имхо.
В качестве еще одного примера приведу http и загрузку по нему на сервер для хранения 10гб-ого видеофайла. Что делает сервер? Он тупо скидывает полученные пакеты в вируальную память, которая может системой сбрасываться на диск, при необходимости. Поскольку когда там придет еще последний кусок - не понятно, а ram нужна здесь и сейчас. И вот когда последний кусок получен и http увидел, что content-length у него сравнялся с фактически полученным, он отдает эту всю виртуальную память куда-то далее, возможно, кусками через ram.
Если вы попытаетесь этот весь файл разместить в ram на все время его получения, количество потенциальных пользователей вашего сервиса сократится до пары десятков при условии размера ram 200—300гб. и это не считается хорошим паттерном.
А http также считается коммуникационным протоколом, как и tls. А по tls идет примерно тот же объем данных, что и по http.
Поскольку вас вопрос вызвал интерес, давайте попробую дополнить некой фантазией, как могло бы быть в реальности.
Вот у меня есть смартфон, не дешевый. Но я заметил, что 4к видео он пишет не очень заморачиваясь на сжатие. Другими словами, я могу в видеоредакторе это видео подсжать еще раза в два. Правда, потратив какое-то время. Это совершенно точная информация, поскольку я иногда делаю и выкладываю видеоролики.
Допустим, примерно так же работают системы видеонаблюдения - пишут какой-то полусырой контент на диск, не особо утруждаясь его сжатием. это снижает требования к процессору.
Теперь, допустим мы имеем реализацию чистого стрима, т.е. отдаем данные на хранение, не заморачиваясь сколько там свободного места осталось. Что может делать механизм хранения? он пишет на свои hdd сколько может. Где-то при заполнении дисков, допустим, на 90% он параллельно отправляет самую старую часть данных в облако на временное хранение, т.о. высвобождая место на локальных hdd. т.е. концепция "подержи немного, скоро заберу". и так далее до окончания стрима. по окончании стрима он более тщательно запаковывает данные и возвращает из облака ранее отправленную туда часть. при этом, само облако может более качественно поджать эти данные. т.е. назад пойдет меньший обьем. и все уместится на локальный hdd.
замечу, при этом, все время работы стрима и после на локальном hdd присутствует схема хранения стрима и мы точно знаем, где какой кусок находится: часть у себя, часть- в облаке. если не смогли забрать все из облака по причине недостатка места на hdd, просто сигнализируем оператору. но в любом случае, медиасервер может работать с полным контентом отгребая его с hdd или из облака. и это уже проблема оператора проплатить облако на время, пока он не сможет перегнать контент в надежное хранилище целиком.
В итоге, мы имеем схему, где облако выступает буфером пиковой нагрузки при работе медиасервера. Как уже указал, облако можно привлекать не только для хранения, но и обработки данных: сжатия, распознавания номеров и лиц и.т.д. т.о. назад уже может вернуться структурированная информация.
Сейчас подобные реализации, может, и существуют. Но я о них не знаю. Это означает, что они если и есть, то не очень широко известны. И их владельцами могут быть какие-то частные конторы с непонятным будущим.
Более того, сейчас подобные схемы могут быть реализованы в медиасерверах. А они стоят ну очень дорого. Другими словами, вася пупкин не будет покупать такой медиасервер, чтобы сделать свой видеоредактор. Вот о том и речь, что хорошо бы в фс ос ввести хотя бы функции хранения такого контента. И здесь помогли бы существенно паттерны для хранения в стриме. Надо вам хранить видео с 4 дорожками - пожалуйста, открывайте стрим с паттерном таким. Надо вам хранить ресурсы видеоигры - паттерн такой. Нужно вам сохранить ресурсы web-сайта - патерн такой.
Сами паттерны могут определять количество дорожек хранения и их назначения. Например, для игры можно определить дорожку 3-д фигур, дорожку текстур, дорожку звуковых сэмплов и т.д. Сейчас каждый разработчик изобретает свой "велосипед".
начну с конца вашего ответа. тогда это будет решение конкретного разработчика. другая контора будет придумывать ровно такой же механизм. и все изобретают велосипеды.
момент второй. файл в ос ограничен по размеру. что делать с дескриптором файла, если в одном из ним закончится место? получается, нужен механизм открытия и закрытия файлов, а также определения свободного места в файле. этого всего можно избежать в концепции потока. аналогия - вы отдаете поток в облако и там оно хранит его в файлах на раиде. но для вас как клиента это поток, а не набор файлов. про файлы вы вообще ничего знать не будете. вы его отдаете, не заботясь о наличии свободного места, не заботясь об открытии новых файлов и ровно также забираете. и теперь альтернативный сценарий - с сервера ютуба, напр., вам идет видео, поделенное на файлы. очевидно, что плеер это все должен как-то собирать. это все оверхеды.
есть еще одно техническое отличие потока от файла. в ос блокировка ставится на файл целиком, а у потока - только на "дорожку" потока, т.е. условно на часть файла.
блокировка части файлов ранее реализовывалась той же ms, но не удачно. потом они вообще отказались от таких механизмов. а в стриме это будет возможно, поскольку дорожка хранения будет физически обособлена от других и связана с ними только логически. на уровне - если начали читать одну, то и вот эту тоже готовь в параллели.
неть. все есть несколько файловых дескрипторов, обьединенных каким-то одним объектом, в ваших терминах, в общем случае.
целью статьи как раз и было это показать. другими словами, можно было бы упрощенно сказать, что понятие потока данных расширяет несколько файлов. ну потому что удобно в разных дорожках потока/файлах передавать/хранить однородную информацию - или видео или аудио или телетекст. опять же, в фильме есть основное видео и есть бонусное видео. очевидно, что их лучше хранить раздельно для возможности быстрого доступа к обоим.
на dvd они так и хранятся отдельными "дорожками". я говорю о том, что пора бы такое хранение организовать на уровне фс в ос, а не только в cdfs.
вместе с тем, сведение работы с потоком к файловым операциям вынуждает отрывать функцию управления потоком и помещать ее в отдельную библиотеку. что приводит к все новым форматам потоков в файле. а можно было бы иметь один универсальный формат хранения на уровне ос. но наполнять его разным контентом. разницу чувствуете?
ну, api- это всего лишь фасад для механизмов. в принципе, ms реализовала его для вынь в виде com+ и idl-интерфейсов. универсальный апи для всего. это покрывает функции управления и передачи практически на любом уровне. они даже обьектную модель драйверов сделали на подобном механизме.
однако, он не затрагивает вопросы хранения. т.е. здесь еще важно как хранить. в свое время ms ушла от стандартного odbc драйвера к mssql в пользу oledb драйвера. знаете в чем основная разница? odbc хранит данные по записям, а oledb - по колонкам. Оказывается, хранение однородных данных в массивах устраняет оверхеды при хранении данных. По скорости работы разницы я не заметил, но сейчас best practices- это oledb.
т.е.инженеры ms посчитали важным иначе хранить и передавать данные. вот я здесь о том же, но уже для файлов.
а вообще статья была лишь призвана проиллюстрирована, что давно уже не все есть файл. надеюсь, примеров привел достаточно.
важными для целей статьи. не ерничайте. я знаю, что у файла есть еще имя и атрибуты создания. к данной теме они отношения не имеют. уже раз 5 написал, что чтение из одного файла разнородной информации приводит к необходимости создания структуры такого файла. а для машины - это оверхеды на запаковку и парсинг такой структуры. для разработчика - это все новые виды структур. а мог бы быть единый механизм хранения и передачи разнородного контента.
ps конкретно про tls. он сидит на tcp. если tcp тоже рассматривать как файловую операцию, то возникает такое понятие как oob данные (параллельный поток данных). сейчас этот костыль зарыт в tcp. и эти oob данные нужно еще как-то протащить через криптованные данные tls, где идет учет каждого пакета. т.е. просто как-то там вставить пакет внутрь tls потока не получится. т.о. oob пойдут либо в нешифрованном виде, либо шифровать их нужно как-то отдельно. а соответственно, возникает рядом еще один такой ssl. это все вынуждает не использовать oob, а как-то мудрить со структурой основного потока на более высоком уровне. любая новая структура - это оверхеды на ее создание и парсинг.
? уважаемый, какой ioctl в tls? я могу еще допустить мысль, что tls-не часть ядра линуха и ее тупо по этой причине не замечают. но виртуальную память не заметить в ядре - просто невозможно.
неофитом вы назвали человека, проработавшего 35 лет в разработке и аналитике it. возможно, вы чего-то не поняли? такая мысль вас не посещала?
комментируют те, кто хочет. никто никого не заставляет и тем более не собирает.
fifo и сокеты - это НЕ КЛАССИЧЕСКИЕ файлы. вы читаете не внимательно. в той же винде сокет не рассматривается как файл. только линух пытается работать с сокетами как файлами. классический файл имеет размер. точка.
разницу уже показал, но вы упорно ее не замечаете. ваш пример - это хафдуплекс. вы дуплексный пример мне покажите при работе с сокетами через файловые хендлы. коментировать вашу ссылку по этой причине нет смысла.
вы можете в какой-нибудь файловой системе никса поместить часть видеофайла на локальный hdd, а часть - в облако? ну или хотя бы в другую файловую систему на другом физическом диске того же компа? если спросите зачем, значит комменты вы не читали. или читали не внимательно. повторяться не буду.
на уровне ядра: поясните мне, пожалуйста, каким образом файловый ввод-вывод относится к виртуальной памяти?
про documentum - на вкус и цвет. однако, такая система есть и стабильно продается. ваш доход выше, чем у компании, продающей documentum? ну так и держите свое фи при себе
т.е. oob сокетов вы тоже причисляете к файловым механизмам?? а в каком толмуде написано, что по одному ФАЙЛОВОМУ дескриптору можно передавать параллельные потоки данных в одну сторону? А где написано, что файловые дескрипторы могут использовать дуплекс (одновременную передачу в разные стороны)? а где сказано, что при файловых операциях данные могут изменить длину и состав (tls и архивирование)?
не многовато ли нагрузок вы накладываете на понятие файла?
ну, ладно, а виртуальная память у вас тоже через файлы работает? это базовый механизм ядра.
банальная описка. смешно видеть снисходительные отзывы "гуру" абстрактного мышления. вы сами за деревьями леса не видите. столько примеров привел и ни одного контр-аргумента по теме.
такие попытки были. но бд не справились с объемами. практически все мега-хранилища документов терабайтных объемов используют бд только для хранения ссылок на файловую систему и метаинформации типа наследования документов. сами доки хранят в фс ос. что конкретно там произошло я не в курсе, но с тех пор попытки поутихли.
впрочем, я тоже недоумеваю, поскольку хранить терабайты документов обычному юзеру и не надо. и современные бд вполне могут хранить все файлы с машины среднестатистического пользователя.
возможно, тут действуют какие-то штатовские законы о конкуренции. т.е.получится, что какая-то одна бд получит конкурентное преимущество.
нет, речь о том, что вы покупаете дорогущий медиасервер. а завтра контора-разработчик помахала вам ручкой и забила на техсуппорт. и вы идете покупать следующий дорогущий медиасервер. я не предлагаю решение, а всего лишь указываю на проблему
вспомните принципы файлового ввода-вывода. сперва открывается файл с каким-то именем. всегда! это либо реальное имя файла, либо файла-устройства.
при открытии получаете дескриптор файла, который используете для операций записи и чтения.
виртуальная память работает совсем по-другому. сам процессор (на примере intel) поддерживает специальные структуры-таблицы gdt и ldt, которые описывают страницы-куски памяти дескрипторами (записями) этих таблиц. в дескрипторе есть бит- загружена страница в ram или выгружена на диск. когда ваша прога обращается к куску памяти по адресу, она использует не только адрес, но и селектор, в который помещен номер дескриптора gdt/ldt. например прочитать байт по ds:[edi]. в edi содержится смещение байта от начала области памяти. а сам физический адрес памяти проц определяет по номеру дескриптора в ds, затем лезет в gdt/ldt и оттуда определяет физический адрес начала блока памяти, который складывает со смещением из edi.
далее процессором происходит попытка чтения по рассчитанному адресу. ввиду того, что дескриптор пометил блок памяти выгруженным, генерируется аппаратное исключение(int). обработчик этого исключения разгребает проблему: определяет, что страница памяти выгружена и ее можно загрузить. освобождает кусок ram(возможно, выгружая другие страницы памяти), подгружает нужный блок с диска и возвращает управление на адрес кода, который читал этот байт. т.е. команда проца как бы рестартует заново с новым состоянием системы. теперь чтение байта проходит успешно.
Вот этот механизм очень похож на файловый ввод-вывод? Да даже не рядом..
файлы-устройства, вроде обсудили. том всегда ограничен. даже рассмотрел пример виртуальной памяти и сокетов. привел конкретные примеры, что файлом не является. ну я уж не говорю про объекты без состояния, кои к файловому вводу-выводу вообще отношения не имеют.
и если пайпы можно посчитать за файловый ввод-вывод, то блокировки вы к нему как отнесете?
машину состояний ни разу не делали? ей хранение практически никогда ненужно. если нужно, то это уже процесс.
вы о чем? так что же имеется ввиду под "все"?
а в случае tls/ssl иостилами не обойтись. там хендлы сертификатов и ключей нужно хранить, состояние сервера и клиента. и еще кучу мутотени. и непонятно при чем здесь криптооперации, когда файловый ввод-вывод - это что получил, ровно то и отдал. а в криптооперациях даже длина может поменяться, не говоря уже о содержимом.
если все это реализовать через иостилы, то получится корова на бане. это вам говорит человек, который расковырял исходники openssl.
давайте еще раз резюмирую. даже если трактовать фразу "все есть файл" как "все состоит из файлов", а разница, согласитесь, есть, то это - все-равно не так.
файловый ввод вывод не поддерживает дуплексные операции. сокеты-поддерживают. ускорение в 2 раза не является причиной для перехода на дуплексный обмен вместо файлового?
stdin, stdout и stderror- это стрим, искусственно разбитый на 3 файловых хендла. был бы дуплекс, потребовался бы один хендл. в winapi, например, количество системных хедлов ограничено в районе 64к или менее на процесс. делить это число на 2 или 3 в реальных условиях не есть хорошо. именно по этой причине в delphi ушли от графических оконных хендлов в визуальных компонентах. то есть, скроллбар в окне винды имеет свой хендл субокна, а в delphi есть только хендл всего окна. скроллбар отрисовывается внутри основного окна. т.е. проблема количества хендлов не надумана мной.
виртуальная память ядра ни разу не является файловой операцией. даже по той причине, что она дробнее файла и действует на уровне страницы памяти. каждая страница, сгружаемая на диск не имеет своего имени файла. и то, что в той же винде оно хранится в своп-файле тоже ничего не означает. потому что этих файлов может быть несколько на разных дисках. где-то из драйвера виртуальной памяти все это дело пишется в некое место, условно зарезервированное за файлами свопа. файл свопа нужно организовать только затем, чтобы на это место никто ничего другого записать не мог. и заметьте, пишется своим способом, а не файловым вводом-выводом ос.
бд предоставляют альтернативный вариант организации хранилища, нежели файлы. т.е. можно выделить бд целый том и она будет его использовать своим образом. как-то много ранее я сравнивал производительность db2 с хранилищем из файлов и с хранилищем на томе. с разгромным счетом файлы проиграли.
в указанных случаях где тут файловый ввод-вывод? в 1-нет, во 2ом- 3 файла и программа ими управляющая, извините, это не чисто файл. в 3-ем опять нет файлового ввода-вывода.
и что же я придумал? от нас скрывают правду, Карл..
пример фантазии на эту тему я озвучил несколько выше в комментариях, не хочу повторяться. конечно, это не решает полностью проблему циклической записи, но облако поджимать видеоконтент может более качественно, чем ваша локальный видеорегистратор. а заодно распознавать лица и номера авто. а это означает, что вместо 2 недель записей у вас могут храниться 3 на тех же ресурсах. кроме того, проц на клиенте может быть слабее. уже интереснее. вся описанная мной схема сейчас может быть реализована только путем заказной разработки. подобных коробочных продуктов я не видел. хотя я не очень хорошо знаю возможности современных медиасерверов. это очень дорогая игрушка, чтобы в нее просто играться.
но тут дело, скорее, в концепции и программной архитектуре. вот недавно появился, а потом исчез коммент про стандартные консольные потоки stdin, stdout, stderror. прекрасная иллюстрация моей идеи. все три потока составляют один объект "консоль". Файловые дескрипторы, в отличие от тех же сокетов, не способны к дуплексной передаче данных. Иначе бы stdin и stdout реализовали на одном дескрипторе. Другими словами, вы не можете и читать из файла и писать туда одновременно. С точки зрения файла - это бессмысленно и труднореализуемо (блокировки). С точки зрения стрима - очень даже полезно.
Иными словами. стандартная консоль - это НЕ файл. Это 3 файла. И обьект управления над ними. Что и требовалось доказать.
нет, это архитектурно другой подход. в варианте с чистым стримом вы никогда eof не проверяете. просто послали в все. если хранилище не готово, оно вернет ошибку и клиент-программа может ее игнорировать, например. а то может, и вообще не вернет, как в случае с udp. там вообще соединений нет. послал и забыл.
клиент, формируя контент, хочет работать только с ним. т.е. х265 и сотоварищами. вы предлагаете такой клиент нагрузить работой по мониторингу и управлению файловыми ресурсами. Но если мы говорим о коммуникационных слоях, то зачем работу одного слоя перекладывать на другой, более высокий? Это как tcp попросило бы поуправлять своими соединениями верхний протокол http.
задача клиента - сформировать и отправить контент. облачный сервер же не просит поуправлять своими файлами клиента? Так почему же на одной машине вы это допускаете?
т.о. задача формирования и отправки контента должна лежать на медиасервере. а задача управления сохранением этого контента должна лежать на файловом/стримовом сервере. И здесь уже речь о хранении структурированного контента. ну, в теории, оба сервера могут располагаться на одной машине. и сейчас происходит сериализация структурированного контента в один файл. зачем? это оверхеды.
согласен, это лишь показывает, что ms давно уже готовится к переходу на стримы. но все вот что-то никак.
Однако! Командами командной строки обычные юзера не пользуются. Не все файл-менеджеры, включая проводник, поддерживают отображение файловых потоков. файловое winapi тоже стримы не видит, их там несколько. Плюс к тому же, здесь мы видим стрим как атрибут файла. И его содержимое предстоит разбирать каждой программе отдельно. Это не очень удобно, поскольку формат файла получается закрытым и никакой сторонний плеер не сможет проиграть видео из такого стрима. Только свой. И невозможно, какой-то стрим показать, а какой-то скрыть. Либо все, либо ничего. Ну так и живет.
Не все современные фс поддерживают понятие стрима. А unix так и вообще стрим выводит в коммуникационный протокол, хотя это давно уже не так: в rfc описывают не только контракт и протокол, но и последнее время начали описывать основы реализации - сервер ДОЛЖЕН или НЕ должен делать то-то, клиент в таких случаях делает -то-то.. Чисто коммуникационный протокол - это контракт +схема взаимодействия. все. А когда вам начинают расписывать состояния клиента и сервера, да еще по маршрутам (напр. в tls по варианту psk или без), то это что ни на есть уже реализация. Не протокол взаимодействия.
И если говорить про паттерны хранения(см. тут рядом в комментах), то у такого стрима (а точнее его дорожки хранения) должно быть api выбора конкретного объекта с этой дорожки. Например, дорожка стрима хранит аудиосэмплы. Должна быть возможность сказать: "а подайте мне вот тот сэмл с перламутровыми пуговицами". Или видео за номером 2. Такого в ntfs и винде сейчас нет. Но! есть подобная фича в структуре pe-файла, к которому можно привязать бинарные ресурсы. Однако, файл имеет конечную длину и размещен на внутреннем носителе. Переместите, скажем, на ftp/http- стримы потеряются.
Сейчас же для каждого аудиосэмпла игры придется делать свой стрим. Или свой файл. Или делать свою БД для этих целей.
Так что стримы ntfs - это лишь полшага. Над ним можно много чего надстроить. но хотелось бы это в виде стандарта в ОС. Тогда отпадет необходимость делать самописные файлы-бд для хранения ресурсов и контента. Это достаточно объемный кусок работы, надо сказать.
Ну и в итоге, не цель статьи была сказать как делать. Цель статьи - озвучить, что файл в настоящем виде исчерпал свой потенциал. Идея многодорожечного стрима дает гораздо больше интересных вариантов для хранения, передачи и главное - параллельной обработки данных.
с таким подходом вы систему с высоким уровнем надежности не сделаете.
Допустим, у вас ранее был веб-сервис на порту 80. Ныне это считается небезопасным, поскольку данные авторизации и sessionid передаются в открытом виде. И вы решаете приспособить к веб-сервису tls на 443 порту. а на 80 порт просто вешаете редирект на 443.
Что получается? Если ранее вы использовали oob, то теперь - никак. Это раз. И все упирается в концепцию файла-единого потока. К слову, медиасервисы реально открывают несколько соединений для своих нужд. Это я к тому, что их УЖЕ не устраивает концепция единого файла-потока.
И что делать, если ваша система высоко нагружена, а память исчерпалась? отказывать в запросе? я как раз и веду речь, что tls-у нет необходимости держать все поступившие запросы в памяти. Если их слишком много, то часть можно кешировать/сохранить на диск. Получается, что смысл хранения на диске для tls потока - временное кеширование.
Растить память на сервере бесконечно вы не сможете. Такой подход может быть выходом из ситуации. И рассматривать сетевые протоколы только как коммуникационные - это тоже устаревшая идея, имхо.
В качестве еще одного примера приведу http и загрузку по нему на сервер для хранения 10гб-ого видеофайла. Что делает сервер? Он тупо скидывает полученные пакеты в вируальную память, которая может системой сбрасываться на диск, при необходимости. Поскольку когда там придет еще последний кусок - не понятно, а ram нужна здесь и сейчас. И вот когда последний кусок получен и http увидел, что content-length у него сравнялся с фактически полученным, он отдает эту всю виртуальную память куда-то далее, возможно, кусками через ram.
Если вы попытаетесь этот весь файл разместить в ram на все время его получения, количество потенциальных пользователей вашего сервиса сократится до пары десятков при условии размера ram 200—300гб. и это не считается хорошим паттерном.
А http также считается коммуникационным протоколом, как и tls. А по tls идет примерно тот же объем данных, что и по http.
Надеюсь, пример показателен.
Поскольку вас вопрос вызвал интерес, давайте попробую дополнить некой фантазией, как могло бы быть в реальности.
Вот у меня есть смартфон, не дешевый. Но я заметил, что 4к видео он пишет не очень заморачиваясь на сжатие. Другими словами, я могу в видеоредакторе это видео подсжать еще раза в два. Правда, потратив какое-то время. Это совершенно точная информация, поскольку я иногда делаю и выкладываю видеоролики.
Допустим, примерно так же работают системы видеонаблюдения - пишут какой-то полусырой контент на диск, не особо утруждаясь его сжатием. это снижает требования к процессору.
Теперь, допустим мы имеем реализацию чистого стрима, т.е. отдаем данные на хранение, не заморачиваясь сколько там свободного места осталось. Что может делать механизм хранения? он пишет на свои hdd сколько может. Где-то при заполнении дисков, допустим, на 90% он параллельно отправляет самую старую часть данных в облако на временное хранение, т.о. высвобождая место на локальных hdd. т.е. концепция "подержи немного, скоро заберу". и так далее до окончания стрима. по окончании стрима он более тщательно запаковывает данные и возвращает из облака ранее отправленную туда часть. при этом, само облако может более качественно поджать эти данные. т.е. назад пойдет меньший обьем. и все уместится на локальный hdd.
замечу, при этом, все время работы стрима и после на локальном hdd присутствует схема хранения стрима и мы точно знаем, где какой кусок находится: часть у себя, часть- в облаке. если не смогли забрать все из облака по причине недостатка места на hdd, просто сигнализируем оператору. но в любом случае, медиасервер может работать с полным контентом отгребая его с hdd или из облака. и это уже проблема оператора проплатить облако на время, пока он не сможет перегнать контент в надежное хранилище целиком.
В итоге, мы имеем схему, где облако выступает буфером пиковой нагрузки при работе медиасервера. Как уже указал, облако можно привлекать не только для хранения, но и обработки данных: сжатия, распознавания номеров и лиц и.т.д. т.о. назад уже может вернуться структурированная информация.
Сейчас подобные реализации, может, и существуют. Но я о них не знаю. Это означает, что они если и есть, то не очень широко известны. И их владельцами могут быть какие-то частные конторы с непонятным будущим.
Более того, сейчас подобные схемы могут быть реализованы в медиасерверах. А они стоят ну очень дорого. Другими словами, вася пупкин не будет покупать такой медиасервер, чтобы сделать свой видеоредактор. Вот о том и речь, что хорошо бы в фс ос ввести хотя бы функции хранения такого контента. И здесь помогли бы существенно паттерны для хранения в стриме. Надо вам хранить видео с 4 дорожками - пожалуйста, открывайте стрим с паттерном таким. Надо вам хранить ресурсы видеоигры - паттерн такой. Нужно вам сохранить ресурсы web-сайта - патерн такой.
Сами паттерны могут определять количество дорожек хранения и их назначения. Например, для игры можно определить дорожку 3-д фигур, дорожку текстур, дорожку звуковых сэмплов и т.д. Сейчас каждый разработчик изобретает свой "велосипед".
начну с конца вашего ответа. тогда это будет решение конкретного разработчика. другая контора будет придумывать ровно такой же механизм. и все изобретают велосипеды.
момент второй. файл в ос ограничен по размеру. что делать с дескриптором файла, если в одном из ним закончится место? получается, нужен механизм открытия и закрытия файлов, а также определения свободного места в файле. этого всего можно избежать в концепции потока. аналогия - вы отдаете поток в облако и там оно хранит его в файлах на раиде. но для вас как клиента это поток, а не набор файлов. про файлы вы вообще ничего знать не будете. вы его отдаете, не заботясь о наличии свободного места, не заботясь об открытии новых файлов и ровно также забираете. и теперь альтернативный сценарий - с сервера ютуба, напр., вам идет видео, поделенное на файлы. очевидно, что плеер это все должен как-то собирать. это все оверхеды.
есть еще одно техническое отличие потока от файла. в ос блокировка ставится на файл целиком, а у потока - только на "дорожку" потока, т.е. условно на часть файла.
блокировка части файлов ранее реализовывалась той же ms, но не удачно. потом они вообще отказались от таких механизмов. а в стриме это будет возможно, поскольку дорожка хранения будет физически обособлена от других и связана с ними только логически. на уровне - если начали читать одну, то и вот эту тоже готовь в параллели.
неть. все есть несколько файловых дескрипторов, обьединенных каким-то одним объектом, в ваших терминах, в общем случае.
целью статьи как раз и было это показать. другими словами, можно было бы упрощенно сказать, что понятие потока данных расширяет несколько файлов. ну потому что удобно в разных дорожках потока/файлах передавать/хранить однородную информацию - или видео или аудио или телетекст. опять же, в фильме есть основное видео и есть бонусное видео. очевидно, что их лучше хранить раздельно для возможности быстрого доступа к обоим.
на dvd они так и хранятся отдельными "дорожками". я говорю о том, что пора бы такое хранение организовать на уровне фс в ос, а не только в cdfs.
вместе с тем, сведение работы с потоком к файловым операциям вынуждает отрывать функцию управления потоком и помещать ее в отдельную библиотеку. что приводит к все новым форматам потоков в файле. а можно было бы иметь один универсальный формат хранения на уровне ос. но наполнять его разным контентом. разницу чувствуете?
ну, api- это всего лишь фасад для механизмов. в принципе, ms реализовала его для вынь в виде com+ и idl-интерфейсов. универсальный апи для всего. это покрывает функции управления и передачи практически на любом уровне. они даже обьектную модель драйверов сделали на подобном механизме.
однако, он не затрагивает вопросы хранения. т.е. здесь еще важно как хранить. в свое время ms ушла от стандартного odbc драйвера к mssql в пользу oledb драйвера. знаете в чем основная разница? odbc хранит данные по записям, а oledb - по колонкам. Оказывается, хранение однородных данных в массивах устраняет оверхеды при хранении данных. По скорости работы разницы я не заметил, но сейчас best practices- это oledb.
т.е.инженеры ms посчитали важным иначе хранить и передавать данные. вот я здесь о том же, но уже для файлов.
а вообще статья была лишь призвана проиллюстрирована, что давно уже не все есть файл. надеюсь, примеров привел достаточно.
важными для целей статьи. не ерничайте. я знаю, что у файла есть еще имя и атрибуты создания. к данной теме они отношения не имеют. уже раз 5 написал, что чтение из одного файла разнородной информации приводит к необходимости создания структуры такого файла. а для машины - это оверхеды на запаковку и парсинг такой структуры. для разработчика - это все новые виды структур. а мог бы быть единый механизм хранения и передачи разнородного контента.
ps конкретно про tls. он сидит на tcp. если tcp тоже рассматривать как файловую операцию, то возникает такое понятие как oob данные (параллельный поток данных). сейчас этот костыль зарыт в tcp. и эти oob данные нужно еще как-то протащить через криптованные данные tls, где идет учет каждого пакета. т.е. просто как-то там вставить пакет внутрь tls потока не получится. т.о. oob пойдут либо в нешифрованном виде, либо шифровать их нужно как-то отдельно. а соответственно, возникает рядом еще один такой ssl. это все вынуждает не использовать oob, а как-то мудрить со структурой основного потока на более высоком уровне. любая новая структура - это оверхеды на ее создание и парсинг.