Главная Учебники - Разные Лекции (разные) - часть 14
|
Министерство образования Российской Федерации Дальневосточный Государственный Университет
Институт математики и компьютерных наук
Кафедра математических методов в экономике.
«
Мировые информационные сети. Основные свойства, примеры и особенности
»
Выполнил студент 225 группы Мартюшев Алексей Проверил Адомавичюс Эдуард Альбертасович Владивосток
200
8
Информационная сеть - сеть, предназначенная для сбора, обработки, хранения и передачи данных. Классическая структура информационной сети состоит из двух основных компонентов: оконечных систем (А-Е) и связывающей их сети передачи данных. Оконечные системы могут выполнять функции серверов или клиентов. Кроме этого в сети работает одна либо несколько административных систем. Последние предназначены для управления функционированием информационной сети и поэтому часто называются центрами управления сетью. Все указанные системы являются объектами сетевого управления. Информационную сеть, которая объединяет открытые системы, принято также называть открытой информационной сетью. На базе одной физической сети можно также создать группу виртуальных сетей. Важной характеристикой является производительность сети. Характер функционирования информационной сети определяется с помощью анализаторов сети. Сеть, в которой работают системы различных типов, именуют гетерогенной сетью. Сеть с системами одного и того же типа называют гомогенной сетью. Люди, взаимодействующие с информационной сетью, именуются ее пользователями либо абонентами. В сети по мере надобности создаются закрытые группы пользователей. В зависимости от расстояния между оконечными системами, информационные сети подразделяются на несколько видов: глобальная сеть, региональная сеть, локальная сеть. Благодаря интеграции рассмотренных видов создаются смешанные сети. Информационные сети называют сетями общего пользования, если их абонентами могут стать любые лица. Выделяют наземные сети и спутниковые сети. В соответствии с используемой моделью, сети используют архитектуру клиент-сервер. Примером первой является системная сетевая архитектура. Ко второй относятся сети NetWare. Третью представляет базовая эталонная модель взаимодействия открытых систем. Важное значение в работе сети имеет ее информационное обеспечение. Информационную сеть, содержащую один либо группу серверов называют серверной сетью. Большинство информационных сетей являются универсальными. Между тем, существует и немало специализированных сетей. К ним относятся: сети библиотек, банковские сети. Создаются защищенные сети. Развитие сетей привело к появлению сетевого сообщества. Любая информационная сеть характеризуется предоставляемыми ею информационными ресурсами. Этой задачей занимается сетевая администрация. Наряду с государственными, муниципальными предприятия и организации создают частные сети. В качастве примеров для более детального изучения представленной тематики мною были рассмотренны следующие три мировые информационные сети. 1. Fidonet 2. Telnet 3. WeNet
Мировая информационная сеть Fidonet
Сеть была создана в 1984 году американским программистом — Томом Дженнингсом (англ. Tom Jennings) для передачи сообщений с его BBS на BBS его друга Джона Мэдила (англ. John Madil). Передача осуществлялась в ночные часы, когда стоимость телефонных звонков была ниже. Для обмена почтой с другим узлом сети был выделен один час (в течение которого доступ сторонних пользователей на BBS был закрыт), который позже получил название «национального почтового часа». Требование организации выделенного часа для обмена сообщениями сохраняется до настоящего времени (за исключением узлов, связанных с сетью не через POTS), хотя контроль за его соблюдением значительно ослаб. Вскоре число узлов сети стало возрастать и достигло 200 в начале 1985 года. Список узлов (нодлист, англ. nodelist) распространялся в виде отдельного файла и первоначально обновлялся самим Дженнингсом, а позже членами группы пользователей DEC из Сент-Луиса Кеном Капланом (англ. Ken Kaplan) и Беном Бейкером (англ. Ben Baker). Они же стали выпускать первый «новостной листок» сети Fidonet. Первоначально каждый узел связывался с другим узлом напрямую. С ростом числа пользователей сети существенно возросло число телефонных звонков, в том числе междугородних. В результате было решено сменить структуру сети с линейной на древовидную, сгруппировав пользователей по сегментам по географическому признаку. В результате адресация стала двухзвенной: вместо простого номера узла стала использоваться нотация сеть/узел. В конце 1986 года аналогичная проблема возникла на уровне континентов. Кроме того, появилась мысль организовать для пользователей BBS возможность получать почту с использованием форматов данных и протоколов Fidonet. На собрании Комитета по техническим стандартам Fidonet в октябре 1986 года была введена четырёхуровневая иерархия списка узлов. Верхним уровнем была зона (континент), далее шли сеть, узел и точка (поинт, англ. point) сети. Схема адресации зона:сеть/узел.поинт продолжает использоваться и в настоящее время. Максимума своей распространённости Сеть Фидонет достигла в 1995 году, когда она насчитывала около 40 тысяч узлов. С тех пор популярность сети постепенно падает, и количество её узлов сократилось в несколько раз. В феврале 1986 года Джеффом Рашем (англ. Jeff Rush) была разработана система сетевых конференций, получившая название «эхопочта» (эхомейл, англ. echomail). Первой международной эхоконференцией стала конференция MODULA-2, распространявшаяся в Европе, Австралии и Северной Америке. В 1986 году также начали функционировать первые постоянные «гейты» между Fidonet и UUCP (то есть между Fidonet и интернетом). Символом-талисманом (англ. mascot) Фидонета является собака с дискетой в зубах. По легенде, «Фидо» — это кличка собаки основателя сети, Тома Дженнингса. На самом деле никакой собаки у него не было; но «Фидо» — это действительно собачья кличка, такая же распространённая в Америке, какой на территории бывшего СССР является, например, «Шарик», «Бобик» или «Тузик». Название сети Том Дженнингс взял из первого попавшегося ему на глаза слова, которое было написано на наклейке, приклеенной у него на мониторе. Первый узел сети Фидонет на территории России появился летом 1990 года в Новосибирске, его системными операторами были Евгений Чуприянов и Владимир Лебедев. Первоначально узел имел адрес 2:42/100, позже — 2:5000/10. Подключение в сеть осуществлялось через узлы, находящиеся в Чехословакии. В октябре—декабре 1990 года появились узлы также в Челябинске, Москве и Санкт-Петербурге, был образован 50-й регион сети. Во время событий августа 1991 года сеть использовалась наряду с Релкомом для рассылки информационных сводок из Белого дома. Число узлов сети в начале 1990-х годов быстро увеличивалось, поскольку подключение к сети не требовало значительных материальных затрат, а передача данных в пределах одного телефонного кода осуществлялась фактически бесплатно. Однако уже в конце 1990-х годов стало очевидно, что Фидонет не выдерживает конкуренции с другими компьютерными сетями и прежде всего с интернетом. В январе 1997 года один из старейших фидошников Дмитрий Завалишин в интервью радиостанции «Ракурс» так охарактеризовал перспективы развития сети: Я полагаю, что Фидо отпущено еще несколько лет активной жизни, после этого его наверно уже не будет видно на горизонте. И причины тому чисто технологические, а совершенно не политические. Фидо очень давно разрабатывалось, разрабатывалось непрофессионально и неудачно, это все, кто занимается им серьезно, знают хорошо, и это ограничивает его жизнь, его развитие. В полной мере эти тенденции проявили себя в 2000-х годах, когда отток пользователей из Фидонет в блоги и социальные сети в интернете приобрёл значительные масштабы. С падением популярности сети стали появляться идеи реформирования Фидонет. К их числу относится концепция «гипертекстового векторного Фидонета», предложенная Сергеем Соколовым, системным оператором узла 2:5063/88 (известным также под псевдонимом Mithgol the Webmaster). Она получила известность в связи с заданным в ходе проводившейся 5 марта 2007 года онлайновой конференции Дмитрия Медведева (который тогда занимал должность вице-премьера) от имени Сергея Соколова вопросом, касающимся сети Фидонет. Медведев ответил на вопрос, однако о поддержке данного направления разработок сказано ничего не было. По состоянию на апрель 2008 года программное обеспечение, реализующее основные положения гипертекстового Фидонета, такие как возможность простановки гиперссылок на адреса и сообщения, цветовое, шрифтовое и графическое оформление сообщений, так и не было представлено. Изначально для передачи данных в сети Фидонет использовалось прямое модемное подключение через телефонную линию, что отражено в Уставе и структуре сети. Фидонет является оффлайновой сетью, то есть сообщения и файлы распространяются по сети, в то время как пользователь может быть отключен от сети. Первоначально основным протоколом сети Фидонет являлся протокол передачи «сетевой почты» (нетмейла, англ. Netmail): индивидуальных электронных текстовых сообщений, содержащих имя отправителя и получателя, а также Фидонет-адреса каждого из них. В сети обеспечивается роутинг сообщений, так что отправителю и получателю сообщения не обязательно устанавливать между собой прямую («директную», англ. direct) связь. Тем не менее, возможность такой связи, при которой почта минует маршрут по умолчанию и административную иерархию, сохраняется и изредка используется, поскольку в таком случае обеспечивается гарантированная доставка почты получателю и сохраняется тайна переписки (поскольку обычно системные операторы транзитных узлов Фидонет оставляли за собой право просматривать проходящую через них личную переписку на предмет содержимого, нарушающего Устав Фидонет). Нетмейл позволял «присоединять» к каждому передаваемому сообщению один файл. Это позволило создать серию работающих поверх нетмейла протоколов, передающих информацию от одного узла к другому в прикрепленных файлах. Наиболее часто используемым из таких протоколов является эхопочта («эхомейл», англ. echomail), представляющая собой публичные конференции («эхоконференции»), похожие на группы Usenet. Первоначально эхомейл предназначался для сбора сообщений с публичных форумов местных BBS и передачи их в сжатом виде (для экономии времени; обычно использовались форматы ARC — отсюда «аркмейл» (англ. arcmail) или ZIP). Позже эхоконференции приобрели самостоятельное значение, став наиболее популярным протоколом обмена информацией в Фидонет. Кроме того, существовали также протоколы обмена бинарными файлами (файлэхоконференции — «файлэхи», англ. fileecho), однако в настоящее время эти протоколы применяются достаточно мало (вследствие распространения быстрых и дешёвых интернет-каналов и P2P-сетей). Фидонет не является частью Интернета. Однако в настоящее время каналы и протоколы Интернета довольно часто используются для передачи поверх них трафика Фидонет (с использованием binkp и аналогичных протоколов). Кроме того, большая часть эхоконференций сети Фидонет доступна пользователям Интернет через Usenet и WWW-гейты. Стандартная схема адресации в сети Фидонет описывается в документе FTSC FRL-1002. Стандарт предусматривает полную форму записи адреса (так называемая 5D-адресация — англ. 5D-addressing, использующая 5 полей сетевого адреса) и различные формы сокращённой записи, из которых наиболее часто используемыми являются 3D и 4D-адресации. 5D-адреса записывается в следующей форме: Zone:Net/Node.Point@Domain, где: i. Zone — номер зоны (от 1 до 32767). ii. Net — номер сети (от 1 до 32767). iii. Node — номер узла (от −1 до 32767). iv. Point — номер пойнта узла (от 1 до 32767). v. Domain — символьное имя сети (до 8 знаков). Из этих полей обязательными являются только Net и Node. Таким образом, возможны следующие сокращённые формы записи адреса: i. Zone:Net/Node.Point — 4D-адресация, имя сети по умолчанию fidonet. ii. Zone:Net/Node — 3D-адресация, опускается поле Point, которое у всех узлов сети имеет значение 0. iii. Net/Node — 2D-адресация, опускается поле Zone, для которого по умолчанию принимается значение 1. Значение номера узла «-1» используется для отправки запроса на получение сетевого адреса. Символьное имя сети используется достаточно редко ввиду маловероятности конфликтов адресации между парами зона‐узел у участников FTN-сетей, и наличия популярного ПО, не учитывающего домен при сравнении адресов. Устав Фидонета требует, чтобы каждый узел сети поддерживал в актуальном состоянии список всех узлов сети (нодлист, англ. nodelist). Формат списка узлов описывается стандартом Фидонет FTS-5000. Информация об узле, указанная в списке, включает в себя статус узла (для обозначения временно неработающих и недоступных средствами телефонии узлов), его номер и наименование (для узлов, доступных посредством интернет-протоколов — доменное имя, IP или E-mail адрес), географическое местонахождение, имя и фамилию оператора узла, номер телефона и флаги, указывающие на возможности программного и аппаратного обеспечения узла. Список узлов еженедельно обновляется. Координаторы каждой сети поддерживают в актуальном состоянии локальные списки узлов. Эти списки регулярно пересылаются вышестоящим координаторам, которые составляют общесетевой список узлов. Изменения в списке рассылаются (как правило, через файловые эхоконференции) всем узлам сети. По концепции Фидонета и по Полиси отправить письмо можно двумя способами: либо директом (то есть непосредственно получателю), либо сетевому координатору получателя, который обязан организовать дальнейшую доставку полученной им почты членам своей сети (обычно либо непосредственно, либо, в больших сетях, через хабы). Такая схема неудобна в сети с большим числом узлов и для передачи информации зачастую требует междугородных и международных телефонных вызовов. Ввиду этого обычной практикой стало заключение неформальных договоренностей между системными операторами о том, что один или несколько узлов сети принимают на себя функции по маршрутизации сетевых сообщений. Кроме того, на уровне зоны выделялись узлы, бравшие на себя функцию передачи почты в другие зоны (межзонные гейты — англ. zone gate). Часто системные операторы этих узлов также являлись одновременно координаторами своего уровня или крупными хабами, но это не являлось обязательным требованием. Выполнение функций такими узлами зачастую требовало значительных материальных затрат, поэтому в таких случаях могло вводиться разделение расходов между всеми узлами сети (англ. costsharing). Использовались и другие возможности: так, с ноября 1991 года передача сообщений между Европой и Северной Америкой, а с 1992 года и между другими регионами (Тайвань, ЮАР, Чили и т.д.) стала осуществлялась с использованием IP-каналов. В России подобные функции нередко выполняли узлы, чьи системные операторы использовали служебное положение для осуществления междугородних звонков без оплаты, в том числе через ведомственные сети (Искра-2, железнодорожная сеть). Такие узлы получили название «лонглинки» (от англ. long link). Фактически схема маршрутизации была иерархична, а количество горизонтальных связей было мало. Это позволяло обходиться без специальных технических средств, позволяющих организовать маршрутизацию сообщений. Однако с ростом количества узлов, а также с распространением IP количество лонглинков сильно увеличилось, что сделало традиционную схему роутинга неэффективной (по крайней мере, в российском сегменте сети). Кроме того, для повышения надёжности сети необходима была децентрализация роутинга с образованием так называемого «бекбона» (англ. backbone) сети. Для оптимизации схемы роутинга у узлов с большим количеством связей с другими узлами было предложено два решения: i. Протокол FRIP (расшифровывается как Fidonet routing information protocol) и одноимённая утилита, созданная Дмитрием Завалишиным, работающая по принципу «объявления» — каждый узел рассылает связанным с ним узлам объявления о том, что он готов принимать почту для некоего списка узлов (как правило, для самого себя и своих даунлинков). Получатели объявления продолжают рассылать его всем связанным узлам. Рассылка не происходит, если получатель объявления уже «знает» более короткий путь к целевому узлу. В результате должна быть автоматически построена карта роутинга, обеспечивающая доставку сообщений по наиболее короткому пути. В настоящее время этот протокол не используется. ii. Программа Hubroute generator (также известная как «сафроутер» — по имени создателя, Юрия Сафронова). Эта программа строит роутинг на основе общих для региона списка жестко заданных путей роутинга и списка «доверенных» узлов, принимающих почту для определённой сети (в российском Фидонет — R50.ROU и R50.TRU соответственно) с учётом данных об узлах, на которые данный узел может напрямую отправлять сообщения. Общерегиональные списки путей роутинга и доверенных узлов составляются региональным координатором на основании данных, которые ему присылают сетевые координаторы. Практически все основные протоколы и форматы, используемые в Фидонете, стандартизированы и записаны в FTS (FidoNet Technical Standards — технические стандарты Фидонета), их сбором и стандартизацией занимается FTSC (FidoNet Technical Standards Committee — комитет по техническим стандартам Фидонета). Исторически основным техническим стандартом Фидонет являлся FTS-0001, устанавливающий базовые требования, которым должны были соответствовать все системы. Стандарт описывает требования к реализации всех уровней протоколов обмена в соответствии с сетевой моделью ВОС, за исключением физического уровня. На канальном уровне для передачи данных использовался протокол XMODEM. FTSC также были приняты следующие основные стандарты и документы: i. FTS-0004: The Conference Mail System (EchoMail Specification) — описывает принципы построения системы эхоконференций ii. FTS-1024: Raw ifcico mail transfer protocol — описывает протокол ifcico, предназначенный для передачи данных через надёжные соединения (такие, как TCP/IP-каналы). iii. FTS-1026: Binkp/1.0 Protocol specification — содержит описание протокола binkp, применяемого для передачи данных с использованием TCP/IP. iv. FTS-5000: The distribution nodelist — определяет формат списка узлов сети v. FSC-0056: EMSI/IEMSI Protocol Definitions — описывает протокол установления соединения (хендшейка) EMSI. vi. FSC-0072: The HYDRA file transfer protocol — включает спецификации протокола передачи данных Hydra. FTSC также создаёт реестр программных продуктов, участвующих в обмене информацией в Фидонет (мейлеров и эхопроцессоров). Последний раз реестр обновлялся в январе 2005 года. Первой программой, включённой в реестр, является Fido Тома Дженнингса, ей присвоен код 0000; последней — трекер RNtrack с кодом 16FF. Фидонет имеет иерархическую структуру, описанную в пунктах 1.2.3—1.2.8 Устава Фидонет. Организационным объединением нижнего уровня является сеть, сети объединяются в регионы, а регионы в зоны. У каждого уровня есть свой координатор. Координаторы сетей и регионов (NC и RC — англ. Network Coordinator, Regional Coordinator) назначаются вышестоящим координатором, координаторы зон (ZC, англ. Zone Coordinator) избираются координаторами регионов. Координаторы зон являются членами Совета координаторов зон, решающего вопросы, касающиеся сети в целом. Председателем Совета является международный координатор (IC, англ. International Coordinator). Международный координатор является гарантом законности проведения выборов и референдумов в сети, оглашает решения Совета, а также выполняет функции по составлению общемирового списка узлов. Международный координатор выбирается Советом координаторов зон. Процедура выборов всегда вызывала большие разногласия, вследствие чего этот пост часто оказывался вакантным. В 2000 году международным координатором был избран Z2C (координатор зоны 2) Вард Досше (нем. Ward Dossche). В 2004 году совет координаторов зон заявил о смещении его с поста и о избрании международным координатором Z3C Малькольма Майлса (англ. Malcolm Miles). Досше не согласился с этим решением, указав, что голоса при выборах должны распределяться не по схеме «один координатор — один голос», а в зависимости от числа узлов в соответствующей зоне. При такой схеме ему, как координатору самой большой, второй зоны, должно было принадлежать 89 голосов, а всем остальным координаторам в сумме — 11 голосов. Следствием этого стало параллельное существование двух международных координаторов: избранного советом координаторов Малькольма Майлса и Варда Досше, который отказался уходить с поста. Координаторы могут делегировать часть своих полномочий другим узлам. Обычно делегируются полномочия по организации доставки эхоконференций (сетевому или региональному эхокоординатору — NEC или REC) и файлового трафика (сетевому или региональному файлэхокоординатору — NFEC или RFEC) В сеть (англ. network) объединяются узлы, находящиеся в одной локальной географической области (городе или регионе), обычно в пределах одного кода междугородной телефонной сети. Не существует единого подхода к нумерации сетей, общепринятого во всей Фидонет. В зоне 2 (Европа) номер сети часто включает в себя номер региона (например, номер сети 5020 (Москва) включает в себя номер региона 50 — Россия). В небольших регионах для номера сети используется одна значащая цифра, в более крупных — две. В последнее время в связи с нехваткой номеров для сетей эта схема нарушается: так, в регионе 50 существует несколько сетей, номер которых начинается на 60: например, сеть 6035 (Железногорск). В зоне 1 используется другой подход: в качестве точки отсчёта для нумерации сетей в регионе принимается значение номер региона × 20, а в больших регионах номер региона × 200. В регион (англ. region) объединяются сети, как правило, находящиеся в пределах большой географической области. Например, в регион 17 первой зоны объединены сети, находящиеся в на северо-востоке тихоокеанского побережья США, в Аляске и северной Канаде, а в регион 46 второй — на Украине и в Молдове. В состав региона могут входить также независимые узлы, которые не включены ни в одну сеть вследствие отсутствия других узлов в данной местности или конфликта с членами существующей сети. В зону (англ. zone) объединяются несколько регионов, как правило, находящихся на одном континенте. В настоящее время существуют пять зон: i. Северная Америка; ii. Европа, страны бывшего СССР и Ближнего Востока; iii. Австралия и Новая Зеландия; iv. Латинская Америка; v. Африка. До мая 2007 года существовала также шестая зона (Азия). Она была расформирована, оставшиеся узлы были перенесены в третью зону. В 1992 году часть российских сисопов выступила с идеей о выделении России, а также всего постсоветского пространства, в новую седьмую зону, однако это не было проделано в силу разногласий. В конце 2005 — начале 2006 года в российском регионе Фидонета (2:50) проводился референдум по вопросам выделения в седьмую зону, по результатам которого также не было выработано какого-либо конкретного решения. Участников Фидонет можно разделить на три группы: i. Узлы или ноды (англ. nodes), которые являются полноправными членами сети и включены в список узлов. Устав Фидонет предусматривает обязанность узла соблюдать процедуры, предусмотренные для почтового обмена (в частности, принимать адресованные узлу сообщения в течение зонального почтового часа). Ноды отвечают за содержание всего трафика, попадающего в сеть с их адреса, независимо от того, какой из конкретных пользователей его разместил. Ноды имеют право осуществлять любую деятельность в рамках сети, которая не противоречит Уставу Фидонет и не раздражает других членов сети. ii. Поинты (англ. points), которые используют программное обеспечение Фидонет, но не включаются в список узлов и не обязаны соблюдать процедуры почтового обмена. Для приёма и отправки сетевой почты и эхомейла они пользуются услугами узла (босс-ноды, англ. boss-node), который берёт на себя ответственность за все действия поинтов. В некоторых зонах (в частности, в зоне 2) число поинтов многократно превышало и превышает число узлов, достигая 120 000. В настоящий момент в зоне 2 сохраняется около 50 000 поинтов. iii. Пользователи (англ. users) не имеющих прямого отношения к Фидонет сервисов, предоставляемых одним из узлов. Пользователям может предоставляться доступ к отдельным транспортам Фидонет путём трансляции (гейтования) сообщений из внешней сети в Фидонет и обратно. За все проявления активности пользователей в Фидонет несёт ответственность предоставивший доступ узел. Изначально положения, касающиеся пользователей, распространялись на лиц, использовавших терминальный доступ к BBS, действующей параллельно с узлом Фидонет, позже они стали применяться также к пользователям гейтов Интернет ↔ Фидонет. Для функционирования узлов сети используется комплекс специфического программного обеспечения. Набор программного обеспечения практически не отличается для конечных пользователей и для крупных раздающих узлов. С одной стороны, это создаёт некоторый барьер для новых членов: для вступления в Фидонет нужно обладать определённой технической грамотностью, чтобы установить и настроить фидошное программное обеспечение. С другой стороны, отсутствие необходимости специфического оборудования, платформ, сложного и дорогого программного обеспечения для организации раздающего узла делает сеть Фидо гибкой и устойчивой: в случае падения хаба (крупного раздающего узла) его технические функции вполне может взять на себя любой другой узел, согласный на это. В настоящее время появилось множество самонастраивающихся пакетов программного обеспечения, призванных облегчить установку и настройку комплекса программ для новых пользователей.
Мировая информационная сеть WeNet
Сеть WeNet возникла из желания создать русскоязычную сеть, имеющую поддержку русских ников и каналов, перекодировок как по портам, так и налету, но не имеющую недостатков и глюков сети RusNet. Сеть создали бывшие администраторы irc-серверов, входивших в составсети RusNet. В начале мы использовали rusnet ircd, внеся туда ряд улучшений и изменений. Так появился сервер wenet-1.0. Далее этот ircd развивался и обростал новыми возможностями, но в последствии, из-за морально устаревшей основы кода сервера (hybryd 2.9.3), было принято решение разработать свой собственный ircd, с полностью переделанными механизмами перекодировок и поддержкой современных функций ircd. Так был взят за основу ircd сети DALNet - bahamut. На базе кода bahamut, мы разработали сервер wudan, который в последствии стал называться ircd-RU!. 1. Информация о сети, возможностях, расширениях, сервисах, планы на будущее: 1. поддержка нескольких кодовых страниц (на данный момент - CP1251, KOI8-R, KOI8-F, TRANSLIT, CP866, ISO8859-5); 2. поддержка 8-битных ников и имен каналов; 3. поддержка чувствительных и нечувствительных к регистру ников и имен каналов; 4. раскладка кодовых страниц по портам; 5. смена пользователем кодовых страниц на лету; 6. оптимизация осуществления клиентских и межсерверных перекодировок; 7. удобные средства контроля и управление всеми возможностями поддержки русского языка; 8. расширенные возможности для управления доступом на каналы. Кроме списка +b (bans) и +e (exceptions), есть еще три списка: 1. +B (extended bans) - баны на маски вида nick!user@host:server. При проверке пользователя на право использования канала также играет роль сервер, с которого пользователь находится в сети. Может применяться для того, чтобы запретить на доступ на канал всем пользователям одного или нескольких серверов. 2. +E (extended exceptions) - исключения из банов для масок nick!user@host:server. 3. +X (exclusions) - определение эксклюзивного доступа к каналу, маски nick!user@host:server. Очень полезная возможность для локальных компаний, существующих в рамках одного или нескольких серверов. Если на канале установить список +X *!*@*:irc.somelocalserver.net, то канал будет доступен только пользователям этого сервера. При таких условиях работают и все остальные механизмы ограничения и выдачи доступа к каналу - баны, исключения из банов, расширенные варианты банов и исключений, приглашения (/invite). 9. расширенные режимы каналов, такие как: 1. 7 - не разрешать заход на канал клиентов с 8-битными никами; 2. x - не разрешать заход на канал клиентов с никами, состоящими одновременно из символов латинского и национального алфавитов; 3. w - не разрешать заход на канал клиентов с никами, содержащими слова, состоящие одновременно из символов латинского и национального алфавитов; 4. e - список исключений из банов, имеет такой же формат, как и +b channel mode, маски nick!user@host. 10. Сервер защищает пользователей и каналы от CTCP флуда, флуда сменой ников. 11. В следующей версии сервера появится возможность ограничения использования канала для клиентов с открытых прокси различных типов. 12. сервисы по своим видимым пользователю возможностям очень похожи на остальные. Но и имеют наши собственные удобства - отображение дерева ников, связанных с данным ником, а также вывод каналов для всего дерева связанных ников. Крайне полезные инструменты для тех, кто регистрирует больше одного ника. 13. Из невидимых пользователям плюсов наших сервисов можно отметить возможность восстановления из сплита записей о пользователях серверов. Например, если сервер пользователя или весь сегмент, содержащий его сервер временно потеряет связь с остальной частью сети, то при возвращении в сеть сервисы не будут требовать вернувшихся пользователей повторно выполнить идентификацию для ника, канала, или лишний раз не покажут новости при входе. 14. Сервисы (как их сообщения, так и разделы помощи) почти полностью переведены на русский язык. Завершить перевод ланируется в ближайшее время. 15. В одной из следующих версий появится BotServ. Пользователи смогут заводить ботов для своих каналов не имея для этого своего собственного shell'а. Будет реализована оптимизированная по используемому межсервеному трафику модель BotServ'а - мы заботимся о вопросе трафика наших администраторов.Три раза в сутки делается бэкап баз данных сервисов, один раз в сутки криптованный бэкап отсылается ответсвенным за сервисы членам команды техподдержки сети. Случайный сбой в работе компьютера или программного обеспечения не может стать причиной потери зарегистрированных ников и каналов. 16. сети есть канал помощи пользователям. Пользователи могут получать ответы на вопросы, касающиеся IRC, использования сервера и сервисов. Когда это возможно, команда помощников также отвечает на вопросы по использованию IRC клиентов. На канале присутсвует бот, автоматически отвечающий на наиболее распространенные вопросы пользователей. Неавтоматическая помощь осуществляется практически 24x7, иногда за исключением ранних утренних часов и некоторых периодов в выходные. 2. Любой пользователь может регистрировать ники и каналы. Каждый пользователей на зарегистрированный ник может зарегистрировать не более 3х каналов (включая все слинкованные ники). Если пользователь хочет иметь больше зарегистрированных каналов, он должен обратиться в комитет по регистрации каналов. Контроль каналов осуществляется комитетом по регистрации каналов в соотвествии с полиси регистрации каналов: http://www.wenet.ru/chans/registration. В комитет может войти любой IRC-оператор. После решения комитета происходит регистрация канала членом комитета на ChanServ'e, и канал далее поддерживается на уровне сети сервисами. Рассматриваются только заявки на регистрацию каналов от лиц, отосланные через веб форму http://www.wenet.ru/chans/chanreg или отправленные почтой на chanreg@wenet.ru. Все спорные ситуации урегулируются собранием членов регистрационного органа по представленным документам (логам). 3. Полиси сети WeNet для операторов - http://www.wenet.ru/net/rules, утверждается техническим советом путем голосования всех членов сети WeNet. Технический совет и операторы сети WeNet действуют только в соотвествии с этим полиси. 4. Полиси сети WeNet для пользователей: 1. Не разрешается подключение к сети более двух клиентов с одного адреса. Если оператор просит Вас убрать Ваших клонов, Вы должны сделать это немедленно. 2. Не разрешаются никакие виды флудботов. o Не разрешаются массовые messages/notices/CTCPs/invites. o Не разрешается массовая реклама каналов и сетей. 3. Запрещены любые проявления национализма и преследования не в специальных частных каналах или частных беседах, при согласии обоих собеседников. 4. Запрещены подмены IP или DNS в локальных сетях, входящих в состав сети WeNet. 5. ненормативная лексика в названиях каналов, топиках. 5. Размер сети - http://www.wenet.ru/net/servers. Охвачены как европейская, так и азиатская части России: 1. Россия: Москва, Санкт-Петербург, Жуковский, Таганрог, Ростов-на-Дону, Краснодар, Тихорецк, Пятигорск, Иваново, Вологда, Кострома, Ульяновск, Волжский, Волгоград, Ижевск, Уфа, Благовещенск, Сургут, Нефтеюганск, Лангепас, Томск, Красноярск. 2. Украина: Донецк, Кременчуг, Полтава, Черновцы, Тернопiль; 3. Грузия: Тбилиси; 4. Кыргызстан: Бишкек В состав сети входят несколько российских ВУЗов: пользователи локальных сетей и общежитий этих ВУЗов имеют доступ к irc: Таганрогский государственный радиотехнический университет, Ивановский государственный энергетический университет, Ижевский государственный технический университет, Костромская государственная сельскохозяйственная академия, Амурский государственный университет, Ульяновский государственный технический университет, Кемеровский государственный университет, Московский государственный технический университет им. Баумана. Из Москвы несколько районов: Крылатское, Отрадное, пр-кт Вернадского, Раменки, Новопеределкино, Солнцево, Жулебино, , локальные сети г. Жуковского. Основные хабы находятся в Москве на магистральных каналах (ИМТЦ МГУ, Комбеллга, Комкор, РТКомм.РУ, Точка.РУ), региональные хабы - г. Таганрог (АО Электросвязь), г. Вологда, г. Иваново, г. Кострома, к. Ижевск, г. Ульяновск, г. Нефтеюганск, г. Донецк, г. Бишкек. Сервера связываются в сеть исходя из наименьшего количества хопов между серверами, оценкой стабильности каналов, здравого смысла ;-) Каждый сервер имеет несколько бэкап-линков. 6. Отвественные лица сети - технический совет, команда разработчиков, орган регистрации каналов - являются компетентными администраторами и программистами, работающими на региональных и городских предприятиях по предоставлению доступа в Интернет, крупных софтверных фирмах. Расширение совета происходит при согласии всех членов этого совета. Ответственные лица, если они находятся в сети, все время следят за сетью, разбираются в конфликтных ситуациях, осуществляют надзор на соблюдением полиси сети. Официальный канал - #wenet. На канале #help пользователям сети оказывается помощь по использованию команд сервера и сервисов, irc-клиентов, скриптованию для irc-клиентов, ботов. 7. Серверное ПО - ircd-RU! (http://www.ircd.ru) - основано на Bahamut 1.4.35 (http://bahamut.dal.net) и сочетает в себе все современные возможности Bahamut'а (флуд контроль, контроль сети, защита от nethack и многое другое) с наиболее полной и грамотной поддержкой русского языка среди российских IRC сетей, и некоторыми другими дополнительными возможностями (подробнее на http://www.ircd.ru/docs.html). Bahamut - основа нашего сервера - является серверным ПО для DALnet (http://www.dal.net), одной из крупнейших IRC сетей мира. Он создан квалифицированными разработчиками, сосредоточившими усилия на наиболее эффективной и безперебойной работе серверов сети. Мы постарались придерживаться такого же принципа при разработке наших расширений. Командой разработчиков ведется разработка новых возможностей, синхронизация с наиболее свежими версиями Bahamut. Осуществляется квалифицированная помощь администраторам серверов в установке и настройке серверного ПО, прием заявок на доработку сервера. 8. Сеть постоянно расширяется, привлекаются новые сегменты, сервера из различных регионов. Основной упор развития - сервера из регионов нашей необъятной родины, различных локальных сетей этих городов, локальных сетей ВУЗов. 9. Время реакции на всевозможные катаклизмы - минимальное, всегда можно достать меня или других членов совета по мылу, аське, sms, телефону. 10. И все остальное, что возможно придумать для улучшение качества сервиса, сети, етц. Для пользователей становятся доступны новые каналы, новые круги общения. Это им очень нравится. Они получают возможность общения с людьми из других городов и регионов страны, находясь на своем сервере. Также они получают в свое распоряжение усовершенствованные возможности нашего сервера и сервисов. Из новых возможностей сервера для пользователей, можно особо отметить: Команда /watch - сервер уведомляет пользователя о смене состояний online/offline для запрошенного списка ников. Грамотные IRC клиенты умеют определять, что сервер поддерживает такую возможность и использовать для /notify команду WATCH вместо ISON, что очень экономит трафик клиента к серверу. Защищенная отправка данных на сервисы. Используя специальные команды для работы с сервисами - /nickserv, /chanserv, /memoserv, /statserv - пользователи защищены от случайного попадания этих данных (например, паролей от ников и каналов) не по назначению. Сервер сам отправляет данные именно объектам сервисов и только им. Также, для удобства есть короткие синонимы: /ns, /cs, /ms, /ss, /identify, /map. Команда /silence - запрещает серверу отправлять приватные сообщения клиенту. Может быть использован для пресечения флуда на уровне сервера, а не клиента. Грамотные русские ники. Улучшенный контроль за ограничением доступа к своим каналам, включающий не только запрет на любые ники, содержащие 8-битные символы, но и более гибкие возможности. А именно: запрет использования канала с никами, содержащими символы из разных алфавитов, и запрет использования канала с никами, содержащими слова с символами из разных алфавитов - это очень удобные возможности, многие владельцы каналов ими пользуются. Наш новый сервер гораздо удобнее в использовании, нежели предыдущий. Из них: 1. Запись сообщений в syslog. 2. Возможность статического (при сборке) и динамического (редактирование Y:lines в ircd.conf) ограничения наборов символов для ников пользователей сервера. 3. Новые возможности ограничения доступа к серверу. 4. Ограничение числа клонов. 5. Возможности для настройки использования сервером строго определенных интерфейсов для разных сетевых операций. 6. Разграничение доступа для IRC операторов к возможностям по управлению сервером (серверами). 7. В дополнение к сжатию, имеется поддержка шифрования трафика между серверами. Планируется сделать отдельную утилиту для отслеживания состояния сервера, подготовке среды для процесса сервера и его запуска/перезапуска. Сервер блокирует работу наиболее распространенных спамботов. В следующей версии появится блокирование еще некоторых распространенных случаев спама, а также возможности ограничения доступа с открытых прокси разных типов. Гораздо эффективнее осуществляется работа по перекодированию сообщений, сервер расходует гораздо меньше процессорного времени. Сервер работает гораздо эффективнее в целом, это видно даже например при соединении к нему пользователем. Мы можем предоставить Вам информацию профайлера, собранную на одном из центральных хабов сети, из которой видно, что большую часть времени сервер занимается сжатием/разжатием межсерверного трафика, а всемя всех остальных операций незначительно. Что касается административных вопросов, у нас существуют жесткие правила применения IRC операторами своих полномочий. IRC операторы не могут без причины (нарушения правил сети) отсоединить Вашего пользователя от сервера (/kill) или без причины (повторяющиеся нарушения правил сети) запретить доступ Вашему пользователю в сеть (autokill). Администраторы серверов могут получать квалифицированную помощь от команды разработчиков сервера по вопросам функционирования сервера, его возможностям и настройкам. При соединении в сеть сегмента случаются конфликты используемых ников. Обычно таких ников не много. Мы со своей стороны можем помочь пользователям найти общий язык и урегулировать эти конфликты без применения насильственных мер. По нашему опыту, конфликты ников обычно всегда решаются мирно, люди понимают, что нет смысла тратить время не на общение, а пререкания по поводу принадлежности, и находят общий язык. Нам никогда не приходилось насильно менять результат переговоров в сторону одной из сторон. Для соединения на Ваших серверах потребуется сменить софт сервера, ознакомиться с его примером файла конфигурации и настроить установленный сервер. Поскольку сервер постоянно находится в разработке, мы периодически апгрейдим софт сервера. На самом деле это случается не очень часто, например последний билд сервера был выпущен через четыре месяца после предыдущего. Иногда новые версии сервера выходят раньше. Апгрейдить сервер надо не обязательно каждый раз после выхода новой версии. Иногда просто исправляются некоторые не значительные ошибки или добавляются некоторая специфическая поддержка для отдельных случаев использования сервера. Если же в сеть устанавливается новая версия сервера и в этой версии расширяется протокол, исправляются серьезные ошибки или добавляются обязательная поддержка, например новых возможностей сервисов - тогда да, мы требуем не задерживать апгрейд софта сервера на новую версию. Команда разработчиков сервера будет специально отмечать, в каких случаях сервер надо проапгрейдить обязательно, а в каких - нет. После первоначальной установки сервера, с которой сопряжены знакомство с сервером, чтение документов по его сборке и настройке, апгрейд на новую версию занимает несколько минут: скачать, собрать, установить. Если при апгрейде будет необходимо что-то изменить в конфигурации или настройках сервера, команда разработчиков особо это отметит и даст рекомендации для быстрого внесения изменений. Для нормального функционирования сервера на машине сервера требуется настроить синхронизацию времени с правильным, например по NTP серверам. Делается эта настройка просто, один раз. При особенной активности непонравившихся пользователей какого-то конкретного сервера (или нескольких серверов), операторы канала могут запретить доступ всем этим пользователям сразу, посредством списка +B и при необходимости открывать доступ лишь некоторым пользователям того сервера (или серверов). Или, как было отмечено выше, при желании владельцы канала могут вообще отгородить свой канал от внешнего мира (список +X), и при этом старые пользователи канала смогут заходить на него как и раньше, без дополнительных действий. Пример грамотного понимания ситуации продемонстрировали администраторы сервера в Тернополе, западная Украина. Пользователи их сервера общаются на своем родном языке и столкновений на их основном канале после линка было бы не избежать. Поэтому хозяева канала заранее установили на канале +X - эксклюзивный доступ - только для своего сервера, а потом, когда их пользователи почувствовали себя в сети более привычно, освоились с количеством других пользователей и каналов, научились применять технические возможности - открыли доступ на канал с других серверов. Связанных с линком проблем на их канале не было совсем. Так же мы очень выросли в плане отношения к пользователям. Правила использования своих полномочий привелегированными пользователями у нас определены очень жестко и их соблюдение также очень жестко контролируется. В случаях безнадежного непонимания миссии IRC оператора или повторяющихся прецедентов злоупотребления, нарушения наказываются лишением привилегий. При возникновении конфликтов (не относящихся к нарушениям общих правил пользователей для сети) на каналах абсолютный приоритет имеют владельцы канала, вне зависимости от статуса, прав доступа на сервере и привилегий конфликтующих сторон. На мой взгляд, теперь у нас более приятная атмосфера в команде администраторов. Администраторы сети работают слаженно, без ссор и потасовок, помнят, что предназначение их сервера и сети в целом - предоставлять клиентам качественный IRC сервис. При решении объединить наши сервера я надеюсь, что Ваши администраторы и IRC операторы также будут придерживаться этого правила и вольются в нашу дружную команду. 1. С линком Вы дадите своим пользователям возможность общаться более эффективно и интересно, без необходимости ходить на другой сервер. Дадите им возможность получить на своих каналах других интересных людей, с других концов страны. 2. С нашим сервером и сервисами Ваши пользователи получат много нового, удобного, эффективного в техническом плане. Станет больше возможностей обеспечить безопасность в IRC для себя и своих каналов. 3. Пользователи смогут получать квалифицированную помощь по различным вопросам использования IRC. 4. Администраторы получат более стабильный, надежный, эффективный, гибкий в настройке и удобный в использовании сервер.
Мировая информационная сеть Telnet
TELNET (англ. TELecommunication NETwork) — сетевой протокол для реализации текстового интерфейса по сети (в современной форме — при помощи транспорта TCP). Название «telnet» имеют также некоторые утилиты, реализующие клиентскую часть протокола. Хотя в сессии Telnet выделяют клиентскую и серверную сторону, протокол на самом деле полностью симметричен. После установления транспортного соединения (как правило, TCP) оба его конца играют роль «сетевых виртуальных терминалов» (англ. Network Virtual Terminal, NVT), обменивающихся двумя типами данных: 1. Прикладными данными (т.е. данными, которые идут от пользователя к текстовому приложению на стороне сервера и обратно); 2. Опциями протокола Telnet, служащими для уяснения возможностей и предпочтений сторон. Прикладные данные проходят через протокол без изменений, т.е. на выходе второго виртуального терминала мы видим именно то, что было введено на вход первого. С точки зрения протокола данные представляют просто последовательность байтов (октетов), по умолчанию принадлежащих набору ASCII, но при включенной опции Binary — любых. Хотя были предложены расширения для идентификации набора символов , но на практике ими не пользуются. Все значения октетов прикладных данных кроме \377 (десятичное 255) передаются по транспорту как есть. Октет \377 передаётся последовательностью \377\377 из двух октетов. Это связано с тем, что октет \377 используется на транспортном уровне для кодирования опций. Исторически Telnet служил для удалённого доступа к интерфейсу командной строки операционных систем. Впоследствии его стали использовать для прочих текстовых интерфейсов, вплоть до игр MUD и анимированного ASCII-art. Теоретически, даже обе стороны протокола могут являться программами, а не человеком. Иногда клиенты telnet используются для доступа к другим протоколам на основе транспорта TCP, см. #Telnet и другие протоколы. Протокол telnet используется в управляющем соединении FTP, т.е. заходить на сервер командой telnet ftp.example.net ftp для выполнения отладки и экспериментов не только возможно, но и правильно (в отличие от применения клиентов telnet для доступа к HTTP, IRC и большинству других протоколов). В протоколе не предусмотрено использование ни шифрования, ни проверки подлинности данных. Поэтому он уязвим для любого вида атак, к которым уязвим его транспорт, т.е. протокол TCP. Для функциональности удалённого доступа к системе в настоящее время применяется сетевой протокол SSH (особенно его версия 2), при создании которого упор делался именно на вопросы безопасности. Так что следует иметь в виду, что сессия Telnet весьма беззащитна, если только не осуществляется в полностью контролируемой сети или с применением защиты на сетевом уровне (различные реализации виртуальных частных сетей). По причине ненадёжности от Telnet как средства управления операционными системами давно отказались. В среде специалистов по технологиям internet распространено мнение, что клиент Telnet пригоден для осуществления ручного доступа (например, в целях отладки) к таким протоколам прикладного уровня как HTTP, IRC, SMTP, POP3 и прочим текст-ориентированным протоколам на основе транспорта TCP. Однако, использование клиента telnet в качестве клиента TCP вызывает следующие нежелательные эффекты: 1. Клиент может передать данные, которые Вы не вводили (опции Telnet); 2. Клиент не будет принимать октет \377; 3. Клиент будет искажать октет \377 при передаче; 4. Клиент вообще может отказаться передавать октеты со старшим битом 1. Такие программы как netcat действительно обеспечивают чистый доступ к TCP, однако использование чистого доступа к TCP вызывает иную проблему. Перевод строки, вводимый из Unix-системы, будет передан одним символом LF, в то время как названные протоколы требуют CR LF как разделитель строки — впрочем, большинство серверов удовлетворяются и одним LF, хотя по стандарту делать это не обязаны. Обычный клиент Telnet по умолчанию передаёт любой перевод строки именно как CR LF. Наиболее корректным решением для отладочного доступа к прикладным протоколам (кроме FTP и, собственно, Telnet) является использование клиента PuTTY в режиме «Raw» (чистый доступ к TCP) — PuTTY преобразует переводы строки отдельно от поддержки протокола Telnet. Информация расположенная на данном сайте взята со следующих источников 1. WeNet 2. Fidonet 3. Telnet 4. Информационная сеть Мировая информационная сеть Fidonet 3
Техническая организация сети. 4
Особенности программного обеспечения сети. 9
Мировая информационная сеть WeNet 10
Информация о сети, администрации, управлении, программном обеспечении. 10
Минусы для администраторов. 14
Предыдущий опыт объединения серверов. 14
Мировая информационная сеть Telnet 16
Telnet и другие протоколы.. 17
| |||||