С помощью ascii из твоих красивых буковок получаются цифровые коды

и в обратную сторону тоже. впрочем, совсем необязательно (например, подумайте, как передаются бинарные данные в HTTP). ascii - это не протокол, это таблица перекодировки, причем лишь некоторых частей ответа.

6 уровень - это упаковка того, что ты хочешь передать, в набор байт, который нужно отдать второй стороне

любой уровень, кроме физического - это упаковка того что ты хочешь передать в набор байт, который нужно отдать второй стороне.

смотри, на 7 уровне у тебя приложение. Допустим, ООП-приложение. У тебя экземпляр класса, т.е. объект. Оно логично, что передать его "как есть", да еще и чтобы оно было понято другой стороной - задача весьма нетривиальная и даже, местами, неразрешимая.

Для этого нужен 6-й уровень. Ты упаковываешь свой объект в последовательность байт, которые, будучи прочтитаны "как есть", смогут быть поняты другой стороной.

а, то есть JSON-сериализация объектов, которая работает поверх HTTP, на самом деле шестой уровень?

На 5-м ты устанавливаешь сеанс связи и "кидаешь" в него свою последовательность байт.

На 5-м ты устанавливаешь сеанс связи и "кидаешь" в него свою последовательность байт.

почему не на четвертом? там ты устанавливаешь сессию и кидаешь в него свою последовательность байт.

Как, какой сеанс, какими средствами, как реализовано на уровне сети - это вопрос к нижележащим уровням. Тебя, как разработчика, особо не волнует.

Как, какой сеанс, какими средствами, как реализовано на уровне сети - это вопрос к нижележащим уровням. Тебя, как разработчика, особо не волнует.

на tcp - тоже.

почему не на четвертом? там ты устанавливаешь сессию и кидаешь в него свою последовательность байт.

Не, сессия - уже следующий этап. У тебя, как разработчика прикладного ПО есть опять же экземпляр класса, который, условно, "умеет работать с сетью".

Тебя не должно заморачивать, КАК он это делает.

Не, сессия - уже следующий этап. У тебя, как разработчика прикладного ПО есть опять же экземпляр класса, который, условно, "умеет работать с сетью".

ну вот у тебя курл и нджинкс. где между ними пятый и шестой уровень?

ну вот у тебя курл и нджинкс. где между ними пятый и шестой уровень?

внутри курла и нджинкса

и что же это такое? :)

детали реализации курла и нджинкса, естественно. Т.е. curllib, например

какие детали? какие преобразования происходят между tcp-потоком и http-запросами и ответами и в обратную сторону? преобразования в виде "читать из сокета байты, раскодировать их по ASCII до тех пор пока не встретится \n\n, разделяя на токены по \n и разделяя получившиеся токены по ": ", потом читать еще Content-Length байт, потом закрыть сокет (примитивно) - это преобразование между TCP и HTTP сразу. где промежуточные уровни?

ты же понимаешь, что "прочитать тесктовый поток, считая <teg> началом тега, </teg> - его концом, а <teg/> - комбинацией этих символов, распарсить построчно и по предопределенным правилам получить DOM-модель в памяти браузера" - это нескольно сложнее?

ты же понимаешь, что "прочитать тесктовый поток, считая <teg> началом тега, </teg> - его концом, а <teg/> - комбинацией этих символов, распарсить построчно и по предопределенным правилам получить DOM-модель в памяти браузера" - это нескольно сложнее?

HTML-верстка теперь является протоколом передачи данных?

HTML-верстка теперь является протоколом передачи данных?

Вообще говоря всегда являлась

HTTP про HTML вообще ничего не говорит

http теперь является "протоколом передачи гипертекста"

смотри, можно считать сетевой моделью только то, что происходит между нодами сети - ты имеешь на это право и можешь тупо игнорировать верхние три уровня OSI в своей модели мироздания. В самой же модели то, что происходит внутри самих нод - это тоже часть сетевого взаимодействия. Это можно принимать, можно отторгать, можно игнорировать - это мало кого волнует. Особенно не волнует саму модель, она модель, ей чувства неведомы.

Сами разработчики говорят, что модель не идеальна, есть исключения на практике, их многие критикуют.

Но при этом модель есть, и она - весьма неплохая рекомендация.

HTML между тем (даже если посчитать ее за протокол передачи данных, хотя это требует насилия над мозгом) работает поверх HTTP, поэтому быть на 5/6 уровнях не может никак. а 8-го уровня не предусмотрено.

Oh, I got it

Причем рекомендация не только для системных администраторов (собственно, для них важны только нижние 4 уровня), но и для разработчиков.

не передачи, кодирования, конечно

Вот этим самые три верхних уровня придуманы для того, чтобы эти самые разработчики вообще не грели голову о том, что происходит на нижних четырех.

Вот этим самые три верхних уровня придуманы для того, чтобы эти самые разработчики вообще не грели голову о том, что происходит на нижних четырех.

только получилась дырявая абстракция.

Можешь воспринимать верхние 3 уровня как психологический блок для неокрепших умов разработчиков.

только получилась дырявая абстракция.

1. Получилась хотя бы какая-то. 2. Пригодилась миллионам софтописателей. 3. Отхождений от модели - единицы.

и, к слову, в чем именно "дырявость"?

дырявая - это же если "течет"?

http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html

ну т.е. да, если течет.

Вот смотри, пример.

и, к слову, в чем именно "дырявость"?

дырявая в том смысле, что писать сетевые приложения, не думая о том, как устроены уровни ниже седьмого можно только в мире розовых пони.

дырявая в том смысле, что писать сетевые приложения, не думая о том, как устроены уровни ниже седьмого можно только в мире розовых пони.

Ну вот неправда ваша же

Отлаживать - да, нереально. Писать -то что мешает?

да, моя ошибка в формулировке. отлаживать тоже реально, кстати, какая проблема-то. заставить работать - почти невозможно.

Ну вот смотри, допустим, я пишу чат-клиента для существующего чат-сервера.

минутку, вы мне что хотите доказать? :)

Я хочу доказать, что в подавляющем числе случаев абстракция не течет)

бОльшая часть прикладных сетевых библиотек работают по одной и той же схеме, которая построена именно на абстракции верхних 3 уровней.

Я хочу доказать, что в подавляющем числе случаев абстракция не течет)

на уровне пользователя абстракция не течет, потому что разработчик учел текучесть абстракции в работе. браузер работает с серверами мягко и легко, да. думать о сети между ними обычному человеку вообще не надо. только во что это вышло разработчику браузера и сервера?

хотя абстракция TCP довольно стойкая, говорит, что передает данные, и даже не теряет их.

Смысл всех этих уровней в том, чтобы дать возможность разработчику каждого надлежащего уровня не заморачиваться деталями более чем одного нижележащего

Смысл всех этих уровней в том, чтобы дать возможность разработчику каждого надлежащего уровня не заморачиваться деталями более чем одного нижележащего

и это не получается. я лично патчил хадуп для защиты от коллизий TCP.

хотя в большОм количестве случаев можно не париться.

вот и я о том же

конечный разработчик приложения, если это приложение не сетевой кластер или что-то совсем уж специфичное, может вообще не париться по поводу работы с сетью. У него есть библиотека, а в ней 3 сущности: "Подключение", "Запрос", "Ответ"

Вот это и результат верхних 3 уровней OSI.

Подключение - 5-й уровень, запрос и ответ - 6-й.

7-й называется "Дальше сам, малыш"

конечный разработчик приложения, если это приложение не сетевой кластер или что-то совсем уж специфичное, может вообще не париться по поводу работы с сетью. У него есть библиотека, а в ней 3 сущности: "Подключение", "Запрос", "Ответ"

а потом "ой, надо таймауты вкручивать", "ой, надо хартбиты вкручивать", "ой, у меня тут окно схлопнулось, поэтому транзакции не шли..."

Подключение - 5-й уровень, запрос и ответ - 6-й.

тем не менее, все авторитетные источники ставят HTTP на седьмой уровень. хотя логически можно сказать, что он съехал вниз.

а потом "ой, надо таймауты вкручивать", "ой, надо хартбиты вкручивать", "ой, у меня тут окно схлопнулось, поэтому транзакции не шли..."

Это уже следующий этап. Для вхождения модель - самое оно. Если у тебя возникла реальная необходимость отойти от OSI, логично предположить, что ты уже сам, в принципе, понимаешь, что делаешь.

При этом эти уровни, на самом деле, могут и облегчить отладку.

В простейшем случае:

Если до сервера не идут сообщения вообще - пинай разработчика 5-го уровня. Если половина дропается - дай с левой разрабу с 6-го.

Вот если уже совсем-совсем никто не понимает, что происходит - позовите админа, он починит...

За 20+ лет в мире админства и разработки софта - OSI модель была самая не пригодившаяся в жизни теория.

При этом эти уровни, на самом деле, могут и облегчить отладку.

всплеск таймаутов записи в кластере. ноки, у вас что-то случилось? нет, у нас все хорошо. не сказал бы, что это очень облегчает отладку (: может быть, знаешь чего ждать, что ли.

За 20+ лет в мире админства и разработки софта - OSI модель была самая не пригодившаяся в жизни теория.

Фактически, эта модель - тупо джентльменское соглашение, не более того.

Фактически, эта модель - тупо джентльменское соглашение, не более того.

не. джентльменское соглашение - это каждый из протоколов в ней. а модель - это абстракция вокруг, чтобы обозвать это все общими словами.

ERROR: S client not available

всплеск таймаутов записи в кластере. ноки, у вас что-то случилось? нет, у нас все хорошо. не сказал бы, что это очень облегчает отладку (: может быть, знаешь чего ждать, что ли.

ну, собственно, верхние три уровня - рекомендация. Читается так: "Ребят, фунцкциональность по установлению соединений и прочей низкоуровневой поебени выностите в отдельную сущность. Принятые протоколы - в отдельную. Делите уж как-то, уебки, а то заебло разбирать, что вы там fprint'ом в сокет из main'а ебашите"

Причём OSI модель к fprint из main'a?

не. джентльменское соглашение - это каждый из протоколов в ней. а модель - это абстракция вокруг, чтобы обозвать это все общими словами.

протоколы - это джентльменское соглашение между разработчиками в одной области. OSI - джентльменское соглашение вообще между всеми "сопричастными". Отхождение от него надо "обосновать"

OSI это не соглашение. Это абстрактная модель сложившейся имплементации.

Причём OSI модель к fprint из main'a?

при том, что модель OSI рекомендует функционал работы с низкоуровневыми сетевыми протоколами выносить за абстракцию и потом работать с ней.

OSI это не соглашение. Это абстрактная модель сложившейся имплементации.

Во, тут соглашусь

Потому как в текущей ситуации сделать как-то по-другому просто не получится :)

почему не получится? Всегда есть вариант "мы тут что-то сделали, и оно как-то работает"

Ну тогда надо начинать с новых стандартов для физических сетей :)

Только не это, плиззз.

А вообще, зря вы так на OSI - нормальная модель. Там вам и драма, и распределение обязанностей, и зарплатная вилка включена

Вы думаете, номера уровней просто так придуманы?

Это делитель зарплаты.

Вы думаете, номера уровней просто так придуманы?

грейды небось?

а регрейдирование с учетом инфляции?

Ну, нюансы реализации есть, идеальных реализаций не существует.

А так... Модель прямо говорит, что человек, понимающий, что просиходит "вот в этой коробочке" и способный собрать такую же на коленке из подручных средств, должен получать, в вреднем, в 7 раз больше, чем тот, кто чат-клиента пишет.

Я тоже хочу такой наркоты.

почитал тред, вы дальше заголовка OSI не читали?

Во-во :)

почитал тред, вы дальше заголовка OSI не читали?

Зачем, если есть картинки?)

А так... Модель прямо говорит, что человек, понимающий, что просиходит "вот в этой коробочке" и способный собрать такую же на коленке из подручных средств, должен получать, в вреднем, в 7 раз больше, чем тот, кто чат-клиента пишет.

7*0=0?

я говорил про 0/7

"в 7 раз больше" это умножение :)

Тот кто пишет чат клиент очевидно студент и не получает ничего

"в 7 раз больше" это умножение :)

я про то, что берем "желаемую зарплату" и делим на уровень OSI, которым владеет соискатель

я про то, что берем "желаемую зарплату" и делим на уровень OSI, которым владеет соискатель

тогда монтажники озолотятся?

т.е. писатели чат-клиентов - это 7 уровень, он получит желаемое, деленное на 7

я про то, что берем "желаемую зарплату" и делим на уровень OSI, которым владеет соискатель

ну да) монтажники еще меньше)

а между тем написать телеграм, не так уж и легко.

тогда монтажники озолотятся?

монтажники действительно знают, как это работает, а не просто цвета жил различают? Тогда пусть озолотятся

я про то, что берем "желаемую зарплату" и делим на уровень OSI, которым владеет соискатель

На 0?