Здравствуйте, LaptevVV, Вы писали:
Pzz>>Ну и мой любимый вопрос, к какому уровню OSI относится тунелирование IP-трафика через HTTP? LVV>Стесняюсь спросить: и к какому ?
Вот мне и самому интересно. Вроде как это надстройка над прикладным протоколом, HTTP, с одной стороны. С другой стороны, торчит из него IP level, т.е., 3, довольно таки низкий.
Я это к тому, что академические модели, типа OSI, конечно дают полезную общепринятую терминологию. Но реальная жизнь не очень укладывается в эту красивую картинку.
Pzz>>А есть еще более интересные уровни. Например, "получить UID процесса, который приконнектился к нашему локальному серверу через loopback" — тут уж совсем системно-зависимые дебри. LVV>Вот. Приеду в Москву — можно об этом будет поговорить и обсудить. LVV>Мне надо же как-то сетевое программирование студням преподавать. LVV>На уровне Стивенса и сокетов — понятно. LVV>А потом начинаются разные варианты...
Второй год уже обещаешь понаехать в Москву. Я уж соскучался даже
...
K>Что бы кто там ни обсуждал, у Asio нет конкурентов, их просто реально нет, никто не готов взять на себя такую библиотку а вот обсуждают необходимость работы с сетью в С++ десятилетиями уже.
их вагон и маленькая тележка тех либ
весь гитхаб забит
даже фб свою написала, даже дуров свою написали итд, их килотонны
но все равно некие полухины из яндекса пилят свой userver в котором своя сетевая либа
вот это я реально понять не могу
LVV>>Вот. Приеду в Москву — можно об этом будет поговорить и обсудить. LVV>>Мне надо же как-то сетевое программирование студням преподавать. LVV>>На уровне Стивенса и сокетов — понятно. LVV>>А потом начинаются разные варианты... Pzz>Второй год уже обещаешь понаехать в Москву. Я уж соскучался даже
В 24 году была операция — пришлось отменить вообще все.
В 25 году — только в последнюю неделю удалось вырваться в Липецк и в Воронеж. 25 приехал, 29 уехал — никак в Москву не попадал.
В Воронеже обещались в декабре на конференцию позвать. Но пока телодвижений не сделали.
А я тут по самые помидоры занят и в вузе и не в вузе...
Еще у меня 31.01 — 12.02 отпуск. Если здоровье позволит — приеду.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Великий Мессия, Вы писали:
ВМ>- сеть не нужно
Сеть в стандартной библиотеке С++ не нужна так же, как там не был нужен XML, и так же, как там сейчас не нужны JSON/YAML/TOML и прочие популярные на данный момент технологии. Это все прекрасно обеспечивается внешними библиотеками.
А если в языке по его природе есть препятствия к тому, чтобы легко подключать в проект внешние библиотеки, то нужно устранять эти препятствия, а не пытаться затащить все в стандартную библиотеку.
Вот был бы C++ языком одной корпорации (как Java у Sun/Oracle, C# у Microsoft, Go у Google или даже Rust у Mozilla), чтобы была всего одна референсная реализация, тогда можно было бы рассматривать вариант "жирной" стандартной библиотеки у C++. Но не в условиях С++а, когда даже у той же Microsoft не хватает ресурсов на развитие VC++.
ВМ>- модули не нужны
Модули не нужны потому, что они вносят раскол в язык по типу того, что было в Python-е после выхода Python3. Раскол длиной в десятилетие, а то и больше. С сомнительными положительными последствиями, поскольку, на мой взгляд:
— сами по себе модули в C++ получились переусложненными. Такую заумную хрень еще нужно было придумать. Кто-то, видимо, очень старался. Причем эти "кто-то" вероятно, родились сильно после выхода Turbo Pascal 5.0, ибо если знать про систему unit-ов Turbo Pascal-я и предшествующих им модулей из Modula-2, то вряд ли бы у вменяемых людей поднялась рука предлагать хитровывернутые модули из C++20;
— внедряя модули отклонили идею "эпох"/"поколений" для C++. Чтобы в начале модуля можно было указать к какой "эпохе" относится код внутри модуля. Тем самым можно было бы наметить путь к постепенному отказу от самого одиозного наследия чистой Сишечки в C++. Например, внутри модулей в рамках, скажем, "эпохи 2025.01" можно было бы запретить неявные сужающие преобразования. И т.д., и т.п.
Т.е. мало того, что заложили свинью тем, что рано или поздно придется заниматься трансформацией легаси под модули, так еще и сами модули сделали такими, что без слез не взглянешь.
ВМ>- комитет занимается не тем чем надо
Люди ошибаются. Комитет состоит из людей. Значит и комитет может ошибаться. Чему уже были подтверждения в виде тех же export template.
ВМ>как вы только уживаетесь со своим Альтер его, которое на лоре рассказывает про то какой классный С++26
Судя по уровню вашего умственного развития, которое не позволило вам усвоить зачем нужны заглавные и строчные буквы, вы, скорее всего, просто не понимаете написанного. Ибо нигде я не рассказывал о том, какой классный C++26.
Здравствуйте, Великий Мессия, Вы писали:
ВМ>Здравствуйте, ksandro, Вы писали:
ВМ>...
K>>Что бы кто там ни обсуждал, у Asio нет конкурентов, их просто реально нет, никто не готов взять на себя такую библиотку а вот обсуждают необходимость работы с сетью в С++ десятилетиями уже.
ВМ>их вагон и маленькая тележка тех либ ВМ>весь гитхаб забит ВМ>даже фб свою написала, даже дуров свою написали итд, их килотонны
Все эти библиотеки делятся на 2 типа: 1) поделки, написанные с разной степенью профессионализма 2) большие фреймворки заточенные для довольно высокоуровневых задач (например для веб сервисов).
Asio это низкоуровневая оберертка над сокетами, и кроссплатформенные абстракции над асинхронным вводом/выводом. Я не знаю пока более менее популярных аналогов. Я бы очень хотел видеть конкурирующую профессионально написанную библиотеку, не поделку и не фреймворк. Возможно я просто не знаю современных тенденций, буду рад, если народ накидает мне тут ссылки на хорошие библиотеки, конкуренты Asio.
ВМ>но все равно некие полухины из яндекса пилят свой userver в котором своя сетевая либа ВМ>вот это я реально понять не могу
В том то и проблема, что сейчас часто проще написать свою библиотеку, для своих целей, Asio все-таки не слишком удобна.
К сожалению userver тяжелый и не кроссплатформенный фреймворк, работа с сетью в него вшита, если бы они выделили свою сетевую библиотеку в отдельный проект, а бы с удовльствием на нее взглянул, уверен, что там все сделанно очень профессионально. Но тянуть в прект весь Userver, если нужен простой TCP клиент, как-то нет желания.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Великий Мессия, Вы писали:
ВМ>>- сеть не нужно
S>Сеть в стандартной библиотеке С++ не нужна так же, как там не был нужен XML, и так же, как там сейчас не нужны JSON/YAML/TOML и прочие популярные на данный момент технологии. Это все прекрасно обеспечивается внешними библиотеками.
сеть не нужна
мутексы не нужны
треиды не нужны
контейнеры не нужны
строки не нужны
атомики не нужны
итд
есть куча внешний библиотек
тот же буст, ага
сеть нужна
ее просили как минимум в опросах комитета которые проходят каждый год
и выбор asio как интерфейса вполне очевиден
это единственная либа для работы сетью которая прожила столько времени
хотя свою славу я считаю она обрела именно будучи в бусте а не отдельно
но если рассматривать под вашим углом о не нужности
я бы предпочел о разделения стандарта на язык и его библиотеку
это помогло бы выходить стандарту библиотеки в два раза чаще стандарта языка
тогда сеть и экзекуторы можно было бы уже впихнуть в любой стандартную библиотеку
между С++23 и С++26
S>А если в языке по его природе есть препятствия к тому, чтобы легко подключать в проект внешние библиотеки, то нужно устранять эти препятствия, а не пытаться затащить все в стандартную библиотеку.
нужно удобное подключение уже существующих библиотек — ага
что бы каждый мог подключить свою шикарную реализацию строк
а при смене работодателя тратить время на изучения оной
да и вообще всех новых либ
S>Вот был бы C++ языком одной корпорации (как Java у Sun/Oracle, C# у Microsoft, Go у Google или даже Rust у Mozilla), чтобы была всего одна референсная реализация, тогда можно было бы рассматривать вариант "жирной" стандартной библиотеки у C++. Но не в условиях С++а, когда даже у той же Microsoft не хватает ресурсов на развитие VC++.
если так смотреть, то не только у MS не хватает ресурсов, или все же не в ресурсах дело
а возвращаясь к сказанному ранее, разрыв такта по времени, в выходе стандарта и его реализациях в компиляторах
ВМ>>- модули не нужны
S>Модули не нужны потому, что они вносят раскол в язык по типу того, что было в Python-е после выхода Python3. Раскол длиной в десятилетие, а то и больше. С сомнительными положительными последствиями, поскольку, на мой взгляд:
модули нужны на мой взгляд
и нужно было их внедрять Страуструпу еще на начальном этапе, вместе с рефлексией и концептами
тогда бы возможно не появился раст а ВандервудАлександреску не изобретал lang D
S>- сами по себе модули в C++ получились переусложненными. Такую заумную хрень еще нужно было придумать. Кто-то, видимо, очень старался. Причем эти "кто-то" вероятно, родились сильно после выхода Turbo Pascal 5.0, ибо если знать про систему unit-ов Turbo Pascal-я и предшествующих им модулей из Modula-2, то вряд ли бы у вменяемых людей поднялась рука предлагать хитровывернутые модули из C++20;
Вандервуд обкатал эту идею в своем lang D
и он был насколько я помню инициатором пропозла про модули
инициатором модулей был Вандервуд
S>- внедряя модули отклонили идею "эпох"/"поколений" для C++. Чтобы в начале модуля можно было указать к какой "эпохе" относится код внутри модуля. Тем самым можно было бы наметить путь к постепенному отказу от самого одиозного наследия чистой Сишечки в C++. Например, внутри модулей в рамках, скажем, "эпохи 2025.01" можно было бы запретить неявные сужающие преобразования. И т.д., и т.п.
в синтаксис модулей? это асбурд
модули не заменяют а дополняют, не нравится пишите без модулей
а то тогда и в обычные файлы нужна эпоха, что бы можно было отказываться от сишечки
S>Т.е. мало того, что заложили свинью тем, что рано или поздно придется заниматься трансформацией легаси под модули, так еще и сами модули сделали такими, что без слез не взглянешь.
тяжело консерваторам, понимаю
ВМ>>- комитет занимается не тем чем надо
S>Люди ошибаются. Комитет состоит из людей. Значит и комитет может ошибаться. Чему уже были подтверждения в виде тех же export template.
но почему вы только здесь решили об этом рассказать?
у обычных пользователей есть возможность если не влиять на развитие языка, то пытаться это делать
я пытаюсь, где то мимо, где как мне кажется получается/получилось
вот не смотря на то что мне не нравится ни сеть которую приняли, ни экзекуторы
это лучше чем ничего
ВМ>>как вы только уживаетесь со своим Альтер его, которое на лоре рассказывает про то какой классный С++26
S>Судя по уровню вашего умственного развития, которое не позволило вам усвоить зачем нужны заглавные и строчные буквы, вы, скорее всего, просто не понимаете написанного. Ибо нигде я не рассказывал о том, какой классный C++26.
возьмите в кавычки "классный С++26"
имелось ввиду что на лоре я не замечал от вас какой то критики по С++, скорее наоборот
а последние ваши ответы там были про С++26 и точно не о его критике
Здравствуйте, Великий Мессия, Вы писали:
S>>Сеть в стандартной библиотеке С++ не нужна так же, как там не был нужен XML, и так же, как там сейчас не нужны JSON/YAML/TOML и прочие популярные на данный момент технологии. Это все прекрасно обеспечивается внешними библиотеками.
ВМ>сеть не нужна ВМ>мутексы не нужны ВМ>треиды не нужны ВМ>контейнеры не нужны ВМ>строки не нужны ВМ>атомики не нужны
Великий Мессия тоже не нужен, из-за тупости.
В стандартной библиотеке должны быть т.н. vocabulary types, вроде строк, контейнеров, атомиков.
Но вот даже к тредам в стандартной библиотеке уже есть вопросы. Например, как ограничить размер стека для нового треда? Как менять приоритет для треда?
С++ -- это такой специфический язык, который сейчас нужен далеко не везде, а там, где он еще нужен, требуется контроль и, зачастую, прямая интеграция с возможностями конкретной платформы. Это уже даже на уровне std::thread видно. А в библиотеке для работы с сетью такой специфики будет еще больше.
Кроме того, для программирования на С++ нужны и другие вещи. Например, средства для работы с аргументами командной строки. Или средства для логирования. Или самые простые средства для криптографии (чтобы можно было хотя бы sha1 или sha512). И что, все это теперь тянуть в стандарт?
ВМ>сеть нужна
Далеко не всегда и далеко не всем.
ВМ>ее просили как минимум в опросах комитета которые проходят каждый год
В свое время очень многим был нужен XML.
А вообще, вспоминается (емнип) Генри Форд, который сказал: "Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь."
ВМ>нужно удобное подключение уже существующих библиотек — ага ВМ>что бы каждый мог подключить свою шикарную реализацию строк
В проекте у текущего заказчика, как бы это не было смешно, используется три типа обычных векторов: std::vector, folly::fbvector и еще один самописный, потому что стандартный не подошел под специфический сценарий.
Проект стартовал в 2024-го без какого-либо легаси, тем не менее в него по разным причинам пришлось затащить и другие типы векторов, и другие типы ассоциативных контейнеров, т.к. классы из stdlib не тянули в конкретных условиях.
Повторюсь, C++ -- это сейчас очень специфический язык. Если кому-то нужно наговнякать без оглядки на скорость/ресурсоемкость/предсказуемость, то есть куча более безопасных языков с жирными стандартными библиотеками.
ВМ>и нужно было их внедрять Страуструпу еще на начальном этапе
Да, это было единственное хорошее время, когда модули могли бы внедрить.
Но раз этого не сделали тогда, то сейчас это уже очень и очень неоднозначное решение.
От которого больше вреда, чем пользы.
ВМ>вместе с рефлексией и концептами
Ага, все это в 1985-ом году, когда Страуструп еще сам не знал как у него в языке будут шаблоны выглядеть.
ВМ>тогда бы возможно не появился раст а Вандервуд не изобретал lang D
Язык D изобрел Вальтер Брайт.
ВМ>Вандервуд обкатал эту идею в своем lang D
Насколько я помню, изначально было два предложения -- одно от Microsoft, второе от Google.
И делалось каждое предложение под то, кому как удобнее свои кодовые базы переводить под модули -- у Microsoft-а было свое представление о прекрасном, у Google -- свое.
А потом, когда в комитете ни одно из них не смогло победить, решили скрестить бульдога с носорогом.
S>>- внедряя модули отклонили идею "эпох"/"поколений" для C++. Чтобы в начале модуля можно было указать к какой "эпохе" относится код внутри модуля. Тем самым можно было бы наметить путь к постепенному отказу от самого одиозного наследия чистой Сишечки в C++. Например, внутри модулей в рамках, скажем, "эпохи 2025.01" можно было бы запретить неявные сужающие преобразования. И т.д., и т.п.
ВМ>в синтаксис модулей? это асбурд
Повторюсь, Великий Мессия -- идиот.
ВМ>модули не заменяют а дополняют
Модули вводят новый контекст, в котором код гарантированно будет соответстовать C++20.
Т.е. как только в исходнике появляется "шапка" с ключевым словом "module", так сразу становится понятно, что код ниже адаптирован под C++20.
Что принципиально отличает модули от произвольных .hpp/cpp-файлов, в которых может быть код еще до C++98 времен.
А раз так, то можно в декларацию модуля тем или иным образом добавить "эпоху".
Это дело, емнип, даже комитетом обсуждалось. Но, к сожалению, не было принято. Экзекуторы же и сеть нужнее, ага.
ВМ>не нравится пишите без модулей
Так и делаю. И планирую в продолжать в ближайшие пару лет.
ВМ>а то тогда и в обычные файлы нужна эпоха, что бы можно было отказываться от сишечки
В обычные файлы это добавлять сложнее.
S>>Т.е. мало того, что заложили свинью тем, что рано или поздно придется заниматься трансформацией легаси под модули, так еще и сами модули сделали такими, что без слез не взглянешь.
ВМ>тяжело консерваторам, понимаю
Не понимаете. И не консерваторам, а тем, кто не любит искуственной сложности на ровном месте.
ВМ>но почему вы только здесь решили об этом рассказать?
Я об этом рассказываю везде (например).
ВМ>вот не смотря на то что мне не нравится ни сеть которую приняли, ни экзекуторы ВМ>это лучше чем ничего
А у меня обратная точка зрения: чем говно, да еще в говняной упаковке (это я сейчас в первую очередь про модули), так лучше ничего.
ВМ>возьмите в кавычки "классный С++26"
Как и ожидалось, никаких рассказов про "классный C++26" не было.
ВМ>имелось ввиду что на лоре я не замечал от вас какой то критики по С++, скорее наоборот ВМ>а последние ваши ответы там были про С++26 и точно не о его критике
В C++ много хорошего. Например, концепты и operator<=>. За это комитету огромное спасибо.
А если кто-то чего-то про C++ не знает, или не понимает, то почему бы не поделиться своими скудными знаниями.
Или развенчать какие-то мифы.
Но если мне кажется, что комитет подкладывает свинью, то не вижу смысла делать вид, что это божья роса.
как я говорил, строить лесенки в темах не люблю
не используйте модули
они вам явно не подходят
продолжайте дальше восхвалять С++
что бы со стороны не казалось что у вас раздвоение личности
адью в этой теме
Здравствуйте, Pzz, Вы писали:
Pzz>Вот мне и самому интересно. Вроде как это надстройка над прикладным протоколом, HTTP, с одной стороны. С другой стороны, торчит из него IP level, т.е., 3, довольно таки низкий. Pzz>Я это к тому, что академические модели, типа OSI, конечно дают полезную общепринятую терминологию. Но реальная жизнь не очень укладывается в эту красивую картинку.
Ой блин.
Вот тот же МЭКовский баян, у которого внтури ISO 9506.
Там вот прямо все 7 уровней. И session и presentation и прочия.
Только вот работает оно в примерно 100% инсталляций, будучи завернутым в TCP/IP, и вся эта требуха просто сидит мертвым грузом внутри пакетов и жрет ресурсы.
Здравствуйте, LaptevVV, Вы писали:
BFE>>Если есть стандарт POSIX, то почему не сделать PONIX — Portable Operating Network Interface? BFE>>Прописать отдельный стандарт на сетевое взаимодействие, а уж на его основе писать библиотеку. LVV>Ну, есть же модель OSI LVV>Там есть tcp/ip и udp
В модели OSI нет ни TCP, ни TCP/IP, ни UDP. Если про строгую OSI, то там свои протоколы чуть более чем полностью.
Ну да, текущие сети реюзают L1-L2, как IEEE802, и то с особенностями. Например, честный IEEE802.2 требует, чтобы была длина пакета, а в текущих IP сетях там не длина, а тип (0x0800 — IPv4, 0x0806 — ARP, 0x86ED — IPv6), это называется Ethernet II, а не IEEE802.2. Но все привыкли. SAP/SNAP навороты над этим уровнем давно забыты.
Если говорить про модель OSI как учебную модель для первичного понимания, то да, в этом смысле она продолжает быть полезной. Рассказать про 7 уровней и связи между ними, а после этого вводить в реальный мир, где, например, повторения последовательностей с инверсией между ними — в случае туннелирования любого вида (хоть GRE, хоть WireGuard, хоть HTTPS).
Разницу в верхних уровнях мало кто понимает. Например, вики пишет, что HTTP это уровень 7, хотя основная нагрузка у него на уровне 5 (сеансовом). Ну при том, что в TCP/IP это всё один уровень I, это мало кого волнует.
В протоколах OSI есть некоторое количество полезностей, которые не перешли в TCP/IP. Например, там изначально вместо TCP был аналог SCTP с делением на сообщения, что помогало от типовых индусских проблем "один send — один recv". Но сейчас и это маловажно, даже в IoT переползают на фрейминг HTTP/DTLS/QUIC/etc.
LVV>И фактический стандарт — сокеты. LVV>Я не в курсе — сокеты в nix-системах стандартизированы официально ? LVV>На уровне API Linux — фактически да.
На это я уже отвечал ссылкой на POSIX.
К сожалению, много важных расширенных возможностей туда не попали. Но их и так используют единицы процентов от всего софта.
