Pzz>Там есть еще OOB — кажется, это единствнный TCP-based протокол с OOB.
У меня точно не было. Возможно есть отдельная опция под это, но на нее как раз можно и отказ послать.
КА, кстати, в сетевом аспекте очень полезная штука. На них по сути то все и держится. А современные программисты начинают сразу ентерпрайз дичь писать при их виде.
Здравствуйте, Pzz, Вы писали:
M>>А, ну так-то да. Но это не совсем таки HTTP 0.9, заголовки-то и в нём были. M>>И взад получаешь скорее всего не двоичный файл, навскидку сейчас не скажу, но скорее всего base64
Pzz>Неа.
Pzz>https://http.dev/0.9
Да, действительно, проще некуда. Я наверное спутал HTTP/1.0 и HTTP/1.1. Но HTTP 0.9 предполагает передачу только html файлов, а не абы каких.
Pzz>>>В принципе, да. Но большинство практическеских сетей предпочитает прикидываться Ethernet-ом. Мне из исключений приходит в голову только PPP и SLIP...
M>>Тем не менее, локалку можно на TokenRing или ArcNet сделать, связь с аплинком — точка-точка — и всё, никаких MAC, а и Internet сделать можно
Pzz>У токенринга тоже MAC-адреса, в стиле Ethernet. У ArcNet-а не знаю.
Ну да, возможно. Но ничего не мешает сделать аналог TokenRing, который оперирует не MAC-адресами, а IP-адресами.
А вообще, у IBM TokenRing физически комп подключался к концентратору одним кабелем, и всё, и кольцо там уже реализовывалось, унутре. Т.е. снаружи видится как точка-точка со звездообразным коммутатором.
В общем, можно сделать звездообразный интернет без всяких MAC-ов.
M>>Интересный вопрос. Я не знаю ответа Тем более, так чтобы прям событие. Теоретически, наверное можно глянуть через IOCTL, осталось ли что-то в буфере на отправку, но не уверен, что это хороший способ
Pzz>При чем тут IOCTL? Как сетевой стек решает, когда очередной пакет послать?
Ошибся, не IOCTL, а getsockopt c SOL_SOCKET. Думал, есть опция узнать сколько места, но есть только ф-я узнать размер буфера — SO_SNDBUF
Здравствуйте, Marty, Вы писали:
Pzz>>https://http.dev/0.9
M>Да, действительно, проще некуда. Я наверное спутал HTTP/1.0 и HTTP/1.1. Но HTTP 0.9 предполагает передачу только html файлов, а не абы каких.
Ему всё равно.
M>Ну да, возможно. Но ничего не мешает сделать аналог TokenRing, который оперирует не MAC-адресами, а IP-адресами.
Даже и в Ethernet можно IP-адрес вместо младших 4-х байт адреса затолкать. Только так обычно не делают.
Здравствуйте, Marty, Вы писали:
LVV>>В новой книжке, ссыль на которую я давал в первом посте, написано, что названия функций не совпадают. LVV>>И вообще ioctl и fnctl отсутствуют.
M>По моему, это единственное отличие. ioctl называется ioctlsocket.
Заметная разница начинается, когда хочется, например, мультикастинга. Между вариантами UNIX, кстати, тоже.
Здравствуйте, LaptevVV, Вы писали:
LVV>Чего-то в сетевом форуме мой вопрос никто тне прочитал. LVV>Повторяю здесь
LVV>Случился тут форс-мажор — некому преподавать LVV>Дали мне. LVV>Я в этом деле практически полный чайник. LVV>Поэтому обращаюсь к народу за помощью.
LVV>Пара книжек есть: Таненбаум и Олиферы. LVV>Вроде все, что там без программирования нужно рассказать — там есть.
Возьмите старую книжку "TCP/IP крупным планом", она была где-то на старом Citforum. Базовые вещи про маршрутизацию в ней рассказаны.
Пусть напишут чатик на TCP, под винду, под линукс, снаала с select, затем с WSA(не помню как его там) и с poll. Пусть передадут файл через TCP, измеряя скорость передачи. Пусть допишут к чатику функцию поиска иных экземпляров чата в локальной сети, через broadcast UDP, ну и разумеется функцию отклика на broadcast. И возьмите какую-нибудь популярную библиотеку для С++ или что вы им преподаёте, boost.asio или libuv для голого С, и пусть на них сделают то же самое. Пусть заодно научатся отличать listen на 0.0.0.0 и на конкретном интерфейсе.
Суперски тут народ все растолковал — СПАСИБО.
Но важный для меня вопрос.
Пока я с localhost работаю на своей машине — я могу в клиент-серверной архитектуре изгаляться как угодно.
Но ведь студентам интересно будет переслать файлы друг другу на машины.
Это ж ip надо конкретное знать.
Тут я краем уха читал, что ip (помимо 127) еще как-то расклассифицированы — для локальных сетей, например.
Но пока подробностей не знаю.
А студентов удобно разбить на пары — и пусть изгаляются.
Сначала один будет сервером, потом другой.
И при каждой смене ролей — какая-нить дополнительная примочка.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Суперски тут народ все растолковал — СПАСИБО. LVV>Но важный для меня вопрос. LVV>Пока я с localhost работаю на своей машине — я могу в клиент-серверной архитектуре изгаляться как угодно. LVV>Но ведь студентам интересно будет переслать файлы друг другу на машины. LVV>Это ж ip надо конкретное знать.
Это просто. над каждым местом повесить лист с адресом. по порядку — 127.0.0.1, 127.0.0.2, 127.0.0.3...
хотя это, наверное, просто, лучше так: 127.26.73.4 127.16.48.31 127.45.91.0 127.58.23.255..
LVV>Тут я краем уха читал, что ip (помимо 127) еще как-то расклассифицированы — для локальных сетей, например. LVV>Но пока подробностей не знаю.
LVV>>Пара книжек есть: Таненбаум и Олиферы. LVV>>Вроде все, что там без программирования нужно рассказать — там есть. С>Возьмите старую книжку "TCP/IP крупным планом", она была где-то на старом Citforum. Базовые вещи про маршрутизацию в ней рассказаны.
Спасибо. Нашел. С>Пусть напишут чатик на TCP, под винду, под линукс, снаала с select, затем с WSA(не помню как его там) и с poll. Пусть передадут файл через TCP, измеряя скорость передачи. Пусть допишут к чатику функцию поиска иных экземпляров чата в локальной сети, через broadcast UDP, ну и разумеется функцию отклика на broadcast. И возьмите какую-нибудь популярную библиотеку для С++ или что вы им преподаёте, boost.asio или libuv для голого С, и пусть на них сделают то же самое. Пусть заодно научатся отличать listen на 0.0.0.0 и на конкретном интерфейсе.
Спасибо!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Пара книжек есть: Таненбаум и Олиферы.
Не смущает, что они на четверть века устарели?
LVV>Но практика вызывает у меня вопросы. LVV>Непонятно, с чего начинать и чем заканчивать.
Начать с физического уровня: модуляция, полоса пропускания, теорема Котельникова-Найквиста, контроль четности. И дальше по модели OSI вверх. Если есть электронная лаба -- прекрасно: два микроконтроллера, кусок провода и вперед, писать приемник и передатчик. До студентов через руки дойдет почему что такое IP, чем TCP отличается от UDP и зачем нужен CAN.
Заканчивать кастомным протоколом прикладного уровня. Типа протокола синхронизации состояния в реальном времени для многопользовтельской онлайн игры, устойчивого к потере пакетов и замены порядка пакетов.
LVV>Но студенты зададут вопрос: а зачем nginx, IIS и прочие всякие апачи, если сервер надо писать самим?
Справедливый вопрос. В индустрии, HTTP сервер не нужно писать самому практически никогда. Поэтому и причин учить студентов этому нет.
LVV>>Пара книжек есть: Таненбаум и Олиферы. M>Не смущает, что они на четверть века устарели?
1. А я откуда об этом знаю?
2. Таненбаум Компьютерные сети у меня 2016 года
3. Почему старая книжка Стивенса по сетевому программирования не устарела еще, а Таненбаум устарел ?
LVV>>Но практика вызывает у меня вопросы. LVV>>Непонятно, с чего начинать и чем заканчивать. M>Начать с физического уровня: модуляция, полоса пропускания, теорема Котельникова-Найквиста, контроль четности. И дальше по модели OSI вверх. Если есть электронная лаба -- прекрасно: два микроконтроллера, кусок провода и вперед, писать приемник и передатчик. До студентов через руки дойдет почему что такое IP, чем TCP отличается от UDP и зачем нужен CAN.
В стандарте Программной инженерии физики нет вообще.
M>Заканчивать кастомным протоколом прикладного уровня. Типа протокола синхронизации состояния в реальном времени для многопользовтельской онлайн игры, устойчивого к потере пакетов и замены порядка пакетов.
LVV>>Но студенты зададут вопрос: а зачем nginx, IIS и прочие всякие апачи, если сервер надо писать самим? M>Справедливый вопрос. В индустрии, HTTP сервер не нужно писать самому практически никогда. Поэтому и причин учить студентов этому нет.
Типа автор nginx сам всему этому научился ?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Miroff, Вы писали:
M>Начать с физического уровня: модуляция, полоса пропускания, теорема Котельникова-Найквиста, контроль четности. И дальше по модели OSI вверх. Если есть электронная лаба -- прекрасно: два микроконтроллера, кусок провода и вперед, писать приемник и передатчик. До студентов через руки дойдет почему что такое IP, чем TCP отличается от UDP и зачем нужен CAN.
Шутка-шуткой, но так тоже можно. Предлагаешь заодно в курс сетевого программирования включить изучение биологии голубей?
IP прекрасен тем, что достаточно мало зависит от среды передачи. Я думаю, эту часть вопроса можно пропустить.
Для продвинутых можно обсудить packet loss в wifi и связанные с этим особенности мултикастинга. Но может и не стоит в это углубляться.
M>Справедливый вопрос. В индустрии, HTTP сервер не нужно писать самому практически никогда. Поэтому и причин учить студентов этому нет.
HTTP — это очень базовый протокол для современного интернета. Очень хорошо было бы знать, как он устроен и почему именно так. А лучший способ это понять — попробовать самому. Поэтому не соглашусь, сделать свою реализацию на сокетах — весьма осмысленное упражнение.
Здравствуйте, LaptevVV, Вы писали:
LVV>>>Но студенты зададут вопрос: а зачем nginx, IIS и прочие всякие апачи, если сервер надо писать самим? M>>Справедливый вопрос. В индустрии, HTTP сервер не нужно писать самому практически никогда. Поэтому и причин учить студентов этому нет. LVV>Типа автор nginx сам всему этому научился ?
Мне типа в опенсорсных проектах 2020-го года пришлось написать HTTP-клиента. Не потому, что я всегда всё пишу сам и не доверяю сторонним библиотекам, а потому, что выбора не было (я долго отлынивал от этого поворота судьбы). Причем один из проектов на Go, а вот жеж всё равно пришлось полклиента руками написать, несмотря на прекрасную библиотечную реализацию.
Здравствуйте, LaptevVV, Вы писали:
LVV>Это ж ip надо конкретное знать.
Ну, запускаешь на локальной машине ipconfig, он тебе выдаст всю сетевую конфигурацию, на ВУЗовских компах, думаю, немного будет, это у меня пара десятков различных сетевых интерфейсов для всяких виртуалок и пр
Вот этот IP коллеге у нужно сказать для подключения к твоему компу
LVV>Тут я краем уха читал, что ip (помимо 127) еще как-то расклассифицированы — для локальных сетей, например.
Раньше были классы сетей — A, B, C. 192.168... — это C, предназначена для частных локалок, сейчас сети бесклассовые, всё определяется маской подсети
Здравствуйте, LaptevVV, Вы писали:
LVV>А студентов удобно разбить на пары — и пусть изгаляются. LVV>Сначала один будет сервером, потом другой. LVV>И при каждой смене ролей — какая-нить дополнительная примочка.
Не делайте этого! Один из пары будет гирей на ноге другого. Как отвечал в другом разделе — дайте готовые ответные части.
Такое упражнение стоит дать раз-другой и уже после освоения базы, чтобы они научились описывать друг другу протокол и разбираться, что же на самом деле шлет другая сторона.
Например, дома сделать клиент/сервер и описание протокола, потом вслепую во избежание мордобития раздать чужие описания и exe, задача — написать сервер/клиент.
Здравствуйте, LaptevVV, Вы писали:
LVV>1. С++. Стандартной библиотеки нет.
asio практически стандарт.
LVV>В общем, основной вопрос: чего давать в лабах.
Беда, на самом деле.
Есть предпололжение, что среди группы будет несколько студентов, которым не надо объяснять, чем отличается UDP от IP (pun intended).
Их я бы отвел тихо в сторонку и задал бы сразу писать курсач по теме "реализация системы доставки сообщений с низкой задержкой и высокой надежностью посредством протокола UDP" (да, пусть пишут лайтовый вариант LBM). И чтобы даже на лекции по предмету не ходили, иначе остальным обломают желание что-то учить и делать.
Тем более, так чтобы прям событие. Теоретически, наверное можно глянуть через IOCTL, осталось ли что-то в буфере на отправку, но не уверен, что это хороший способ
