Чего-то в сетевом форуме мой вопрос никто тне прочитал.
Повторяю здесь
Случился тут форс-мажор — некому преподавать
Дали мне.
Я в этом деле практически полный чайник.
Поэтому обращаюсь к народу за помощью.
Пара книжек есть: Таненбаум и Олиферы.
Вроде все, что там без программирования нужно рассказать — там есть.
Но практика вызывает у меня вопросы.
Непонятно, с чего начинать и чем заканчивать.
Ну, писание клиента и сервера — это понятно.
Но студенты зададут вопрос: а зачем nginx, IIS и проие всякие апачи, если сервер надо писать самим7
2. Python. Есть стандартные (?) библиотеки (разного уровня — вплоть до сокетов)
Есть неплохая книжка про сетевое программиррование на Python https://bhv.ru/product/setevoe-programmirovanie-na-python/
И вроде неплохо все изложено. Но а) Питон — осваивать придется самому
б) все равно неясно, что в качестве лаб давать.
3. Go. Есть стандартная библиотека
На русском практически ничего нет.
На английском довольно много. И есть документация.
Для меня — число психологически предпочтительнее Питона, но что давать в лабах — понятия не имею.
4. JS/TS + Node.JS
Ну, тоже лучше питона, но менее приятно, чем Go
В общем, основной вопрос: чего давать в лабах.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Но студенты зададут вопрос: а зачем nginx, IIS и проие всякие апачи, если сервер надо писать самим7
А зачем самому играть в футбол, если можно по телевизору посмотреть чемпионат высшей лиги?
LVV>Для меня — число психологически предпочтительнее Питона, но что давать в лабах — понятия не имею.
Моё ИМХО, неплохое начальное упражнение — написать на сокетах (а не на стандартной библиотеке) HTTP сервера и клиента. Начинаешь лучше понимать многие вещи.
На уровне HTTP/1.1, 2.0 трогать не надо, там совсем другая игра.
Язык — на усмотрение исполнителя.
А дальше можно развивать. Например, как передавать БОЛЬШИЕ файлы? Всасывать всё в память или сделать streaming-mode передачу тела сообщения? А как передавать видеопоток, у которого нет конечной длины? Как реагировать на разрывы соединения? Запустили стриминговый клиент в лабтопе, крышку закрыли, через полдня открылы, а ему понадобилось еще полдня чтобы понять, что соединение уже тогось. Кто виноват и что делать?
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 сюда вписывается ?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, 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 сюда вписывается ?
LVV>В общем, основной вопрос: чего давать в лабах.
1. написать telnet клиент. Спека простенькая UI минимальный.
2. SOCKS proxy со снифингом/фильтрацией/подменой траффика.
3. классика — клиент-серверный мессенджер.
LVV>Но студенты зададут вопрос: а зачем nginx, IIS и проие всякие апачи, если сервер надо писать самим7
вот тут наглядно покажете студентам как их самописный сервер умирает от 1к клиентов
4. HTTP. У многих есть открытый HTTP API. Реализовать какую-нить извлекалку данных. У желтого банка можно котировки акций, например. У многих игрушек (Танки, Ева, WOW) есть АПИ тоже можно что-нить простенькое написать.
Здравствуйте, LaptevVV, Вы писали:
LVV>Пара книжек есть: Таненбаум и Олиферы. LVV>Вроде все, что там без программирования нужно рассказать — там есть.
У.Р. Стивенс. UNIX: Разработка сетевых приложений. Там всё по TCP/IP. Актуально до сих пор практически целиком. Под винду тоже. В принципе, не знаю, зачем нужны ещё какие-то книжки...
LVV>В общем, основной вопрос: чего давать в лабах.
Здравствуйте, 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.
Здравствуйте, 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>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.
Блин!
Ты ж можешь прямо учебник написать!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, 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. Но это всё такие мелочи.
