Редактирование: UNИX, осень 2008, 01 лекция (от 01 октября)

Материал из eSyr's wiki.

Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.

ПРЕДУПРЕЖДЕНИЕ: Длина этой страницы составляет 37 килобайт. Страницы, размер которых приближается к 32 КБ или превышает это значение, могут неверно отображаться в некоторых браузерах. Пожалуйста, рассмотрите вариант разбиения страницы на меньшие части.

Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.

* '''Аудиозапись:''' http://esyr.org/lections/audio/uneex_2008_winter/uneex_08_10_01.ogg
= Лекция =
== Вступление ==
О лекторе:
* Георгий Владимирович Курячий
* Работает на факультете в лаборатории программного оборудования, следит за почтовым сервером.
* Не знает, что такое программное оборудование.
* Также работает в компании АльтЛинукс, занимается образовательными проектами.

О курсе:
* Помимо спецкурсов проходит семинар, сходный, но чуть более профессиональный. Название общее.
* http://uneex.ru/ (Спасибо Е. Сыромятникову за зарегистрированный домен)
* 4 года назад был аналогичный спецкурс.
* Этот курс наполовину будет посвящен TCP/IP, наполовину Linux-специфичный.

// За дверью в П-5 что-то, принадлежащее экономфаку и опечатанное его печатью.

Если пятна на Луне сложатся удачно, будет рассказ про межсетевые экраны.
Если пятна сложатся в другую конфигурацию, будет рассказ про IPv6.

// «Фактически на диктофон позвонили».

== Стек протоколов ==
Не мог понять, что за стек протоколов, почему их 5, а в ISO/OSI вообще 7, почему нельзя передавать по одному протоколу.

'''Задача.''' Требуется обеспечить связь между компьютерами во Вселенной. Ничего не знаем об интернете. Что мы должны сделать, чтобы передавать данные между компьютерами?

=== Пункт 1. Среда передачи данных ===
'''Проблема.''' Допустим, у нас есть компьютер-отправитель и компьютер-получатель. Есть некий «эфир» между ними. Что это за «эфир»?

'''Пункт 1.''' Нужно договориться о среде передачи данных.
Вопрос весьма непростой и ответы бывают весьма разнообразные.
Есть возможность передавать данные в обе стороны и питание по одному проводу.
Есть возможность и вообще без проводов передавать данные.

Витая пара — классический способ передачи данных на сегодняшний день.
Пусть мы изготовили соответствующую СПД.
Задача все еще не решена, т.к. провод мы в компьютер не воткнули.

=== Пункт 2. Подключение к СПД ===
'''Проблема.''' Стоит вопрос, как присоединяться к СПД.
Термин «подключение» некорректно использовать.
Но за неимением лучшего будем использовать.

'''Пункт 2.''' Как осуществлять подключение компьютера к данной среде.
У нас есть сигнал, нужно перевести его в нолики и единички.
Второй пункт дробится на две задачи.

'''Пункт 2.1.''' Какой должна быть розетка.
Раньше был нуль-модемный кабель.
Если среда подразумевает подсоединение нескольких абонентов, нужно решить вопрос, как определять, кто передает данные, твои ли данные сейчас передаются.
Если в качестве абонентов в СПД более, чем два устройства, сразу возникает вопрос о дисциплине передачи.

'''Пункт 2.2.''' Как друг друга различить и как друг другу не мешать.

Конкретный провод втыкается в конкретный компьютер с помощью сетевой карты.
Если к данной СПД подключено несколько абонентов, они знают, как передавать данные, не мешая друг другу.
Чего не хватает?

=== Резюме по первым шагам. Размеры сетей ===
При подключении доп. абонентов безопасность падает.
Будем считать, что мы ничего не можем сделать с безопасностью, раз уж изначально не позаботились.
Оптимизации не касаемся.

Существуют задачи, которые от начала до конца решаются на этих двух уровнях.

Все это очень хорошо работает, если СПД одна.
Компьютеров будет не очень много, пусть 10, пусть 100.
Чем больше абонентов, тем больше шансов, что один из них превратит СПД в месиво.
Есть зона ответственности.
Если передавать данные в Лос-Анджелес, получается что-то не то, да и провод слишком длинный.

Далеко не все компьютеры видят все компьютеры.
Мы имеем дело с неким графом.
Граф получается сложный. В нем могут быть звезды, шины и т.д.
Мы решаем задачу в рамках того, что называется '''локальная''' сеть.

Некоторые учебники: ''сети бывают локальные, районные, городские и глобальные''.
Лектор прочитал это с ужасом.
Не верьте.
Сети бывают '''локальные''' и '''глобальные'''.
С точки зрения того, какие задачи нам нужно решать, есть два варианта — абоненты подключены к одной СПД, и к разным.

=== Пункт 3. Кто все эти люди ===
'''Проблема.''' Как только мы начинаем иметь дело с совокупностью СПД, возникает вопрос «Кто все эти люди?».
Отправитель должен знать, кто есть получатель.

'''Пункт 3.''' Идентификация абонентов сети (назовем ее глобальной), а также маршрутизация.
Теперь мы можем доставить любые данные из одной машины в другую.
Мы договорились о правилах пересылки между различными СПД.
Чего не хватает?

Первый подход — сеть с разделением каналов.
Есть канал, который способен надежно передать данные.
Абонент обращается к сети и запрашивает канал к другому абоненту.
Каналов становится на 1 меньше, никто другой этим каналом пользоваться не может.
Никто до этого абонента достучаться не может, передача идет между двумя абонентами.
Аналог — телефонная сеть.
Можно купить 5 каналов и разговаривать 5 ртами и 5 ушами.
Про это говорить мы особо не будем.
Такие вещи возможны только когда у нас сравнительно немного абонентов в СПД и они относительно редко осуществляют передачу данных.
Существует проблема исчерпания каналов между телефонными станциями.

Второй подход — сеть с разделением пакетов.
Ограничение на объем единовременно передаваемых данных.
Если нужно передать больше, чем один пакет, передаем их много.
Есть управление передачей пакетов — можно сейчас передавать данные по среде или нет.
Условно — канал один на всех, но сами данные режутся на части, именуемые пакетами.
Эти пакеты передаются по СПД в определенное время.
Главное отличие от первого подхода — речь идет о постоянном обмене данными между абонентами.
Если среда занята — чуть-чуть подождем и передаем.
А в Бутово бывает невозможно дозвониться в течение 3 часов.
Говорить о гарантированном времени передачи не приходится, хотя очень хочется.
Будем говорить о сетях с разделением пакетов, потому что уже на уровне 2 практикуется использованией сетей с разделением пакетов.

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

=== Пункт 4. Потоки данных ===
'''Проблема.''' Отправитель отослал несколько пакетов.
Получатель получил не все.
Должно быть предусмотрено место, где написано, что это первый пакет, это второй, а это третий.
Задача не решается средствами третьего уровня.
Нужно ввести понятие потока данных, внутри которого возможно понять, какой кусок данных за каким следует.
Также возможна проблема дублирования пакетов.

'''Пункт 4.''' Потоки данных.

'''Пункт 4.1.''' Обеспечить надежность, чтобы данные, которые ушли, они же и пришли, чтобы они не попортились, не пропали. Сюда относится и целостность.

'''Пункт 4.2.''' Манипуляция потоком данных.
Мы должны отличать несколько потоков данных, которые идут от одного абонента к другому.
Также возможна ситуация, когда у отправителя быстрый компьютер и быстрая сеть, а у получателя медленный пентиум и медленная сеть.
Кто угодно может передавать что угодно кому угодно.
Что еще нужно?

=== Пункт 5. Интерпретация ===
'''Проблема.''' Мы хотели передать данные, а не цепочку из 0 и 1. 
'''Пункт 5.''' Интерпретация полученного сообщения.

== Свойства системы уровней ==
=== Свойство 1. Независимость уровней ===
Если мы решили задать, каким образом данные передаются по среде — привязываем к лапке голубя, передаем сигналом по проводам и т.п., —
то, когда встает задача посмотреть, как интерпретировать данные, можно забыть, что среда передачи была голубем, проводом, радиоканалом и т.д.
Есть протокол Ethernet, который может использовать много разных вещей — толстый и тонкий коаксиал, витую пару и т.д.
У некоторых умельцев «свои способы» обжимки витой пары с перекрестным использованием.
Гигабитная карта работать откажется.
У витой пары 6 категории отдельные пары выложены на «полочки», то есть там гарантировано разделение пар.
Если есть Ethernet, то как он реализован на уровне 1 — не важно.
Поднимемся на уровень выше, где происходит идентификация абонентов глобальной сети.
Среды передачи данных разнородны, но у каждой машины есть свой адрес, и есть алгоритм маршрутизации.
И это не учитывает, что есть разные СПД.
Пользуясь Интернетом, мы задействуем целую пачку различных сред: ADSL, кабель, спутник, кабель оптоволоконный на дне океана и пр.
Мы пользуемся одним протоколом, не думая, как бегают пакетики.

Речь идет о контроле потоков данных.
Нам не важно, как шли пакеты.
У IP есть отправитель и получатель.
Когда мы переходим на уровень интепретации данных, не важно, как они получены, хоть из файла, хоть набитые руками.

Мы говорим о сети с разделением пакетов, и не важно, что на каждом уровне пакеты — разные сущности.
Есть среды, например ATM, где есть понятие пакета.

=== Свойство 2. Инкапсуляция данных ===
Рассмотрим Ethernet.
На аппаратном уровне — 8 проводов.
Используется дифференциальный манчестерский код.
Передаем реально высокий и низкий уровень сигнала.
А нужно передавать пакеты.
Когда мы принимаем решение о передаче пакетов, нужно обеспечить, чтобы непрерывный поток нулей и единиц дробился на пакет.
Мы уславливаемся о наборе нулей и единиц, которая будет означать, что это пакет.
Будут и другие поля, о которых лектор не помнит.
Например, будет конец этого пакета, длина, контрольная сумма, должен быть идентификатор адресата.
Таким образом к нашей цифре 3, которую мы передаем, добавляется много служебных данных — маркер начала фрейма, получатель, адресат, контрольная сумма, длина и прочее.
Они либо паразитные, либо служебные, в зависимости от того, что мы хотим.
Такая же штука происходит, когда мы переходим на следующий уровень.
Мы хотим передать что-то по проводу, к этому чему-то мы прилепляем идентификатор начала фрейма (это даже не нули и единицы, а что-то другое) и прочие служебные данные.
Только внутренняя часть является полезной информацией.
Рассмотрим ее.
На третьем уровне (сетевом) у нас есть опять же отправитель и получатель (уже в глобальной адресации) и другие служебные данные, а также payload — полезные данные.
На четвертом уровне опять же есть служебные данные — идентификатор потока, пакета в потоке и прочая служебная информация, и опять payload — полезные данные.
Даже в них есть служебные данные.
По дороге в провода на нижний уровень на них налипло много всего.
Это свойство — инкапсуляция.
Посередине данные попилили на куски, которые потом надо собрать.

== Итог ==
Два фундаментальных свойства сети с разделением пакетов — независимость уровней и инкапсуляция данных (связано с первым) — при переходе на уровень ниже добавляются служебные данные этого уровня. Также есть декапсуляция — инкапсуляция наоборот.

Лектор взял на себя смелость изобрести стек TCP/IP по-новому.

* Первый уровень — аппаратный. В курсах Cisco (CCNA и др.) он игнорируется.
* Второй — интерфейсный (MAC).
* Третий — сетевой.
* Четвертый — транспортный.
* Пятый — прикладной.

ISO/OSI — альтернативный стек протоколов, даже постоянно обновляется.
В нем 7 уровней.
Принято считать, что 4 уровень разделяется на 2 — это '''неправда'''.
TCP/IP '''нельзя''' попилить на уровни ISO/OSI.
Была даже одна реализация ISO/OSI.
Потом им стало стыдно.

В следующий раз будем говорить о средах передачи данных.

= Конспект [[Участник:ESyr01|eSyr]] =
<div style="font-size:50%">
UNИX, uneex.ru

Есть лекции, есть семинар.

4 год нзд был нлогичный курс, з эти 4 гд изменилсь сравнительн немнго, тем не менее, лектор пстрется сделть тк, чтобы половина курса была посвящена TCP/IP, с другой строный, курс был достточн линуксоспецифичным.

Что ксется сегодняшней лекции, лектоор не хотел бы нзывть ни одной вещти из TCP/IP, поскольку необхдимо прояснить некий фкт, почему 5 протоколов, пчему ни вложены друг в друга, в ISO/OSI их вобще 7, почему нельзя использовать один пртокол, а не 7.

Предположим, чт нш здч сстоит в том, чтбы нлдить связь между произвольным числом компьютером н Земле, во Вслееенной, при этом, ничего не знем о том, что быфло прделно до нас ребятми из arpA. Для нчл нужн договоритьмся о том, кк эти данные передавть. У нс есть дв кмпьютер, и между ними есть ткй межзвёздный эфир, и неизвестно, мжет ли он передвать днные или нет. Поэтому предже чем передвть днные, необх. договориться, посредством чего они передются — договориться об СПД. Между прочим, эт вопрос довольно непростой, и ответы н него довольно рзнообразные. Нпример, посредством несколькихз проводов. В конце концов,Ю привязывть зписки к голубям. Н смм деле, это рзщгвор непростой, с другой стороны, в лее очевидных случяях это более-менее понятн. Нпример, если мы имеем коксил, т это устроено тк: тм стоит высокочстотня влн, и тм ккой-то модуляцией иджут данные, н это не вжно, вжн, что мы договорились о среде.

Рзумеется, псле того, кк в голову пришл идея, что можно передвть днные, и дже если нлдили СПД, то здч передчи днных не решена. Хотя бы потому, что мы его в компьютер не воткнули. Т есть, теперь встёт вопрос, кк боненты сети компьютерной будут подсоединяться к этой СПД. Подключение к среде. Тут решется две здчи н смом деле: у нс есть бстрктня СПД и бстрктный кмпьютер, вопрс, кк преобрзуется то, что идёт по СПД в то, что понимет компьютер. Это здч тй чмой розетки — кк сделть так, чтбы днные в СПД стли доступны компьютеру. Другя здча: склоько кого род устройств будет пдключено по СПД? А в кком порядке и кк опр. прядок передчи днных по сети? Потому что нверняк возникнет ситуция, что если два бонента зхотят что-то передть, то ни не смгут этого сделть, или смгут, но по опр. првилам. Или если днные пробегют мимо, то они твои или не твои? Если есть блее двух компьютеров в сети, возникет вопрс о дисциплине передачи.

Тут лектор здст вопрос:  может мы уже решили здчу? Мы уже много чего сделли: договорились о том, что некий првод втыкется в некий компьютер посредством стеевй крты. Блее того, мы решили более сложную здчу: ждоговорились о тм, что если пдключено несколько бонентов, т они смогут передвть днные между сбой, не мешя друг другу. Чего нм не хватает?

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

При этом понятно, что компьютеров в дной СПД может быть немного. Т. О. мы решили только задачу передчи днных н небольшие рсстояния, с неблоьшим количеством точек и в рамкх одной зоны ответственнсти. В результте мы будем иметь део не с дной СПД,  с пучкм связнных друг с другом. В рельнсти мы имеем дел не с дной СПД,  с грфом СПД. Кк передвть днные между СПД? Эти СПД будут нектрым спец. устрйством объединены. Нш здч — нучиться передавть днные с призвльного кмпьютер н призвльны.

Фктически, на уровне 2 мы решили здчу "локльные сети".

С точки зрения того, ккие задчи прихдится решть,  не с тчки хрения того, ккого рзмер сеть, локльные сети подкл. к единой среде,  кк только политика нелок., и приходится пересылть между рзными СПД и взн. небх. в коммутаторах. Как только мы нчинем иметь дело с совок. СПД, у нс срзу встёт дв вопрос: кто все эти люди? Т есть, если мы хотим передть данные из одной СПД в другую, мы олжны тчно знать, кт есть целевя мшин. У нс возн. прблем идент. всех бонентов сети. Пмимо идент. бонентов взн. впрс, как оствить днные от дного бонента друшгому, еслип пр него неизв. прктически ничего. То есть, взн. вос=прс о мршрутизтрх. У здчи марш. есть одн пикнтная пдрбность: нахдясь в одной СПД, нельзя никак повлиять на о, что пкет идёт через опр. мшины в других СПД.

Теперь мы смгли доствить днные из одной СПД в другую. Дсттчно ли этого? Чего не хвтет?

Не хвтет сущей млости — уверенности плучтеля в тм, что плучил т, что отпрвили и всё, что нужно.

Здесь нужно сделть одно отступление? кгд говрят о СПД, есть дв пдхд к тому, как эти днные передются. Первый — сеть с передчью кнлоов. Есть рельное устр. — кнл передчи днных, которое дост. ндёжно, чтбы передвть всё, что небоходим. Кк тлько у одного бонент взн. небх. чт-то передть, он арендует канал, кличество достуных уменьш н единицу, и дльше абонент беззстенциво им пльзуется. чень похоже функцинирует телефоння сеть.

...  пр это мы оворить дже не будем. Ткие вещи возм., когд у вс срвн. немного бонентов в СПД, и эти боненты срвн. редко осущ. передачи данных. Прблемы: количество кналов огрничено. Ну и это довольно дорогост. штука.

Поэтому те рх., котрые будем рссм., основны н рзделении пкетов. В чём смысл: для начл вводится огр. на однокр. бъём перед. днных (пкет). В случе, если ндо больше днных передвть, передёте пкетов много. При этом, тто фкт, что передв дин пкет, начинете передвать другой, пр. дисц. передчи в СПД. Или сущ. некий сигнал, услышв кторый мжете передть сигнл, если того хотите. Или дисфиплин передчи днных предусим. неий лг. определения. Условн говоря, кнл одиин на всех, и пкеты передются по СПД в опр. дисциплине. Глвне отличие в лучшую строну состоит в том, что (в осбенности, если речь идёт о дост. пост. бмене днными) если лько если все хотят все передвть, возм. передчи будет. В тличие т среды с разд. кналов.

Главный недстток: при том вы не гр. чётке мкс. время передчи. Пкет идёт микросекунды, но мжет кзться тк, чт кнал знят, и придётся ждть целую секунду.Тем не менее, говорим осреде коммутции пакетв.

Абнент должен быть уверен, чт ему плслли т, чт послли, причём это не просто контр. сумм,  горздо более серьёзня штука. Вот нм отпр. 4 пкет, а плоучтель получил 1,2,4. Н урвне маршрутизции эт задч не решется вообще никак, пскольку нет понятия пток днных. Сответственн, нд их ввести.

Тут на смом деле две разл. здчи взн. Первая здач: вообще обесп. надёжность, те днные, котрые ушли, ни же и пришли: чтбы днные не ппортились, не прпли... целостнсть. Втря задач: уметь мнип. пресл. потоком днных. Напр., дин отпр. получ.передёт файл и псылет письмо. По ккому признку будет отл. файл от письма? Сюд же нкл. след. наблюдение: если с дной стороны мшин быстрая, СПД быстрая, с другой стороны унылый пентиум н унылм мдеме. И вт отпр. льёт мегбйтми днные, и получатель его килобйтами читет. Куда деваются ост. днные?

В очередной лектр здст впрс: мжет мыр рзбрались с здчей передачи данных между абнентм и получ в призв. сети? Д, тльк непонятно, ккие данные.

Лектор произнёс слово почт, кртинка и тк длее, и проблем в тм, что потоки надо как-то интерпретировть. В самомд еле, непонятно, чт это за данные, и из тог, чт потоку был присвоен номер 1, не озн., что это была картинка. И эта задча выходит за задчу перед. данных по сети. Т, как С будет днные интерп. не зависит от того, кк мы их передём.

Прежде, чем нпишем прпвильные слов, рссм. дв вжных свойств след. из этй структуры: 
# Незвисимость урвней. Если мы решили здчть, кким бразом передаются данные по нашей среде, нпример, привыязывть к нжке глубя письм, или кдировть 0 и 1 и пускть п проводам, отчсти решем здчу рзетки. Когда у нс встаёт задча сбственно посмтреть, кк компьютер должен интерп. то, чт пришл из СПД, мжем ссмело збыть, чт был з СПД. То есть в тт ммент, когда присх. переход н второй урвеньт, мжем збыть пр первый. Нпр., есть Ethernet, 	и он в кчестве СПД мог использвть разныек среды. Если мы даже дговор. что здесь у нас вплне пор. спомоб рбты с сетью, т т, кк тт езернет  первом урвне, не очень волнует.

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

Теперь речь идёт  тм, чт небх. кнтр. птоки днных. Тут с этой нез. некрые прблемы. Они хзрктера чисто теор., в некторых умозр. архитектурах они решены, в TCP/IP не очень. Когда мы передём поток данных, нам не важен их маршрут. Это обесп. незвисимость.

Мы бесп. рзделение пакетов, и н каждом из этих урвней	 пкетм будет наз. рзня сущность.

Рассм. тот же езернет. Лектор боязливо соврёт, что нличие напр. озн. единицу, тсутствие — 0. Но когд мы гворим, что по этой среде должны пердвться пкеты, когд в этой среде ..., мы должны кким-то образом беспечить, что вот этот поток 0 и 1 делится на пкеты. Некя спец. посл. 0 и 1 озн., что дльше пйдёт фрейм. Она не явл. днными, кторые мы передём, это некая дополн. нагрузка.: нчало фрейм, длин, контрольная сумма, дресат пакет. То есть к нашей одной цифре прибавляется неск. доплнительных, служебных днных.

Мы хотим передать что-то. То к этому чему-то прилепляем оверхед, чтобы эт инф. на блее низком урвне тв. з передчу днных. Т же присх., когд мы берём данные, предн. для рботы в сети и зпих. её в СПД. Тм точно также есть payload и overhead. В случе, если уже речь идёт б элементе урвня сетевого. Здесь уже написны тпр. и адресат в смысле глоб. сети (IP, гворя русским языком). Н уровне потоков днных та же истрия: номер поток днных, длжен быть идент. пакета в потоке, мнго всякй инф. и payload. И н урвне прикл. тоже есть сви зголовки.

В итоге мы хотели передать столько днных,  по пути к проводам н них налиплоо много разных днных служебных.

Первое фунд. свйство — нез, уровней, второе — инкпс. днных, то есть при переъхде на более низкий уровень добвл. днные, тв. за перед. днных именн на этом уровне.

Для того, чтбы зк. эту тему, назовём вещи своими именми:
# Аппаратный
# Интерфецйсный уровень
# Сетевой
# Трнспортный
# Приклдной

Ровно тк нз. урвни в стеке TCP/IP, кторый собст. сетевыми пртоколми явл. с интерфейсного. Именн тк он и релизован.

Лектор срзу скжет, что помимо TCP/IP есть ещё ISO/OSI, он был стандртом.

В ISO/OSI семь урвней, не 5. И его нельзя попилить на уровни TCP/IP, тм немнжко не так.
</div>

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. eSyr's_wiki:Авторское право).
НЕ РАЗМЕЩАЙТЕ БЕЗ РАЗРЕШЕНИЯ ОХРАНЯЕМЫЕ АВТОРСКИМ ПРАВОМ МАТЕРИАЛЫ!

Описание изменений:

Отменить | Справка по редактированию (в новом окне)

Шаблоны, использованные на этой странице:

Получено с http://esyr.us/wiki/UN%D0%98X%2C_%D0%BE%D1%81%D0%B5%D0%BD%D1%8C_2008%2C_01_%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BE%D1%82_01_%D0%BE%D0%BA%D1%82%D1%8F%D0%B1%D1%80%D1%8F%29

Редактирование: UNИX, осень 2008, 01 лекция (от 01 октября)

Материал из eSyr's wiki.

Просмотры

Личные инструменты

Навигация

инструменты

Разделы

Спецкурсы

9 семестр

7 семестр

5 семестр

3 семестр

Поиск

Инструменты

@@ Строка 137: / Строка 137: @@
 === Пункт 5. Интерпретация ===
 '''Проблема.''' Мы хотели передать данные, а не цепочку из 0 и 1.
 '''Пункт 5.''' Интерпретация полученного сообщения.