Комментарии 19
Интересно, много ли приложений прямо используют протокол IP?
Везде где нужно быстро и много отправить, при этом небольшое число ошибок или не влияет или можно исправить последующими запросами.
Еще для приложений реального времени.
Еще для приложений реального времени.
Везде где нужно быстро и много отправить, при этом небольшое число ошибок или не влияет или можно исправить последующими запросами.
Для таких приложений используется связка UDP/IP. Напрямую на уровне IP — мне кажется, что нигде.
Вот и мне всегда казалось, что IP протокол всего лишь базовый контейнер, на котором строятся прочие более умные и красивые протоколы.
Простые приборы на FPGA, да и UDP не сильно высокого уровня протокол.
UDP ровно той же «высоты» что и TCP, пусть и не гарантирует доставку (на уровень это никак не влияет).
Поскольку модель OSI сама кривая — в зависимости от т.з. UDP надо поместить на третий или на четвёртый уровень модели. А TCP — всегда на четвёртом. Ибо по определению — четвёртый уровень должен обеспечивать надёжную доставку.
И тут внезапно выясняются, что ограничения на размер UDP пакета приплыли откуда? Правильно, из IP.
Особого смысла в raw IP, по-моему, нет. Если сильно приспичило с упрощением, то лучше уж сразу raw Ethernet frames.
Взято отсюда: man7.org/linux/man-pages/man7/ip.7.html
Нет порта — нет стандартной поддержки под Linux. Нет стандартной поддержки — лепи своё творение со своим уникальным стеком на коленке.
Note that the raw IPv4 protocol as such has no concept of a port, they are implemented only by higher protocols like tcp(7) and udp(7).
Взято отсюда: man7.org/linux/man-pages/man7/ip.7.html
Нет порта — нет стандартной поддержки под Linux. Нет стандартной поддержки — лепи своё творение со своим уникальным стеком на коленке.
Из закона дырявых абстракций следует, что абстракции не упрощают нашу жизнь настолько, насколько нам хотелось бы
Почему это — следует?
Это неоткуда и не следует. А само существование и широкое распостранение абстракций как раз подтверждает ровно обратное. Гипотеза о существовании некой идеальной концепции, которая одновременно и «упрощает нашу жизнь» и в то же время «не протекает» — и есть, самая, что ни на есть — «дырявая абстракция» :)
Порой понимаю Никиту Хрущева, который позорил художников-абстракционистов
Разве IP у нас не 3 уровень, и не декларирует адресацию, и правила передачи информации между точками?
«Закон дырявых абстракций» — это попытка «натянуть сову на глобус» :)
Тут «текут» не абстракции, а «мозги»:) Иерархическое устройство мира подразумевает, что любой уровень иерархии зависит от предыдущих по определению. А поскольку, любой элемент имеет всегда собственную степень свободы, то это неизбежно сказывается на всех уровнях иерархии.
То, что автор называет брезгливо «дырявые абстракции» — по сути, просто отражение естественного устройства мира, описываемого "законом иерерхических компенсаций". Это просто цена, которую приходится платить за простосту сложных систем.
Именно это я и называю дырявыми абстракциями.
Тут «текут» не абстракции, а «мозги»:) Иерархическое устройство мира подразумевает, что любой уровень иерархии зависит от предыдущих по определению. А поскольку, любой элемент имеет всегда собственную степень свободы, то это неизбежно сказывается на всех уровнях иерархии.
То, что автор называет брезгливо «дырявые абстракции» — по сути, просто отражение естественного устройства мира, описываемого "законом иерерхических компенсаций". Это просто цена, которую приходится платить за простосту сложных систем.
Автор говорит о конкретной проблеме и эта проблема существует: получив новый инструмент программист должен увидеть дырявые абстракции (иначе он захочет нечто такое чего инструмент не может и начнет мучаться). Можно зайти с другой стороны: создвая новый инструмент сконцентрироваться на тех пользователях которые понимают как инструмент работает, потому что объяснять тем кто не понимает устройство «низких уровней» — неподъемный труд.
В этом смысле, вы правы и такая проблема действительно существует. Вы же её и очень хорошо сформулировали: «он захочет нечто такое чего инструмент не может»
И вот тут я как раз и сделал акцент, что проблема не в абстракциях как таковых — с ними как раз всё в порядке. А проблема в наших ожиданиях от них. Увеличивая степень абстрактности систем, в своём собственном их восприятии, мы зачастую рискуем всё ещё оставаться на нижележащих уровнях, и глядя на условный «абстрактный файл», который по факту какой-нибудь сетевой, хотеть от него того же, что и от файла локального.
Поэтому для программиста, получившего новый инструмент, я бы предложил начать с ознакомления с границами его применимости.
Но, в принципе, и, судя по всему, мы говорим об одном и том же.
И вот тут я как раз и сделал акцент, что проблема не в абстракциях как таковых — с ними как раз всё в порядке. А проблема в наших ожиданиях от них. Увеличивая степень абстрактности систем, в своём собственном их восприятии, мы зачастую рискуем всё ещё оставаться на нижележащих уровнях, и глядя на условный «абстрактный файл», который по факту какой-нибудь сетевой, хотеть от него того же, что и от файла локального.
Поэтому для программиста, получившего новый инструмент, я бы предложил начать с ознакомления с границами его применимости.
Но, в принципе, и, судя по всему, мы говорим об одном и том же.
Перевод этой и многих других статей существует уже много лет на local.joelonsoftware.com/wiki.
Сайт почему-то недоступен, ссылка на архив.
Сайт почему-то недоступен, ссылка на архив.
Здесь главное не перегибать фанатично. То, что абстракции иногда текут — не повод отказываться от абстракций вообще всегда.
Только что прочитал эту прекрасную статью в оригинале и захотел выложить перевод на хабр, а он тут уже есть!) Спасибо замечательной компании Selectel за качественный контент!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Закон дырявых абстракций