Здравствуйте, LaptevVV, Вы писали:
LVV>Поэтому обращаюсь к народу за помощью.
Я тут подумал, и у меня в голове нарисовался след. учебный план.
1. Введение. Сеть, как способ коммуникации между процессами, расположенными на разных компьютерах. Сокеты, как интерфейс операционной системы к сети. IP-адреса.
Практическое задание: написать на сокетах простейший сервис пересылки файлов (HTTP 0.9), клиента и сервера.
2. TCP и UDP, на базовом уровне.
TCP — старается обеспечить надёжность. Если не получается, возможны большие задержки или разрыв соединения.
UDP — ничего не старается. Потери данных — проблема приложения.
Практическое задание: написать передачу файлов на основе UDP (TFTP).
Желательно было бы иметь учебный эмулятор, который умеет случайным образом терять пакеты в пределах заданного процента потерь и вставлять задержки, случайно распределенные в заданном диапазоне.
При наличии эмулятора, практическое задание: сравнить поведение пересылки файлое через TCP и через UDP.
3. Более углублённое понимание о сетевой адресации. Зачем нужны отдельно MAC-адреса и отдельно IP-адреса. Протокол ARP, связывающий их вместе. Роутинг пакетов на уровне MAC (Ethernet switch) и на уровне IP (IP Router). NAT, что это и зачем нужен.
Вопрос на засыпку: почему гугабитный IP-роутер стоит в 5 таз дороже гигабитного Ethernet-свитча?
4. Введение в DNS.
5. Как устройство в сети находит себя. Протокол DHCP.
Практические задание: написать DHCP-клиента, который получает сетевую конфигурацию и печатает её.
6. Когда UDP лучше TCP. Media streaming.
Практическое задание: написать программу, которая эмулирует media stream, посылая данные с установленной скоростью, на TCP и на UDP. В случае UDP не заботиться о потерях, но измерять отдельно скорость потока на передаче и на приёме и процент потерь. Сравнить поведение TCP-based и UDP-based реализации при наличии потерь в сети.
Вопрос на засыпку: почему DHCP использует UDP?
7. TCP flow control и congestion control. В чём разница между понятиями? Как выглядит график скорости TCP-соединения во времени, если получатель вычитывает данные с ограниченной скоростью, и если он их вычитывает быстро, по мере появления. Как на это влияют потери пакетов в сети.
Всё это хорошо бы отработать на практике.
8. Поиск соседей в сети. UDP multicasting. Протоколы mDNS и DNS-SD. Почему для multicastinga используется UDP, а не TCP.
Практическое задание: написать самодельный протокол поиска друг друга в сети.
Продвинутое задание: исследовать, что у него с надёжностью при наличии сетевых потерь.
9. TCP handshake. Почему он дорог (задача: намерить время установления TCP-соединения при пингах в 200 миллисекунд). Почему при передаче большого количества мелких файлов очень невыгодно использовать отдельное соединение для каждого файла.
10. HTTP/1.1. Какие задачи он решает по сравнению с 0.9 (передача от клиента к серверу, переиспользование соединених).
Практическое задание: написать клиента и сервера HTTP/1.1 на сокетах.
11. Динамическая природа современной сети. Что делать, если IP-адрес изменился? Что делать, если система ушла в suspend а проснулась в другом мире. Как вообше понять, что это произошло.
12. Основы безопасности сети. Введение в TLS.
13. Введение в вопросы производительности. Поведение TCP на сетях с большими задержками и большими потерями. TCP Nagle algorithm.
Здравствуйте, LaptevVV, Вы писали:
LVV>Но студенты зададут вопрос: а зачем nginx, IIS и проие всякие апачи, если сервер надо писать самим7
А зачем самому играть в футбол, если можно по телевизору посмотреть чемпионат высшей лиги?
LVV>Для меня — число психологически предпочтительнее Питона, но что давать в лабах — понятия не имею.
Моё ИМХО, неплохое начальное упражнение — написать на сокетах (а не на стандартной библиотеке) HTTP сервера и клиента. Начинаешь лучше понимать многие вещи.
На уровне HTTP/1.1, 2.0 трогать не надо, там совсем другая игра.
Язык — на усмотрение исполнителя.
А дальше можно развивать. Например, как передавать БОЛЬШИЕ файлы? Всасывать всё в память или сделать streaming-mode передачу тела сообщения? А как передавать видеопоток, у которого нет конечной длины? Как реагировать на разрывы соединения? Запустили стриминговый клиент в лабтопе, крышку закрыли, через полдня открылы, а ему понадобилось еще полдня чтобы понять, что соединение уже тогось. Кто виноват и что делать?
Здравствуйте, Miroff, Вы писали:
M>Начать с физического уровня: модуляция, полоса пропускания, теорема Котельникова-Найквиста, контроль четности. И дальше по модели OSI вверх. Если есть электронная лаба -- прекрасно: два микроконтроллера, кусок провода и вперед, писать приемник и передатчик. До студентов через руки дойдет почему что такое IP, чем TCP отличается от UDP и зачем нужен CAN.
Шутка-шуткой, но так тоже можно. Предлагаешь заодно в курс сетевого программирования включить изучение биологии голубей?
IP прекрасен тем, что достаточно мало зависит от среды передачи. Я думаю, эту часть вопроса можно пропустить.
Для продвинутых можно обсудить packet loss в wifi и связанные с этим особенности мултикастинга. Но может и не стоит в это углубляться.
M>Справедливый вопрос. В индустрии, HTTP сервер не нужно писать самому практически никогда. Поэтому и причин учить студентов этому нет.
HTTP — это очень базовый протокол для современного интернета. Очень хорошо было бы знать, как он устроен и почему именно так. А лучший способ это понять — попробовать самому. Поэтому не соглашусь, сделать свою реализацию на сокетах — весьма осмысленное упражнение.
Здравствуйте, LaptevVV, Вы писали:
LVV>>>Для меня — число психологически предпочтительнее Питона, но что давать в лабах — понятия не имею. Pzz>>Моё ИМХО, неплохое начальное упражнение — написать на сокетах (а не на стандартной библиотеке) HTTP сервера и клиента. Начинаешь лучше понимать многие вещи. LVV>То есть, сокеты — наше все.
Ну, моя точка зрения, надо двигаться от более низкого уровня к более высокому. Тогда не возникает ощущения, что там внутри — непонятная тёмная магия, а мы сверху ей управляем непонятными, но действенными заклинаниями.
И объясни, кстати, своим студентам, что ключевая абстракция HTTP — это обнмен сообщениями (HTTP-запрос и HTTP-ответ — это сообщения), а TCP-соединение, это абстракция более низкого уровня. Которая, по идее, на уровне HTTP не должна быть видна. Но иногда просачивается. Например, из websocket или из-за того, что соединение могут кончиться или соединение может захрястнуть.
Pzz>>На уровне HTTP/1.1, 2.0 трогать не надо, там совсем другая игра. LVV>т.е. HTTP/1.0 — можно ?
Лучше 1.1. Там разница невелика, но починили многие нюансы. Например, сделали обязательным поле Host:, которое неофициально появилось в 1.0, но здесь его узаконили. Описали, как должен работать connection keep alive (переиспользование одного и того же TCP-соединения для последовательности запросов), сделанный не по-партизански, а по стандарту. Стандартизировали, как клиент и сервер могут договориться о компрессии данных. Ввели понятие chunked encoding — он позволяет реализовать завершение потока с заранее неизвестной длиной без разрыва соединения.
Лучше 1.1.
Pzz>>Язык — на усмотрение исполнителя. LVV>Мысль — а давайте на 3 языках
Прям сразу?
LVV>И 2 операционных системах. В винде же сокеты немного другие.
Немного.
Pzz>>А дальше можно развивать. Например, как передавать БОЛЬШИЕ файлы? Всасывать всё в память или сделать streaming-mode передачу тела сообщения? А как передавать видеопоток, у которого нет конечной длины? Как реагировать на разрывы соединения? Запустили стриминговый клиент в лабтопе, крышку закрыли, через полдня открылы, а ему понадобилось еще полдня чтобы понять, что соединение уже тогось. Кто виноват и что делать? LVV>Вот разрывы — это важно. LVV>Остальное пока в тумане.
С этим приходится сталкиваться на практике.
LVV>А REST API сюда вписывается ?
По хорошему должен быть отдельный предмет, где 7 уровней модели OSI и соответсвующие протоколы рассмастриваются. Сетевое программирование это уже обычно прикладные протоколы и API OS — те самые сокеты.
Если начинать с низов, то как минимум надо показать и объяснить что такое tcpdump, traceroute, ip a & co, wireshark. Looking glass сервисы и AS. DHCP и прочее DNS с HTTP это уже самая верхушка сетевого айсберга.
Здравствуйте, PlushBeaver, Вы писали:
PB>То есть учиться программировать сокеты нужно из любви к искусству? PB>Потому что в голове преподавателя нарисован такой образ сетевого программиста?
К сожалению, более высокоуровневые абстракции (скажем, HTTP) то там то сям немного подтекают.
PB>То есть учиться программировать сокеты нужно из любви к искусству? PB>Потому что в голове преподавателя нарисован такой образ сетевого программиста?
Мне кажется с сокетов нужно начинать, потому, что это базовый уровень реализованный в каждой современной ОС (ну, про всякую экзотику и микроконтроллеры не говорим).
И хоть сокетов и нет в стандартной библиотеки С/C++ есть почти одинаковое API на С для всех ОС.
Это и не слишком высокий и не слишком низкий уровень. Когда студент сможет переслать с одной машины на другую "Hello world", у него уже будет какое-то минимальное базовое понимание.
А дальше от этого можно идти на более высокий уровень (всякие HTTP, web сервисы, разные протоколы прикладного уровня), так и на более низкий (залезсть внутрь ядра, разбираться в системных протоколах).
Сеть вообще вещь сложная и очень объемная, мне кажется студентов серьезными специалистами быстро не сделать. Мне кажется можно научить их на практике пользоваться сокетами, написать простой клиент сервер.
И обзорно и кратко дать как можно больше широких знаний как о библиотеках и протоколов и сервисов более высокого уровня, так и о низкоуровневой реализации, чтобы потом студенты понимали в какую сторону им копать, если что-то понадобится.
LVV>>Случился тут форс-мажор — некому преподавать LVV>>Дали мне. S>1. Что за курс? Я не вижу в списке преподаваемых у вас дисциплин "Сетевое программирование". S>Есть Сетевые приложения.
Один фиг...
Программу, очевидно, писал Алтуфьев Мишка — мой дипломник.
И писал, очевидно, под запросы другого моего дипломника и аспиранта, который тоже у нас преподает.
Но он уехал.
А утверждал третий мой выпускник... S>2. Если курс новый — должна быть характеристика дисциплины. Исходить надо из неё.
Ну, конечно, в поручении тоже Сетевые приложения.
Но меня программа не совсем устраивает — там Додиез и винда.
Давно переходить на линукс.
S>3. У нас есть Сетевые технологии. Двадцать с лишним лет тому я практические занятия по ним строил примерно так, как советует сейчас коллега Pzz (https://ccfit.nsu.ru/fit/courses/NetTech/tasks/). S>Сейчас её ведет один из тех, кому я тогда преподавал . Он существенно переделал курс: https://www.nsu.ru/n/information-technologies-department/education_fit/programs/OOP/09-03-01/piikn/rabochie-programmy/09.03.01_PIiKN_B1.B.16.pdf
А вот за это большое спасибо!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>>>Но студенты зададут вопрос: а зачем nginx, IIS и прочие всякие апачи, если сервер надо писать самим? M>>Справедливый вопрос. В индустрии, HTTP сервер не нужно писать самому практически никогда. Поэтому и причин учить студентов этому нет. LVV>Типа автор nginx сам всему этому научился ?
Мне типа в опенсорсных проектах 2020-го года пришлось написать HTTP-клиента. Не потому, что я всегда всё пишу сам и не доверяю сторонним библиотекам, а потому, что выбора не было (я долго отлынивал от этого поворота судьбы). Причем один из проектов на Go, а вот жеж всё равно пришлось полклиента руками написать, несмотря на прекрасную библиотечную реализацию.
Здравствуйте, LaptevVV, Вы писали: LVV>Но студенты зададут вопрос: а зачем nginx, IIS и проие всякие апачи, если сервер надо писать самим7
Типа, зачем программировать, когда всё уже сделано до нас? Ну не программируйте, ПТУ по настройке nginx на соседней улице.
LVV>1. С++. Стандартной библиотеки нет.
База — это сокеты на С.
LVV>Но у меня 100500 книжек по программированию на основе сокетов.
Если про UNIX речь, классика — книги Стивенсона.
Но впрочем, и в винде API сокетов — перепев из юниксового API.
LVV>В точ числе и Ntnlink-сокеты.
Это всё внутрилинуксовая хрень, для программирования сетей не нужно.
LVV>Ну, тоже лучше питона, но менее приятно, чем Go
да, нафиг этот JS выкинуть из головы
LVV>В общем, основной вопрос: чего давать в лабах.
1) Пишем UDP клиент-сервер. Размыкаем кабель. Видим, что сообщение пропущено, и сетевому стеку пофиг.
Пишем TCP клиент-сервер. Размыкаем кабель. Видим, что сообщение НЕ пропущено, потому что сетевому стеку НЕ пофиг.
2) Первый вариант сервера — однопоточный, с мультиплексированием I/O.
Второй вариант сервера — многопоточный, работа с каждым клиентом в отдельном потоке.
3) Пишем сервер для ооочень большого количества клиентов (epoll), нагружаем.
Здравствуйте, student__, Вы писали:
__>Здравствуйте, LaptevVV, Вы писали: LVV>>Но студенты зададут вопрос: а зачем nginx, IIS и проие всякие апачи, если сервер надо писать самим7
__>Типа, зачем программировать, когда всё уже сделано до нас? Ну не программируйте, ПТУ по настройке nginx на соседней улице.
То есть учиться программировать сокеты нужно из любви к искусству?
Потому что в голове преподавателя нарисован такой образ сетевого программиста?
Изучение чего угодно действительно начинается с предпосылок для применения и с границ применимости.
Формируется навык: выбирать подходящие средства для реализации сетевого взаимодействия.
(2LaptevVV) Студентам я бы изложил так.
Программирование на сокетах нужно:
* Для реализации кастомных протоколов, которые нужны:
* * Когда оверхед слишком большой:
* * * по доле служебных полей в трафике (никакой HTTP в 64 бита CAN не влезет);
* * * по тяжести разбора (реализация DHCP и TFTP в PXE);
* * * по риску багов в реализации (регулярно находят CVE в реализациях HTTP/2).
* * Когда схема работы отличается от "запроса-ответа": однонаправленная передача (телеметрия) или multicast (service discovery).
* Для реализации стандартных протоколов, которая может потребоваться:
* * Если её нет под нужную платформу или под какие-то требования (Pzz уже выступал).
* * Чтобы эффективно читать данные без промежуточных структур (сотни тысяч сообщений Netflow/sFlow в секунду).
* Для передачи дескриптора между процессами в *nix (SCM_RIGHTS), которое нужно:
* * Чтобы разделить управляющий процесс и воркеров (как в том же Nginx);
* * ЧТобы обновлять или перезапускать программу без разрыва существующих соединений (как nginx -s reload).
* Для оптимизации производительности с помощью ОС-специфичных средств (recvmmsg/sendmmsg, SO_ATTACH_FILTER, управление буфером).
Границы применимости:
* Сокетов может не быть в микроконтроллере без ОС. (Более экзотический случай: когда мы уже работаем в обход ядра.)
* Обычные (не AF_PACKET) сокеты не предназначены для обработки транзитного трафика на неопределенные адреса, т. е. в задачах файерволов и т. п.
* Производительность сокетов принципиально ограничена копированием между ядром и userspace, системными вызовами и производительностью ядра. (А как тогда? DPDK, eBPF.)
Аналогично есть причины изучать протоколы, диагностику сети и сокетов.
Какие из причин релевантны для студентов в рамках дисциплины — зависит от специальности и учебной программы.
Например, нашему "Управлению в технических системах" упомянутый в теме BGP напрочь не нужен, а "Вычислительным машинам, системам и сетям" — обязателен (хотя это уже не сетевое программирование).
__>1) Пишем UDP клиент-сервер. Размыкаем кабель. Видим, что сообщение пропущено, и сетевому стеку пофиг. __>Пишем TCP клиент-сервер. Размыкаем кабель. Видим, что сообщение НЕ пропущено, потому что сетевому стеку НЕ пофиг.
Видим, что send/sendto отрабатывает одинаково успешно, данные одинаково не приходят.
Тут-то и начинается настоящая лаба с инспекцией системы и трафика
Правда, всё еще непонятно, зачем для этого уметь программировать сокеты.
Суперски тут народ все растолковал — СПАСИБО.
Но важный для меня вопрос.
Пока я с localhost работаю на своей машине — я могу в клиент-серверной архитектуре изгаляться как угодно.
Но ведь студентам интересно будет переслать файлы друг другу на машины.
Это ж ip надо конкретное знать.
Тут я краем уха читал, что ip (помимо 127) еще как-то расклассифицированы — для локальных сетей, например.
Но пока подробностей не знаю.
А студентов удобно разбить на пары — и пусть изгаляются.
Сначала один будет сервером, потом другой.
И при каждой смене ролей — какая-нить дополнительная примочка.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Пара книжек есть: Таненбаум и Олиферы. LVV>Вроде все, что там без программирования нужно рассказать — там есть.
У.Р. Стивенс. UNIX: Разработка сетевых приложений. Там всё по TCP/IP. Актуально до сих пор практически целиком. Под винду тоже. В принципе, не знаю, зачем нужны ещё какие-то книжки...
LVV>В общем, основной вопрос: чего давать в лабах.
Pzz>Я тут подумал, и у меня в голове нарисовался след. учебный план. Pzz>1. Введение. Сеть, как способ коммуникации между процессами, расположенными на разных компьютерах. Сокеты, как интерфейс операционной системы к сети. IP-адреса. Pzz>Практическое задание: написать на сокетах простейший сервис пересылки файлов (HTTP 0.9), клиента и сервера. Pzz>2. TCP и UDP, на базовом уровне. Pzz>TCP — старается обеспечить надёжность. Если не получается, возможны большие задержки или разрыв соединения. Pzz>UDP — ничего не старается. Потери данных — проблема приложения. Pzz>Практическое задание: написать передачу файлов на основе UDP (TFTP).
--- Pzz>Желательно было бы иметь учебный эмулятор, который умеет случайным образом терять пакеты в пределах заданного процента потерь и вставлять задержки, случайно распределенные в заданном диапазоне. Pzz>При наличии эмулятора, практическое задание: сравнить поведение пересылки файлое через TCP и через UDP.
Это может быть заданием на бакалаврскую!
Pzz>3. Более углублённое понимание о сетевой адресации. Зачем нужны отдельно MAC-адреса и отдельно IP-адреса. Протокол ARP, связывающий их вместе. Роутинг пакетов на уровне MAC (Ethernet switch) и на уровне IP (IP Router). NAT, что это и зачем нужен. Pzz>Вопрос на засыпку: почему гугабитный IP-роутер стоит в 5 таз дороже гигабитного Ethernet-свитча? Pzz>4. Введение в DNS. Pzz>5. Как устройство в сети находит себя. Протокол DHCP. Pzz>Практические задание: написать DHCP-клиента, который получает сетевую конфигурацию и печатает её. Pzz>6. Когда UDP лучше TCP. Media streaming. Pzz>Практическое задание: написать программу, которая эмулирует media stream, посылая данные с установленной скоростью, на TCP и на UDP. В случае UDP не заботиться о потерях, но измерять отдельно скорость потока на передаче и на приёме и процент потерь. Сравнить поведение TCP-based и UDP-based реализации при наличии потерь в сети. Pzz>Вопрос на засыпку: почему DHCP использует UDP? Pzz>7. TCP flow control и congestion control. В чём разница между понятиями? Как выглядит график скорости TCP-соединения во времени, если получатель вычитывает данные с ограниченной скоростью, и если он их вычитывает быстро, по мере появления. Как на это влияют потери пакетов в сети. Pzz>Всё это хорошо бы отработать на практике. Pzz>8. Поиск соседей в сети. UDP multicasting. Протоколы mDNS и DNS-SD. Почему для multicastinga используется UDP, а не TCP. Pzz>Практическое задание: написать самодельный протокол поиска друг друга в сети. Pzz>Продвинутое задание: исследовать, что у него с надёжностью при наличии сетевых потерь. Pzz>9. TCP handshake. Почему он дорог (задача: намерить время установления TCP-соединения при пингах в 200 миллисекунд). Почему при передаче большого количества мелких файлов очень невыгодно использовать отдельное соединение для каждого файла. Pzz>10. HTTP/1.1. Какие задачи он решает по сравнению с 0.9 (передача от клиента к серверу, переиспользование соединених). Pzz>Практическое задание: написать клиента и сервера HTTP/1.1 на сокетах. Pzz>11. Динамическая природа современной сети. Что делать, если IP-адрес изменился? Что делать, если система ушла в suspend а проснулась в другом мире. Как вообше понять, что это произошло. Pzz>12. Основы безопасности сети. Введение в TLS. Pzz>13. Введение в вопросы производительности. Поведение TCP на сетях с большими задержками и большими потерями. TCP Nagle algorithm.
Блин!
Ты ж можешь прямо учебник написать!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>1. С++. Стандартной библиотеки нет.
asio практически стандарт.
LVV>В общем, основной вопрос: чего давать в лабах.
Беда, на самом деле.
Есть предпололжение, что среди группы будет несколько студентов, которым не надо объяснять, чем отличается UDP от IP (pun intended).
Их я бы отвел тихо в сторонку и задал бы сразу писать курсач по теме "реализация системы доставки сообщений с низкой задержкой и высокой надежностью посредством протокола UDP" (да, пусть пишут лайтовый вариант LBM). И чтобы даже на лекции по предмету не ходили, иначе остальным обломают желание что-то учить и делать.
Здравствуйте, Pzz, Вы писали:
Pzz>Я имел ввиду затронуть маршрутизацию по префиксам (и прочие там классы сетей)
"Классы сетей" уже несколько десятилетий как не используются Classless Inter-Domain Routing появился в 1993 году. Такие архаичные термины не стоит и упоминать т.к. это тупиковая ветвь эволюции.
Здравствуйте, Pzz, Вы писали:
Pzz>Она слишком академичная. Стек TCP/IP плохо на неё ложится.
Прекрасно ложится, просто не для каждого уровня есть отдельный протокол.
Здравствуйте, Stanislav V. Zudin, Вы писали:
M>>Ну, в винде есть дополнительная пачка функций WSA*, может про них? А так, API беркли сокетов точно такое же, только, как уже сказал, ioctl по другому называется, и нет poll (когда я активно с сетью возился, его не особо было и линупсах и прочих бздях). Сейчас, наверное, уже подвезли.
SVZ>poll'а нет, зато есть overlapped и I/O completion ports
Чего-то в сетевом форуме мой вопрос никто тне прочитал.
Повторяю здесь
Случился тут форс-мажор — некому преподавать
Дали мне.
Я в этом деле практически полный чайник.
Поэтому обращаюсь к народу за помощью.
Пара книжек есть: Таненбаум и Олиферы.
Вроде все, что там без программирования нужно рассказать — там есть.
Но практика вызывает у меня вопросы.
Непонятно, с чего начинать и чем заканчивать.
Ну, писание клиента и сервера — это понятно.
Но студенты зададут вопрос: а зачем nginx, IIS и проие всякие апачи, если сервер надо писать самим7
2. Python. Есть стандартные (?) библиотеки (разного уровня — вплоть до сокетов)
Есть неплохая книжка про сетевое программиррование на Python https://bhv.ru/product/setevoe-programmirovanie-na-python/
И вроде неплохо все изложено. Но а) Питон — осваивать придется самому
б) все равно неясно, что в качестве лаб давать.
3. Go. Есть стандартная библиотека
На русском практически ничего нет.
На английском довольно много. И есть документация.
Для меня — число психологически предпочтительнее Питона, но что давать в лабах — понятия не имею.
4. JS/TS + Node.JS
Ну, тоже лучше питона, но менее приятно, чем Go
В общем, основной вопрос: чего давать в лабах.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>Но студенты зададут вопрос: а зачем nginx, IIS и проие всякие апачи, если сервер надо писать самим7 Pzz>А зачем самому играть в футбол, если можно по телевизору посмотреть чемпионат высшей лиги?
LVV>>Для меня — число психологически предпочтительнее Питона, но что давать в лабах — понятия не имею. Pzz>Моё ИМХО, неплохое начальное упражнение — написать на сокетах (а не на стандартной библиотеке) HTTP сервера и клиента. Начинаешь лучше понимать многие вещи.
То есть, сокеты — наше все.
Pzz>На уровне HTTP/1.1, 2.0 трогать не надо, там совсем другая игра.
т.е. HTTP/1.0 — можно ? Pzz>Язык — на усмотрение исполнителя.
Мысль — а давайте на 3 языках!
И 2 операционных системах. В винде же сокеты немного другие. Pzz>А дальше можно развивать. Например, как передавать БОЛЬШИЕ файлы? Всасывать всё в память или сделать streaming-mode передачу тела сообщения? А как передавать видеопоток, у которого нет конечной длины? Как реагировать на разрывы соединения? Запустили стриминговый клиент в лабтопе, крышку закрыли, через полдня открылы, а ему понадобилось еще полдня чтобы понять, что соединение уже тогось. Кто виноват и что делать?
Вот разрывы — это важно.
Остальное пока в тумане.
А REST API сюда вписывается ?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>В общем, основной вопрос: чего давать в лабах.
1. написать telnet клиент. Спека простенькая UI минимальный.
2. SOCKS proxy со снифингом/фильтрацией/подменой траффика.
3. классика — клиент-серверный мессенджер.
LVV>Но студенты зададут вопрос: а зачем nginx, IIS и проие всякие апачи, если сервер надо писать самим7
вот тут наглядно покажете студентам как их самописный сервер умирает от 1к клиентов
4. HTTP. У многих есть открытый HTTP API. Реализовать какую-нить извлекалку данных. У желтого банка можно котировки акций, например. У многих игрушек (Танки, Ева, WOW) есть АПИ тоже можно что-нить простенькое написать.
Здравствуйте, Pzz, Вы писали:
Pzz>Я тут подумал, и у меня в голове нарисовался след. учебный план.
Pzz>1. Введение. Сеть, как способ коммуникации между процессами, расположенными на разных компьютерах. Сокеты, как интерфейс операционной системы к сети. IP-адреса.
У.Р. Стивенс. UNIX: Взаимодействие процессов. Она зело тоньше стивенсоновского сетевого программирования, можно пару-тройку лекций посвятить межпроцессному взаиводействию, про шаред мемори не углубляться, а про пайпы, майлслоты и подобное. Вот тут можно сказать, что у винды АПИ другие, но принципы — те же самые.
Потом уже от этого можно перейти к сети, и показать, в том числе, что механизм в общем-то аналогичный
Pzz>Практическое задание: написать на сокетах простейший сервис пересылки файлов (HTTP 0.9), клиента и сервера.
Да ну, крутовато для первой лабы, пока разберуться, что к чему, пусть просто клиент-сервер, клиент по энтеру отсылает ввод, эхо-сервер отвечает, может у себя на экране выводить, с указанием, от какого клиента пришло.
Pzz>Практическое задание: написать передачу файлов на основе UDP (TFTP).
Крутовато берёшь
Pzz>3. Более углублённое понимание о сетевой адресации. Зачем нужны отдельно MAC-адреса и отдельно IP-адреса. Протокол ARP, связывающий их вместе. Роутинг пакетов на уровне MAC (Ethernet switch) и на уровне IP (IP Router). NAT, что это и зачем нужен.
Я бы ещё сказал, что MAC-адрес для сети TCP/IP не обязателен. И что MAC — это фишка Ethernet, в других типах сетей их может и не быть, или быть, но называться по другому, или называться так же, но быть отличным понятием.
Я как-то поспорил на работе с челом на эту тему, он мне втирал, что интернета без MAC адресов не бывает, я говорил, что в TCP/IP нет ничего про MAC-адреса
Здравствуйте, Marty, Вы писали:
Pzz>>Практическое задание: написать на сокетах простейший сервис пересылки файлов (HTTP 0.9), клиента и сервера.
HTTP 0.9 очень простой. Посылаешь туда HTTP GET /path/to/file, получаешь взад файл.
Pzz>>Практическое задание: написать передачу файлов на основе UDP (TFTP).
M>Крутовато берёшь
Ну TFTP правда очень простой протокол. T — от слова Trivial, и ведь не наврали.
M>Я бы ещё сказал, что MAC-адрес для сети TCP/IP не обязателен. И что MAC — это фишка Ethernet, в других типах сетей их может и не быть, или быть, но называться по другому, или называться так же, но быть отличным понятием.
В принципе, да. Но большинство практическеских сетей предпочитает прикидываться Ethernet-ом. Мне из исключений приходит в голову только PPP и SLIP...
M>Я как-то поспорил на работе с челом на эту тему, он мне втирал, что интернета без MAC адресов не бывает, я говорил, что в TCP/IP нет ничего про MAC-адреса
Я хотел еще задать вопрос из числа моих любимых. Но боюсь, это уж сложно очень.
Вопрос такой. Вот есть устоявшийся TCP-поток, который уже нащупал максимальную скорость сети. Посылатель посылает, приниматель принимает пакеты.
Вопрос: какое именно событие заставляет посылатель послать следующий пакет в потоке?
Здравствуйте, syrompe, Вы писали:
LVV>>В общем, основной вопрос: чего давать в лабах.
S>1. написать telnet клиент. Спека простенькая UI минимальный.
В нём правильная реализация options negotiation довольно сложна и выводит на сцену того самого Бернштейна, который прославился своей деятельностью в областии криптографии.
LVV>>Пара книжек есть: Таненбаум и Олиферы. LVV>>Вроде все, что там без программирования нужно рассказать — там есть. M>У.Р. Стивенс. UNIX: Разработка сетевых приложений. Там всё по TCP/IP. Актуально до сих пор практически целиком. Под винду тоже. В принципе, не знаю, зачем нужны ещё какие-то книжки...
Эта книжка тоже есть.
Спасибо
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>И 2 операционных системах. В винде же сокеты немного другие. M>Чем же они в винде другие?
В новой книжке, ссыль на которую я давал в первом посте, написано, что названия функций не совпадают.
И вообще ioctl и fnctl отсутствуют.
Но про программирование в винде аж 5 глав подряд написано.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Pzz, Вы писали:
Pzz>>>Практическое задание: написать на сокетах простейший сервис пересылки файлов (HTTP 0.9), клиента и сервера.
Pzz>HTTP 0.9 очень простой. Посылаешь туда HTTP GET /path/to/file, получаешь взад файл.
А, ну так-то да. Но это не совсем таки HTTP 0.9, заголовки-то и в нём были.
И взад получаешь скорее всего не двоичный файл, навскидку сейчас не скажу, но скорее всего base64
Pzz>>>Практическое задание: написать передачу файлов на основе UDP (TFTP).
M>>Крутовато берёшь
Pzz>Ну TFTP правда очень простой протокол. T — от слова Trivial, и ведь не наврали.
Ну может, я не изучал TFTP на самом деле
Pzz>В принципе, да. Но большинство практическеских сетей предпочитает прикидываться Ethernet-ом. Мне из исключений приходит в голову только PPP и SLIP...
Тем не менее, локалку можно на TokenRing или ArcNet сделать, связь с аплинком — точка-точка — и всё, никаких MAC, а и Internet сделать можно
Pzz>Я хотел еще задать вопрос из числа моих любимых. Но боюсь, это уж сложно очень.
Pzz>Вопрос такой. Вот есть устоявшийся TCP-поток, который уже нащупал максимальную скорость сети. Посылатель посылает, приниматель принимает пакеты.
Pzz>Вопрос: какое именно событие заставляет посылатель послать следующий пакет в потоке?
Интересный вопрос. Я не знаю ответа Тем более, так чтобы прям событие. Теоретически, наверное можно глянуть через IOCTL, осталось ли что-то в буфере на отправку, но не уверен, что это хороший способ
S>>1. написать telnet клиент. Спека простенькая UI минимальный.
Pzz>В нём правильная реализация options negotiation довольно сложна и выводит на сцену того самого Бернштейна, который прославился своей деятельностью в областии криптографии.
Да ладно. Там простенький КА за час-два пишется. Ну на крайний случай можно отказ на все предложения слать.
Здравствуйте, Marty, Вы писали:
Pzz>>HTTP 0.9 очень простой. Посылаешь туда HTTP GET /path/to/file, получаешь взад файл.
M>А, ну так-то да. Но это не совсем таки HTTP 0.9, заголовки-то и в нём были. M>И взад получаешь скорее всего не двоичный файл, навскидку сейчас не скажу, но скорее всего base64
Неа.
https://http.dev/0.9
Pzz>>В принципе, да. Но большинство практическеских сетей предпочитает прикидываться Ethernet-ом. Мне из исключений приходит в голову только PPP и SLIP...
M>Тем не менее, локалку можно на TokenRing или ArcNet сделать, связь с аплинком — точка-точка — и всё, никаких MAC, а и Internet сделать можно
У токенринга тоже MAC-адреса, в стиле Ethernet. У ArcNet-а не знаю.
Pzz>>Вопрос: какое именно событие заставляет посылатель послать следующий пакет в потоке?
M>Интересный вопрос. Я не знаю ответа Тем более, так чтобы прям событие. Теоретически, наверное можно глянуть через IOCTL, осталось ли что-то в буфере на отправку, но не уверен, что это хороший способ
При чем тут IOCTL? Как сетевой стек решает, когда очередной пакет послать?
Здравствуйте, syrompe, Вы писали:
Pzz>>В нём правильная реализация options negotiation довольно сложна и выводит на сцену того самого Бернштейна, который прославился своей деятельностью в областии криптографии.
S>Да ладно. Там простенький КА за час-два пишется. Ну на крайний случай можно отказ на все предложения слать.
Я писал. Не за час-два, есть кривые реализации, с которыми надо бы ладить.
Здравствуйте, LaptevVV, Вы писали: LVV>>>И 2 операционных системах. В винде же сокеты немного другие. M>>Чем же они в винде другие? LVV>В новой книжке, ссыль на которую я давал в первом посте, написано, что названия функций не совпадают. LVV>И вообще ioctl и fnctl отсутствуют.
По моему, это единственное отличие. ioctl называется ioctlsocket.
fnctl — такой в винде нет, но я что-то не припоминаю, чтобы она как-то использовалась с сокетами. Не расскажешь?
LVV>Но про программирование в винде аж 5 глав подряд написано.
Ну, в винде есть дополнительная пачка функций WSA*, может про них? А так, API беркли сокетов точно такое же, только, как уже сказал, ioctl по другому называется, и нет poll (когда я активно с сетью возился, его не особо было и линупсах и прочих бздях). Сейчас, наверное, уже подвезли.
Ну и надо ещё вызывать WSAStartup/WSACleanup. Но это всё такие мелочи.
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 и на конкретном интерфейсе.
Здравствуйте, 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 сам всему этому научился ?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Это ж ip надо конкретное знать.
Ну, запускаешь на локальной машине ipconfig, он тебе выдаст всю сетевую конфигурацию, на ВУЗовских компах, думаю, немного будет, это у меня пара десятков различных сетевых интерфейсов для всяких виртуалок и пр
Вот этот IP коллеге у нужно сказать для подключения к твоему компу
LVV>Тут я краем уха читал, что ip (помимо 127) еще как-то расклассифицированы — для локальных сетей, например.
Раньше были классы сетей — A, B, C. 192.168... — это C, предназначена для частных локалок, сейчас сети бесклассовые, всё определяется маской подсети
Здравствуйте, LaptevVV, Вы писали:
LVV>А студентов удобно разбить на пары — и пусть изгаляются. LVV>Сначала один будет сервером, потом другой. LVV>И при каждой смене ролей — какая-нить дополнительная примочка.
Не делайте этого! Один из пары будет гирей на ноге другого. Как отвечал в другом разделе — дайте готовые ответные части.
Такое упражнение стоит дать раз-другой и уже после освоения базы, чтобы они научились описывать друг другу протокол и разбираться, что же на самом деле шлет другая сторона.
Например, дома сделать клиент/сервер и описание протокола, потом вслепую во избежание мордобития раздать чужие описания и exe, задача — написать сервер/клиент.
Здравствуйте, mrTwister, Вы писали:
Pzz>>Я тут подумал, и у меня в голове нарисовался след. учебный план.
T>Про маршрутизацию не хватает: OSPF, BGP
Боюсь, столько не впихнуть.
Я имел ввиду затронуть маршрутизацию по префиксам (и прочие там классы сетей) в разговоре об различии между MAC и IP адресами, но мне кажется, сильно дальше этого идти не обязательно.
Здравствуйте, Pzz, Вы писали:
Pzz>Я имел ввиду затронуть маршрутизацию по префиксам (и прочие там классы сетей) в разговоре об различии между MAC и IP адресами, но мне кажется, сильно дальше этого идти не обязательно.
Не знаю, не уверен. Весь интернет работает на BGP. Это максимально фундаментальная технология, которая буквально находится в основе всего современного IT. И при этом про нее почти никто ничего не знает.
Здравствуйте, mrTwister, Вы писали:
Pzz>>Я имел ввиду затронуть маршрутизацию по префиксам (и прочие там классы сетей) в разговоре об различии между MAC и IP адресами, но мне кажется, сильно дальше этого идти не обязательно.
T>Не знаю, не уверен. Весь интернет работает на BGP. Это максимально фундаментальная технология, которая буквально находится в основе всего современного IT. И при этом про нее почти никто ничего не знает.
Может это не такое уж и обязательное знание, если о нём почти никто ничего не знает?
Я тоже, должен признаться, мало чего знаю про BGP...
LVV>Но практика вызывает у меня вопросы. LVV>Непонятно, с чего начинать и чем заканчивать. LVV>Ну, писание клиента и сервера — это понятно. LVV>Но студенты зададут вопрос: а зачем nginx, IIS и проие всякие апачи, если сервер надо писать самим7
но сервера же не только для веб-страниц бывают. игрушки и всякие телеграммы имеют вполне себе самописные сервера.
J>>Модель osi . 90% программистов очень далеки от ее понимания.
Pzz>Она слишком академичная. Стек TCP/IP плохо на неё ложится.
Это смотря как его подать Когда я учился в институте, у нас был преподаватель фанат OSI.
Каждая лекцию / зачет он обязательно ее вспоминал и дотошно спрашивал у каждого студента . Сейчас ,по прошествии лет, благодаря этому
у меня не возникает никаких проблем с настройкой новой сетевой железки .
Если студент в последствии попадет в авиацию, море и прочие конторы, где много пропитанных протоколов , хорошее знание osi тоже лишнем не будет
... Хорошо уметь читать между строк. Это иногда
приносит большую пользу
Здравствуйте, Janus, Вы писали:
Pzz>>Она слишком академичная. Стек TCP/IP плохо на неё ложится.
J>Это смотря как его подать Когда я учился в институте, у нас был преподаватель фанат OSI. J>Каждая лекцию / зачет он обязательно ее вспоминал и дотошно спрашивал у каждого студента . Сейчас ,по прошествии лет, благодаря этому J>у меня не возникает никаких проблем с настройкой новой сетевой железки .
На каком уровне OSI находится IP-level VPN, который использует HTTPS для авторизации, а потом уходит в WebSocket, используя его в качестве транспорта для пакетов?
J>Если студент в последствии попадет в авиацию, море и прочие конторы, где много пропитанных протоколов , хорошее знание osi тоже лишнем не будет
Ну, наверное умение работать в авиации, это отдельный навык. Требующий, например, умения выживать при сильно формализованном процессе.
Здравствуйте, Pzz, Вы писали:
Pzz>На каком уровне OSI находится IP-level VPN, который использует HTTPS для авторизации, а потом уходит в WebSocket, используя его в качестве транспорта для пакетов?
Любой впн находится в квантовой суперпозиции, являясь одновременно и транспортом и пэйлоадом, независимо от хендшейка и мнения наблюдателя.
Здравствуйте, Stanislaw K, Вы писали:
Pzz>>На каком уровне OSI находится IP-level VPN, который использует HTTPS для авторизации, а потом уходит в WebSocket, используя его в качестве транспорта для пакетов?
SK>Любой впн находится в квантовой суперпозиции, являясь одновременно и транспортом и пэйлоадом, независимо от хендшейка и мнения наблюдателя.
Тут важно, чтобы от него не отваливался какой-нибудь кусок под воздействием недоброго взгляда наблюдателя.
Здравствуйте, Marty, Вы писали:
LVV>>Но про программирование в винде аж 5 глав подряд написано.
M>Ну, в винде есть дополнительная пачка функций WSA*, может про них? А так, API беркли сокетов точно такое же, только, как уже сказал, ioctl по другому называется, и нет poll (когда я активно с сетью возился, его не особо было и линупсах и прочих бздях). Сейчас, наверное, уже подвезли.
poll'а нет, зато есть overlapped и I/O completion ports
_____________________
С уважением,
Stanislav V. Zudin
Pzz>На каком уровне OSI находится IP-level VPN, который использует HTTPS для авторизации, а потом уходит в WebSocket, используя его в качестве транспорта для пакетов?
Это вопрос из серии как рассматривает самолет летчик и пассажир .
Есть еще L2TPv3 на каком уровне OSI он находится ?
J>>Если студент в последствии попадет в авиацию, море и прочие конторы, где много пропитанных протоколов , хорошее знание osi тоже лишнем не будет
Pzz>Ну, наверное умение работать в авиации, это отдельный навык. Требующий, например, умения выживать при сильно формализованном процессе.
дело не формализации. Любое сетевое взаимодействие можно описать моделью osi . Обсуждая с коллегами проприетарную сеть (протокол) вы поймете друг друга
... Хорошо уметь читать между строк. Это иногда
приносит большую пользу
Здравствуйте, Pzz, Вы писали:
SK>>Любой впн находится в квантовой суперпозиции, являясь одновременно и транспортом и пэйлоадом, независимо от хендшейка и мнения наблюдателя.
Pzz>Тут важно, чтобы от него не отваливался какой-нибудь кусок под воздействием недоброго взгляда наблюдателя.
Здравствуйте, Pzz, Вы писали:
Pzz>Может это не такое уж и обязательное знание, если о нём почти никто ничего не знает?
Может быть, не знаю. Но для меня странно, что доставка пакетов из точки А в точку Б на другом конце света объясняется магией и это всем ок
Pzz>Я тоже, должен признаться, мало чего знаю про BGP...
Да я сам не так давно в эту тему начал погружаться и был в шоке от своей некомпетентности. Я понял, что вообще не понимал, как работает интернет и очень мне бы хотелось, чтобы про BGP мне рассказали еще в университете. Благо его придумали 36 лет назад, это не какая-то новомодная технология
Здравствуйте, LaptevVV, Вы писали:
LVV>В общем, основной вопрос: чего давать в лабах.
А у вас то кейс какой? Системный или прикладной? Есть у студентов курс типа "сети" или это первое знакомство?
Если прикладной, то нужно смотреть адресацию, http api udp tcp dns, таймауты-обрывы. Минимально протоколы, фокус на различные задачи — передача файлов, чат, восстановление после обрыва, итд.
Здесь можно писать хоть на чем, абы работало.
Если системный — то это протоколы, сокеты и подобные вещи. Тут нужно чтото низкоуровневое, вещи типа nodejs не сгодятся.
Если курса по сетям не было, то нужно дать какую то картину мира tcp/ip osi/iso адресация порты итд, что бы могли это попробовать при помощи утилит — ping, tracert, ifconfig, route, netstat итд.
Тут я бы потратил 2 лабы чисто на докер и похожие вещи, что бы люди могли соорудить сеть и попробовать на ней разные инструменты. Если с докером тупик, то нужно чтото другое, мб ssh, telnet
Уже после этого приступать к тем самым сокетам.
Вы можете давать студентам какие то заготовки хоть на Go, что бы они дорабатывали под конкретную лабу. В этом случае вы можете увеличить объем задания, т.к. студенты будут стартовать "с трамплина"
Здравствуйте, mrTwister, Вы писали:
Pzz>>Может это не такое уж и обязательное знание, если о нём почти никто ничего не знает?
T>Может быть, не знаю. Но для меня странно, что доставка пакетов из точки А в точку Б на другом конце света объясняется магией и это всем ок
Ну почему магией? Маршрутом...
Pzz>>Я тоже, должен признаться, мало чего знаю про BGP...
T>Да я сам не так давно в эту тему начал погружаться и был в шоке от своей некомпетентности. Я понял, что вообще не понимал, как работает интернет и очень мне бы хотелось, чтобы про BGP мне рассказали еще в университете. Благо его придумали 36 лет назад, это не какая-то новомодная технология
А что в Интернете придумали не несколько десятков лет назад?
Здравствуйте, mrTwister, Вы писали:
Pzz>>Может это не такое уж и обязательное знание, если о нём почти никто ничего не знает?
T>Может быть, не знаю. Но для меня странно, что доставка пакетов из точки А в точку Б на другом конце света объясняется магией и это всем ок
Зачем магией? BGP полезен, спору нет, но можно обойтись и статическими таблицами маршрутизации
Здравствуйте, PlushBeaver, Вы писали:
PB>То есть учиться программировать сокеты нужно из любви к искусству?
вообще что-либо делать без любви довольно хреново...
PB>Потому что в голове преподавателя нарисован такой образ сетевого программиста?
я не имею понятия, что в вашей голове находится о том, что находится в голове преподавателя
PB>Программирование на сокетах нужно: PB>* Для реализации кастомных протоколов, которые нужны:
хосспади, да ему начать надо с хелловорлда.
Хорошо, если так хочется конкретной задачи — пожалуйста.
Вот есть индустриальный протокол XYZ, и надо его реализовать для отечественного PLC.
Какие там оверхэды... да насрать, потому что выбор протокола определяется существующими устройствами, которыми, собсна, и надо управлять, и разработчики этих устройств уже выбрали протокол.
PB>* Сокетов может не быть в микроконтроллере без ОС.
сделать ещё одну лабу, где две доски с МК говорят друг с другом по последовательному порту.
PB>Аналогично есть причины изучать протоколы, диагностику сети и сокетов. PB>Какие из причин релевантны для студентов в рамках дисциплины — зависит от специальности и учебной программы.
очевидно, что все вопросы, свазанные с сетевым взаимодействием, в рамках одного курса не осветить
PB>Видим, что send/sendto отрабатывает одинаково успешно, данные одинаково не приходят. PB>Тут-то и начинается настоящая лаба с инспекцией системы и трафика
Так разработать эксперимент — сама по себе инженерная задача.
Типа, пишут, что TCP что-то там гарантирует. Докажи.
PB>Правда, всё еще непонятно, зачем для этого уметь программировать сокеты.
Если не нравится такая задачка, можно другую придумать.
Вопрос же основной был про лабы, а это по определению строение велосипедов.
librats is a modern P2P networking library designed for superior performance and simplicity.
Built from the ground up in C++17, it provides enterprise-grade P2P networking capabilities with minimal overhead and maximum efficiency.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Marty, Вы писали:
T>>Может быть, не знаю. Но для меня странно, что доставка пакетов из точки А в точку Б на другом конце света объясняется магией и это всем ок
M>Зачем магией? BGP полезен, спору нет, но можно обойтись и статическими таблицами маршрутизации
FullView не каждый маршрутизатор операторского уровня потянет и придется надолго забыть о 100 мбитных скоростях.
Здравствуйте, Stanislaw K, Вы писали:
M>>Зачем магией? BGP полезен, спору нет, но можно обойтись и статическими таблицами маршрутизации
SK>FullView не каждый маршрутизатор операторского уровня потянет и придется надолго забыть о 100 мбитных скоростях.
Здравствуйте, Marty, Вы писали:
M>>>Зачем магией? BGP полезен, спору нет, но можно обойтись и статическими таблицами маршрутизации
SK>>FullView не каждый маршрутизатор операторского уровня потянет и придется надолго забыть о 100 мбитных скоростях.
M>Можно поподробнее?
Под статические таблицы маршрутизации потребуется на порядок больше ресурсов (памяти и процессора), соответственно стоимость маршрутизатора будет в разы выше, а производительность в разы (десятки раз) ниже.
Это не домашний роутер, в котором собственно работа по маршрутизации фактически отсутствует, там каждый пакет придётся роутить по полной.
Здравствуйте, Stanislaw K, Вы писали:
SK>>>FullView не каждый маршрутизатор операторского уровня потянет и придется надолго забыть о 100 мбитных скоростях.
M>>Можно поподробнее?
SK>Под статические таблицы маршрутизации потребуется на порядок больше ресурсов (памяти и процессора), соответственно стоимость маршрутизатора будет в разы выше, а производительность в разы (десятки раз) ниже.
SK>Это не домашний роутер, в котором собственно работа по маршрутизации фактически отсутствует, там каждый пакет придётся роутить по полной.
Всё равно не понятно, как BGP позволяет уменьшить таблицы маршрутизации
Pzz>Желательно было бы иметь учебный эмулятор, который умеет случайным образом терять пакеты в пределах заданного процента потерь и вставлять задержки, случайно распределенные в заданном диапазоне.
Кстати, я с Мишкой вчера связался в телеге.
Он мне написал, какие лабы он давал.
----
Сетевые приложения: https://professorweb.ru/my/csharp/web/level1/web_index.php
Можете почитать на досуге, но вообще мы это будем рассматривать потихоньку.
Лабы:
1. Выдача ответа на запрос по протоколу http (Raw Socket). Выдача ответа на запрос по протоколу file (Web Request). Выдача ответа на запрос dns (Shell Exec).
2. Client+Server — выдача на сервере текстовой строки, переданной клиентом с помощью Socket (использовать протокол TCP).
3. Сканер открытых портов локального IP адреса. Использовать Raw Socket.
4. Сканер локальной сети на предмет имеющихся IP адресов и открытых портов. Использовать Raw Socket.
5. Сниффер пакетов. Использовать Raw Socket. НЕ надо парсить заголовки. Но если хочется, то можно.
6. Чат на TCP-сокетах:
— Клиенты подключаются к серверу с указанием IP:port.
— Клиенты могут передавать сообщения и файлы.
— Клиенты могут создавать групповые и личные чаты.
— Сервер хранит список клиентов.
— Сервер обновляет список клиентов при его изменении и отправляет новый клентам.
— Сервер обеспечивает поддержание списка в актуальном соостоянии (например, при обрыве связи с клиентом).
— Сервер поддерживает возможность создаия групповых и p2p чатов.
— Сервер обеспечивает передачу сообщений и файлов в трёх режимах: личный, групповой, общий.
----
Лучше писать на C#
Можно писать на Java, Kotlin, [C++, Swift, Objective C] — для месье, Go, Rust, Elixir...
Нельзя на: JS, Dart, Ruby, Python.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Marty, Вы писали:
M>Зачем магией? BGP полезен, спору нет, но можно обойтись и статическими таблицами маршрутизации
И как ими обмениваться? По почте? В интернете пятизначное число активных автономных систем (~провайдеров).
Здравствуйте, LaptevVV, Вы писали:
LVV>---- LVV>Лучше писать на C# LVV>Можно писать на Java, Kotlin, [C++, Swift, Objective C] — для месье, Go, Rust, Elixir... LVV>Нельзя на: JS, Dart, Ruby, Python.
Какое его дело, на чём писать?
Если на питоне написать, незачёт поставит что ли?
Ну бред же.
LVV>>---- LVV>>Лучше писать на C# LVV>>Можно писать на Java, Kotlin, [C++, Swift, Objective C] — для месье, Go, Rust, Elixir... LVV>>Нельзя на: JS, Dart, Ruby, Python. __>Какое его дело, на чём писать? __>Если на питоне написать, незачёт поставит что ли? __>Ну бред же.
не бред.
Реальное знание контингента и их уровня знаний.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
