Pull to refresh

Comments 26

"Какие же вы счастливые" - подумал я, подключая libuv.

необычный формат)

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

Это они ещё интерфейсы не посчитали (можно слушать на интерфейсе), что становится особо интересно после переименования интерфейсов.

listen_app -i eth0
ip link set name foo dev eth0
ip link add type veth name eth0
ip link set up dev veth0
listen_app -i eth0

Два приложения слушают eth0, но это разные eth0!

В целом, статья выглядит как попытка "вскочить в вопрос" не прочитав man по сокетам.

Немного оффтоп: не подскажете ли, что стоит прочесть про сокеты и порты чисто техническое? Что обычно рекомендуют? Достаточно краткое, при этом внятное.

И без лирических героев.

man 2 socket

Дальше там:

SEE ALSO

   “An Introductory 4.3BSD Interprocess Communication Tutorial”  and  “BSD
   Interprocess  Communication  Tutorial”,  reprinted in UNIX Programmer's
   Supplementary Documents Volume 1.

Обоих довольно много для понимания. Ещё есть man 7 socket.

Спасибо:)

Попробовала для начала вчитаться в ман 2.

... верно ли я понимаю, что речь реально про линукс, а это вот всё на питоне - только к нему оболочка? А что тогда происходит в винде? То же, что в линуксе? Ну, я списала эти вот два первых отрывка (ещё пока читала статью) "сервер 1" и "сервер 2" к себе на виндуДомашюю, на питон. Запустила, банально в Idle. И моя Idle начала слушать не пойми что (в смысле что ожидала ввода, не реагировала на Ctrl+C, хуже того - в процессах на Ctrl+Alt+Del не значилось ничего отдельного, только открытый браузер да тот самый питон).

Куда же вот это вот всё направилось на винде?

Есть ядро (the kernel), которое предоставляет набор системных вызовов для работы с сокетами. Поверх есть libc, которая на 90% враппер поверх ядра, плюс небольшой фэнсервис. Поверх уже python (и его библиотеки), которые этот "фэнсервис" используют.

Т.е. реальную работу делает ядро, libc приглаживает углы и разницу в версиях а python и его библиотеки используют.

Теоретически можно себе представить альтернативный сетевой стек в userspace (dpdk, rdma, etc), но это крайняя экзотика.

Сокет - это абстракция операционной системы по взаимодействию процессов по сети (AF_INET) или локально (AF_UNIX).

В windows аналогично, хотя точная связь ядро (a kernel) и его библиотек (всякие winapi и т.д.) различается.

Все разработчики ОС ориентируются на упомянутую "BSD Interprocess Communication Tutorial", хотя и докидывают всякие фичи/несовместимости.

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

Вот и пришло то время, когда молодёжь стала изучать систему "методом чёрного ящика", то есть заранее не имея представления, как она там, под капотом, работает. Наверно, уже надо сказать спасибо, что хоть начала изучать...

Всю статью ждал какого-то откровения, которого я не знал. Не дождался, чуда не случилось.

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

Пока разбираешься что такое сокет, люди давным давно зарабатывают, просто склепав сайтик на cms

... а потом их сайтик взломал Вася-хакер из 5-го "Б", потому что ему было не лень разобраться, что админский интерфейс, оказывается, можно закрыть паролем!

Они до этой строчки в документации не дочитали — некогда было.

Напротив, мейнстримная CMS с настройками по умолчанию может быть понадёжнее самописного новичком сервера на сокетах?..

Тут палка о двух концах. Для таргетированной атаки - да. Но если в мейнстримной CMS найдут уязвимость, то в зоне риска окажутся даже те, кого вряд ли кто-то стал бы взламывать целеноправленно.

На самом деле умение изучать систему как черный ящик довольно полезное. Не у всего есть хорошая, актуальная документация, как у api сокетов.

Нет, умение изучать систему как чёрный ящик довольно полезное, тут я не спорю. Но умение RTFM тоже не самое последнее по пользе, и обычно приводит к искомому результату несколько быстрее.

Правда это не такой увлекательный путь.

Думается, что на каком-то уровне (для каждого специалиста на своём) "капот" всё-же остаётся всегда закрытым.

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

К большинству же современного софта никакие RFC не предлагаются.

А я вот не знаю. uucp учитывать или нет?

Откройте Ваш sendmail.cf и почитайте. Всё поймёте (конечно, не сразу).

почему статьи с хакер ньюс оказываются здесь? я их на хакер ньюс читал в оригинале ))

UFO just landed and posted this here

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

Просто программист - понятие обширное. Под разные задачи и специализации.

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

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

А про "дохренадолларов": с больным зубом, я, скорее, заплачу среднему стоматологу, чем гениальному проктологу. Потому что решению моих проблем набор навыков среднего стоматолога отвечает несколько больше...

Sign up to leave a comment.

Articles