Разное

Что такое сетевая модель: 30.1. Сетевые модели. Основные понятия сетевой модели

Содержание

30.1. Сетевые модели. Основные понятия сетевой модели

До появления сетевых методов планирование работ, проек­тов осуществлялось в небольшом объеме. Наиболее известным средством такого планирования был ленточный график Ганта, недостаток которого состоит в том, что он не позволяет установить зависимости между различными операциями.


Современное сетевое планирование начинается с разбиения программы работ на операции. Определяются оценки продол­жительности операций, и строится сетевая модель (график). Построение сетевой модели позволяет проанализировать все операции и внести улучшения в структуру модели до начала ее реализации. Строится календарный график, определяющий начало и окончание каждой операции, а также взаимосвязи с другими операциями графика. Календарный график выявляет критические операции, которым надо уделять особое внима­ние, чтобы закончить все работы в директивный срок. Что касается некритических операций, то календарный план поз­воляет определить резервы времени, которые можно выгодно использовать при задержке выполнения работ или эффектив­ном применении как трудовых, так и финансовых ресурсов.


Сетевая модель — графическое изображение плана выпол­нения комплекса работ, состоящего из нитей (работ) и узлов (событий), которые отражают логическую взаимосвязь всех операций. В основе сетевого моделирования лежит изображе­ние планируемого комплекса работ в виде графа. Граф — схе­ма, состоящая из заданных точек (вершин), соединенных сис­темой линий. Отрезки, соединяющие вершины, называются ребрами (дугами) графа. Ориентированным называется такой граф, на котором стрелкой указаны направления всех его ребер (дуг), что позволяет определить, какая из двух его граничных вершин является начальной, а какая — конечной. Исследование таких сетей проводится методами теории графов.


Теория графов оперирует понятием пути, объединяющим последовательность взаимосвязанных ребер. Контур означает такой путь, у которого начальная вершина совпадает с конеч­ной. Сетевой график — это ориентированный граф без конту­ров. В сетевом моделировании имеются два основных элемен­та — работа и событие.


Работа — это активный процесс, требующий затрат ресур­сов, либо пассивный (ожидание), приводящий к достижению намеченного результата.


Фиктивная работа — это связь между результатами работ (событиями), не требующая затрат времени и ресурсов.


Событие — это результат (промежуточный или конечный) выполнения одной или нескольких предшествующих работ.


Путь — это любая непрерывная последовательность (цепь) работ и событий.


Критический путь — это путь, не имеющий резервов и включающий самые напряженные работы комплекса. Работы, расположенные на критическом пути, называют критически­ми. Все остальные работы являются некритическими (нена­пряженными) и обладают резервами времени, которые позво­ляют передвигать сроки их выполнения, не влияя на общую продолжительность выполнения всего комплекса работ.


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


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



2. Два соседних события могут объединяться лишь одной работой. Для изображения параллельных работ вводятся про­межуточное событие и фиктивная работа (рис. 30.1).


3. В сети не должно быть тупиков, т. е. промежуточных событий, из которых не выходит ни одна работа (рис. 30.2).



4. В сети не должно быть промежуточных событий, кото­рым не предшествует хотя бы одна работа (рис. 30.3).


5. В сети не должно быть замкнутых контуров, состоя­щих из взаимосвязанных работ, создающих замкнутую цепь (рис. 30.4). Для правильной нумерации событий поступают следующим образом: нумерация событий начинается с исход­ного события, которому дается номер 1. Из исходного собы­тия 1 вычеркивают все исходящие из него работы, на остав­шейся сети вновь находят событие, в которое не входит ни одна работа. Этому событию дается номер 2. Затем вычеркивают работы, выходящие из события 2, и вновь находят на остав­шейся части сети событие, в которое не входит ни одна работа, ему присваивается номер 3, и так продолжается до заверша­ющего события. Пример нумерации сетевого графика показан на рис. 30.5.




Продолжительность выполнения работ устанавливается на основании действующих нормативов или по экспертным оцен­кам специалистов. В первом случае временные оценки являют­ся детерминированными (однозначными), во втором — стохас­тическими (вероятностными).


Рассмотрим в качестве примера программу создания но­вого бытового прибора, пользующегося спросом у населения. Необходимые данные приведены в табл. 30.1.


На основании данных таблицы построим сетевой график создания прибора с учетом вышеизложенных рекомендаций (рис. 30.6).

< Предыдущая   Следующая >

Сетевая модель — Студопедия

Введение

Теоретическая часть

Сетевая модель

Топология сети

Среда передачи данных

Практическая часть

Заключение

Введение

Ни для кого не секрет насколько в наше время важны информационные технологии. Сети, в свою очередь, являются немаловажной частью их распространенности. Использование сетей позволяет резко увеличить возможности пользователя как в деле оказания услуг своим клиентам, так и при решении собственных организационно-экономических задач.

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

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

Компьютерная сеть — объединение нескольких ЭВМ для совместного решения информационных, вычислительных, учебных и других задач.

Компьютерные сети и сетевые технологии обработки информации стали основой для построения современных информационных систем. Глобальная сеть Интернет превратилась в явление мирового масштаба. Сеть, которая когда-то использовалась ограниченным кругом ученых, государственных служащих и работников образовательных учреждений в их профессиональной деятельности, стала доступной для больших и малых корпораций и для индивидуальных пользователей.



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

Теоретическая часть

Сетевая модель

Сетевая модель OSI (англ. open systems interconnection basic reference model — базовая эталонная модель взаимодействия открытых систем, сокр. ЭМВОС; 1978 г.) — абстрактная сетевая модель для коммуникаций и разработки сетевых протоколов. Предлагает взгляд на компьютерную сеть с точки зрения измерений. Каждое измерение обслуживает свою часть процесса взаимодействия. Благодаря такой структуре совместная работа сетевого оборудования и программного обеспечения становится гораздо проще и прозрачнее.


В настоящее время основным используемым стеком протоколов является TCP/IP, разработанный ещё до принятия модели OSI и вне связи с ней.

Уровни модели OSI

В литературе наиболее часто принято начинать описание уровней модели OSI с 7-го уровня, называемого прикладным, на котором пользовательские приложения обращаются к сети. Модель OSI заканчивается 1-м уровнем — физическим, на котором определены стандарты, предъявляемые независимыми производителями к средам передачи данных:

· тип передающей среды (медный кабель, оптоволокно, радиоэфир и др.),

· тип модуляции сигнала,

· сигнальные уровни логических дискретных состояний (нуля и единицы).

Модель OSI представлена на рисунке 1.

Рисунок 1. Модель OSI

Любой протокол модели OSI должен взаимодействовать либо с протоколами своего уровня, либо с протоколами на единицу выше и/или ниже своего уровня. Взаимодействия с протоколами своего уровня называются горизонтальными, а с уровнями на единицу выше или ниже — вертикальными. Любой протокол модели OSI может выполнять только функции своего уровня и не может выполнять функций другого уровня, что не выполняется в протоколах альтернативных моделей.

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

К базовым сетевым технологиям относятся физический и канальный уровни.

Прикладной уровень (уровень приложений; англ. application layer) — верхний уровень модели, обеспечивающий взаимодействие пользовательских приложений с сетью:

· позволяет приложениям использовать сетевые службы:

· удалённый доступ к файлам и базам данных,

· пересылка электронной почты;

· отвечает за передачу служебной информации;

· предоставляет приложениям информацию об ошибках;

· формирует запросы к уровню представления.

Протоколы прикладного уровня: HTTP, SMTP, SNMP, POP3, FTP, XMPP, OSCAR, Modbus, SIP, TELNET.

Представительский уровень (уровень представления; англ. presentation layer) обеспечивает преобразование протоколов и кодирование/декодирование данных. Запросы приложений, полученные с прикладного уровня, на уровне представления преобразуются в формат для передачи по сети, а полученные из сети данные преобразуются в формат приложений. На этом уровне может осуществляться сжатие/распаковка или кодирование/декодирование данных, а также перенаправление запросов другому сетевому ресурсу, если они не могут быть обработаны локально.

Протоколы уровня представления: AFP — Apple Filing Protocol, ICA — Independent Computing Architecture, LPP — Lightweight Presentation Protocol, NCP — NetWare Core Protocol, NDR — Network Data Representation RDP — Remote Desktop Protocol, XDR — eXternal Data Representation, X.25 PAD — Packet Assembler/Disassembler Protocol.

Сеансовый уровень (англ. session layer) модели обеспечивает поддержание сеанса связи, позволяя приложениям взаимодействовать между собой длительное время. Уровень управляет созданием/завершением сеанса, обменом информацией, синхронизацией задач, определением права на передачу данных и поддержанием сеанса в периоды неактивности приложений.

Протоколы сеансового уровня: ADSP (AppleTalk Data Stream Protocol), ASP (AppleTalk Session Protocol), H.245 (Call Control Protocol for Multimedia Communication), ISO-SP (OSI Session Layer Protocol (X.225, ISO 8327)), iSNS (Internet Storage Name Service), L2F (Layer 2 Forwarding Protocol), L2TP (Layer 2 Tunneling Protocol), NetBIOS (Network Basic Input Output System), PAP (Password Authentication Protocol), PPTP (Point-to-Point Tunneling Protocol), RPC (Remote Procedure Call Protocol), RTCP (Real-time Transport Control Protocol), SMPP (Short Message Peer-to-Peer), SCP (Secure Copy Protocol), ZIP (Zone Information Protocol), SDP (Sockets Direct Protocol).

Транспортный уровень (англ. transport layer) модели предназначен для обеспечения надёжной передачи данных от отправителя к получателю. При этом уровень надёжности может варьироваться в широких пределах. Существует множество классов протоколов транспортного уровня, начиная от протоколов, предоставляющих только основные транспортные функции (например, функции передачи данных без подтверждения приема), и заканчивая протоколами, которые гарантируют доставку в пункт назначения нескольких пакетов данных в надлежащей последовательности, мультиплексируют несколько потоков данных, обеспечивают механизм управления потоками данных и гарантируют достоверность принятых данных. Например, UDP ограничивается контролем целостности данных в рамках одной датаграммы, и не исключает возможности потери пакета целиком, или дублирования пакетов, нарушение порядка получения пакетов данных; TCP обеспечивает надёжную непрерывную передачу данных, исключающую потерю данных или нарушение порядка их поступления или дублирования, может перераспределять данные, разбивая большие порции данных на фрагменты и наоборот склеивая фрагменты в один пакет.

Протоколы транспортного уровня: ATP (AppleTalk Transaction Protocol), CUDP (Cyclic UDP), DCCP (Datagram Congestion Control Protocol), FCP (Fiber Channel Protocol), IL (IL Protocol), NBF (NetBIOS Frames protocol), NCP (NetWare Core Protocol), SCTP (Stream Control Transmission Protocol), SPX (Sequenced Packet Exchange), SST (Structured Stream Transport), TCP (Transmission Control Protocol), UDP (User Datagram Protocol).

Сетевой уровень (англ. network layer) модели предназначен для определения пути передачи данных. Отвечает за трансляцию логических адресов и имён в физические, определение кратчайших маршрутов, коммутацию и маршрутизацию, отслеживание неполадок и «заторов» в сети.

Протоколы сетевого уровня маршрутизируют данные от источника к получателю. Работающие на этом уровне устройства (маршрутизаторы) условно называют устройствами третьего уровня (по номеру уровня в модели OSI).

Протоколы сетевого уровня: IP/IPv4/IPv6 (Internet Protocol), IPX (Internetwork Packet Exchange, протокол межсетевого обмена), X.25 (частично этот протокол реализован на уровне 2), CLNP (сетевой протокол без организации соединений), IPsec (Internet Protocol Security), ICMP (Internet Control Message Protocol), RIP (Routing Information Protocol), OSPF (Open Shortest Path First), ARP (Address Resolution Protocol).

Канальный уровень (англ. data link layer) предназначен для обеспечения взаимодействия сетей на физическом уровне и контроля за ошибками, которые могут возникнуть. Полученные с физического уровня данные он упаковывает в кадры, проверяет на целостность, если нужно, исправляет ошибки (формирует повторный запрос поврежденного кадра) и отправляет на сетевой уровень. Канальный уровень может взаимодействовать с одним или несколькими физическими уровнями, контролируя и управляя этим взаимодействием.

На этом уровне работают коммутаторы, мосты и другие устройства. Говорят, что эти устройства используют адресацию второго уровня (по номеру уровня в модели OSI).

Протоколы канального уровня: ARCnet, ATM, Cisco Discovery Protocol (CDP), Controller Area Network (CAN), Econet, Ethernet, Ethernet Automatic Protection Switching (EAPS), Fiber Distributed Data Interface (FDDI), Frame Relay, High-Level Data Link Control (HDLC), IEEE 802.2 (provides LLC functions to IEEE 802 MAC layers), Link Access Procedures, D channel (LAPD), IEEE 802.11 wireless LAN, LocalTalk, Multiprotocol Label Switching (MPLS), Point-to-Point Protocol (PPP), Point-to-Point Protocol over Ethernet (PPPoE), Serial Line Internet Protocol (SLIP, obsolete), StarLan, Spanning tree protocol, Token ring, Unidirectional Link Detection (UDLD), x.25.

Физический уровень (англ. physical layer) — нижний уровень модели, предназначенный непосредственно для передачи потока данных. Осуществляет передачу электрических или оптических сигналов в кабель или в радиоэфир и, соответственно, их приём и преобразование в биты данных в соответствии с методами кодирования цифровых сигналов. Другими словами, осуществляет интерфейс между сетевым носителем и сетевым устройством.

На этом уровне также работают концентраторы, повторители сигнала и медиаконвертеры.

Протоколы физического уровня: IEEE 802.15 (Bluetooth), IRDA, EIA RS-232, EIA-422, EIA-423, RS-449, RS-485, DSL, ISDN, SONET/SDH, 802.11 Wi-Fi, Etherloop, GSM Um radio interface, ITU и ITU-T, TransferJet, ARINC 818, G.hn/G.9960.

В качестве адреса хоста IPX использует идентификатор, образованный из четырёхбайтного номера сети (назначаемого маршрутизаторами) и MAC-адреса сетевого адаптера.

О сетевой модели в играх для начинающих / Хабр

Последние две недели я работал над сетевым движком для своей игры. До этого я вообще ничего не знал о сетевых технологиях в играх, поэтому прочитал множество статей и провёл множество экспериментов, чтобы уяснить все концепции и иметь возможность написать собственный сетевой движок.

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

В целом существует два основных типа сетевых архитектур: peer-to-peer и клиент-серверная. В архитектуре peer-to-peer (p2p) данные передаются между любыми парами подключенных игроков, а в клиент-серверной архитектуре данные передаются только между игроками и сервером.

Хотя архитектура peer-to-peer по-прежнему используется в некоторых играх, стандартом является клиент-серверная: она проще в реализации, требует канал меньшей ширины и облегчает защиту от читерства. Поэтому в этом руководстве мы сосредоточимся на клиент-серверной архитектуре.


В частности, нас больше всего интересуют авторитарные серверы: в таких системах сервер всегда прав. Например, если игрок думает, что находится в координатах (10, 5), а сервер говорит ему, что он в (5, 3), то клиент должен заменить свою позицию той, которую передаёт сервер, а не наоборот. Использование авторитарных серверов упрощает распознавание читеров.

В игровых сетевых системах есть три основных компонента:

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

Очень важно понять роль каждой части и связанные с ними трудности.
Первый шаг заключается в выборе протокола для транспортировки данных между сервером и клиентами. Для этого существует два Интернет-протокола: TCP и UDP. Но вы можете создать и собственный транспортный протокол на основе одного из них или применить библиотеку, в которой они используются.

Сравнение TCP и UDP

И TCP, и UDP основаны на IP. IP позволяет передавать пакет от источника получателю, но не даёт гарантий, что отправленный пакет рано или поздно попадёт к получателю, что он доберётся до него хотя бы раз и что последовательность пакетов придёт в правильном порядке. Более того, пакет может содержать только ограниченный размер данных, задаваемый величиной MTU.

UDP является всего лишь тонким слоем поверх IP. Следовательно, он имеет те же ограничения. В отличие от него, TCP обладает множеством особенностей. Он обеспечивает надёжное упорядоченное соединение между двумя узлами с проверкой на ошибки. Следовательно, TCP очень удобен и используется во множестве других протоколов, например, в HTTP, FTP и SMTP. Но все эти функции имеют свою цену: задержку.

Чтобы понять, почему эти функции могут вызывать задержку, надо разобраться, как работает TCP. Когда узел-отправитель передаёт пакет узлу-получателю, он ожидает получить подтверждение (ACK). Если спустя определённое время он не получает его (потому что пакет или подтверждение было утеряно, или по каким-то другим причинам), то отправляет пакет повторно. Более того, TCP гарантирует получение пакетов в правильном порядке, поэтому пока утерянный пакет не получен, все остальные пакеты не могут быть обработаны, даже если они уже получены узлом-получателем.

Но как вы наверно понимаете, задержка в многопользовательских играх очень важна, особенно в таких активных жанрах, как FPS. Именно поэтому многие игры используют UDP с собственным протоколом.

Собственный протокол на основе UDP может быть эффективнее TCP по различным причинам. Например, он может помечать некоторые пакеты как надёжные, а другие — как ненадёжные. Поэтому его не волнует, добрался ли ненадёжный пакет до получателя. Или он может обрабатывать несколько потоков данных, чтобы потерянный в одном потоке пакет не замедлял остальные потоки. Например, может существовать поток для ввода игрока и ещё один поток для сообщений чата. Если сообщение чата, которое не является срочными данными, потеряно, то оно не замедлит срабатывание ввода, который является неотложным. Или же собственный протокол может реализовать надёжность иначе, чем в TCP, чтобы быть более эффективным в условиях видеоигр.

Итак, если TCP такой отстойный, то мы будем создавать свой транспортный протокол на основе UDP?

Всё немного сложнее. Даже хотя TCP почти субоптимален для игровых сетевых систем, он может вполне хорошо работать конкретно в вашей игре и сэкономить ваше драгоценное время. Например, задержка может и не быть проблемой для пошаговой игры или игры, в которую можно играть только в сетях LAN, где задержки и утеря пакетов намного меньше, чем в Интернете.

Во многих успешных играх, в том числе World of Warcraft, Minecraft и Terraria, используется TCP. Однако в большинстве FPS применяются собственные протоколы на основе UDP, поэтому ниже мы поговорим о них подробнее.

Если вы решите использовать TCP, то убедитесь, что отключен алгоритм Нейгла, потому что он буферизует пакеты перед отправкой, а значит, увеличивает задержку.

Чтобы подробнее узнать о различиях между UDP и TCP в контексте многопользовательских игр, можно прочитать статью Гленна Фидлера UDP vs. TCP.

Собственный протокол

Итак, вы хотите создать собственный транспортный протокол, но не знаете, с чего начать? Вам повезло, ведь Гленн Фидлер написал об этом две потрясающие статьи. В них вы найдёте множество умных мыслей.

Первая статья, Networking for Game Programmers 2008 года, проще, чем вторая, Building A Game Network Protocol 2016 года. Рекомендую вам начать с более старой.

Учтите, что Гленн Фидлер — большой сторонник использования собственного протокола на основе UDP. И после прочтения его статей вы наверняка переймёте у него мнение о том, что TCP имеет в видеоиграх серьёзные недостатки, и захотите реализовать собственный протокол.

Но если вы новичок в работе с сетями, то сделайте себе одолжение и используйте TCP или библиотеку. Для успешной реализации собственного транспортного протокола нужно предварительно многому научиться.

Сетевые библиотеки

Если вам нужно что-то более эффективное, чем TCP, но вы не хотите заморачиваться реализацией собственного протокола и вдаваться во множество подробностей, то можете воспользоваться сетевой библиотекой. Их очень много:

  • yojimbo Гленна Фидлера
  • RakNet, которая больше не поддерживается, но её форк SLikeNet похоже ещё активен.
  • ENet — это библиотека, созданная для многопользовательского FPS Cube
  • GameNetworkingSockets компании Valve

Я не пробовал их все, но предпочтение отдаю ENet, потому что она проста в использовании и надёжна. Кроме того, у неё есть понятная документация и туториал для начинающих.

Транспортный протокол: заключение

Подведём итог: существует два основных транспортных протокола: TCP и UDP. TCP обладает множеством полезных особенностей: надёжность, сохранение порядка пакетов, обнаружение ошибок. У UDP всего этого нет, зато TCP по своей природе обладает повышенными задержками, недопустимыми для некоторых игр. То есть для обеспечения низких задержек можно создать собственный протокол на основе UDP или использовать библиотеку, реализующую транспортный протокол на UDP и адаптированную для многопользовательских видеоигр.

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

У меня есть два совета:

  • Максимально абстрагируйте транспортный протокол от остальной части приложения, чтобы его можно было легко заменить, не переписывая весь код.
  • Не занимайтесь преждевременной оптимизацией. Если вы не специалист по сетям и не уверены, нужен ли вам собственный транспортный протокол на основе UDP, то можете начать с TCP или библиотеки, обеспечивающих надёжность, а затем протестировать и измерить производительность. Если возникают проблемы и вы уверены, что причина заключается в транспортном протоколе, то возможно настало время создавать собственный транспортный протокол.

В завершение этой части рекомендую вам прочитать Introduction to Multiplayer Game Programming Брайана Хука, в котором рассмотрено множество обсуждаемых здесь тем.
Теперь, когда мы можем обмениваться данными между клиентами и сервером, нужно решить, какие именно данные передавать и в каком формате.

Классическая схема заключается в том, что клиенты отправляют серверу ввод или действия, а сервер отправляет клиентам текущее игровое состояние.

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

Сериализация

Первым шагом будет преобразование данных, которые мы хотим отправить (ввод или игровое состояние), в подходящий для передачи формат. Этот процесс называется сериализацией.

В голову сразу приходит мысль использовать человекочитаемый формат, например JSON или XML. Но это будет совершенно неэффективно и впустую займёт большую часть канала.

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

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

Только убедитесь, что библиотека создаёт портируемые архивы и заботится о порядке байтов.

Альтернативным решением может быть самостоятельная реализация, она не особо сложна, особенно если в коде вы используете ориентированный на данные подход. Кроме того, она позволит вам выполнять оптимизации, которые не всегда возможны при использовании библиотеки.

Гленн Фидлер написал о сериализации две статьи: Reading and Writing Packets и Serialization Strategies.

Сжатие

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

Битовая упаковка

Первая техника — это битовая упаковка. Она заключается в использовании ровно того количества битов, которое необходимо для описания нужной величины. Например, если у вас есть перечисление, которое может иметь 16 различных значений, то вместо целого байта (8 бит) можно использовать всего 4 бита.

Гленн Фидлер объясняет, как реализовать это, во второй части статьи Reading and Writing Packets.

Битовая упаковка особенно хорошо работает с дискретизацией, которая будет темой следующего раздела.

Дискретизация

Дискретизация — это техника сжатия с потерями, которая заключается в использовании для кодирования величины только подмножества возможных значений. Проще всего реализовать дискретизацию округлением чисел с плавающей запятой.

Гленн Фидлер (опять!) показывает, как применять дискретизацию на практике, в своей статье Snapshot Compression.

Алгоритмы сжатия

Следующей техникой будут алгоритмы сжатия без потерь.

Вот, на мой взгляд, три самых интересных алгоритма, которые нужно знать:

  • Кодирование Хаффмана с заранее вычисленным кодом, которое чрезвычайно быстро и может давать хорошие результаты. Оно использовалось для сжатия пакетов в сетевом движке Quake3.
  • zlib — алгоритм сжатия общего назначения, который никогда не увеличивает объём данных. Как можно увидеть здесь, он применялся во множестве областей применения. Для обновления состояний он может оказаться избыточным. Но он может и пригодиться, если вам нужно отправлять клиентам с сервера ассеты, длинные тексты или рельеф.
  • Копирование длин серий — это, наверно, простейший алгоритм сжатия, но он очень эффективен для определённых типов данных, и может использоваться как этап предварительной обработки перед zlib. Он особенно подходит для сжатия рельефа, состоящего из тайлов или вокселей, в которых множество соседних элементов повторяется.

Дельта-сжатие

Последняя методика сжатия — это дельта-сжатие. Она заключается в том, что передаются только различия между текущим игровым состоянием и последним состоянием, полученным клиентом.

Впервые она была применена в сетевом движке Quake3. Вот две статьи, объясняющих способ её использования:

Гленн Фидлер также использовал её во второй части своей статьи Snapshot Compression.

Шифрование

Кроме того вам может понадобиться шифровать передачу информации между клиентами и сервером. На это есть несколько причин:

  • приватность/конфиденциальность: сообщения могут быть прочитаны только получателем, и ни одному другому лицу, выполняющему сниффинг сети, не удастся их прочесть.
  • аутентификация: человек, желающий исполнять роль игрока, должен знать его ключ.
  • предотвращение читерства: злонамеренным игрокам будет намного сложнее создавать собственные пакеты для читерства, им придётся воспроизводить схему шифрования и находить ключ (который меняется при каждом соединении).

Я настойчиво рекомендую использовать для этого библиотеку. Предлагаю пользоваться libsodium, потому что она особенно проста и имеет отличные туториалы. Особо интересен туториал по обмену ключами, позволяющий генерировать новые ключи при каждом новом соединении.

Протокол приложения: заключение

На этом мы закончим с протоколом приложения. Я считаю, что сжатие совершенно необязательно и решение о его использовании зависит только от игры и требуемой пропускной способности канала. Шифрование, на мой взгляд, обязательно, но в первом прототипе можно обойтись без него.
Теперь мы способны обновлять состояние в клиенте, но можем столкнуться с проблемами задержек. Игроку, выполнив ввод, нужно ждать обновления состояния игры от сервера, чтобы увидеть, какое воздействие он оказал на мир.

Более того, между двумя обновлениями состояния мир совершенно статичен. Если частота обновления состояний низка, то движения будут очень дёрганными.

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

Техники сглаживания задержек

Все описанные в этом разделе техники подробно рассмотрены в серии Fast-Paced Multiplayer Габриэля Гамбетты. Я настойчиво рекомендую прочитать эту великолепную серию статей. В ней также есть интерактивное демо, позволяющее увидеть, как эти техники работают на практике.

Первая техника заключается в том, чтобы применять результат ввода напрямую, не ожидая ответа от сервера. Это называется прогнозированием на стороне клиента. Однако когда клиент получает обновление от сервера, он должен убедиться, что его прогноз был верным. Если это не так, то ему нужно просто изменить своё состояние согласно полученному от сервера, потому что сервер авторитарен. Эта техника впервые была использована в Quake. Подробнее о ней можно прочитать в статье Quake Engine code review Фабьена Санглара [перевод на Хабре].

Второй набор техник используется для сглаживания движения других сущностей между двумя обновлениями состояния. Существует два способа решения этой задачи: интерполяция и экстраполяция. В случае интерполяции берутся два последних состояния и показывается переход из одного в другое. Её недостаток в том, что она вызывает небольшую долю задержки, потому что клиент всегда видит то, что происходило в прошлом. Экстраполяция заключается в прогнозировании того, где сейчас должны находиться сущности на основании последнего состояния, полученного клиентом. Её недостаток в том, что если сущность полностью меняет направление движения, то возникнет большая погрешность между прогнозом и реальной позицией.

Последняя, самая продвинутая техника, полезная только в FPS — это компенсация лага. При использовании компенсации лага сервер учитывает задержки клиента, когда он стреляет в цель. Например, если игрок выполнил хедшот на своём экране, но в реальности его цель из-за задержки находилась в другом месте, то было бы нечестно отказывать игроку в праве на убийство из-за задержки. Поэтому сервер выполняет перемотку времени назад, на тот момент, когда игрок выстрелил, чтобы симулировать, что видел игрок на своём экране, и проверить коллизию между его выстрелом и целью.

Гленн Фидлер (как всегда!) написал в 2004 году статью Network Physics (2004), в которой заложил фундамент синхронизации симуляции физики между сервером и клиентом. В 2014 году он написал новую серию статей Networking Physics, в которой описал другие техники для синхронизации симуляции физики.

Также в wiki компании Valve есть две статьи, Source Multiplayer Networking и Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization в которых рассматривается компенсация задержек.

Предотвращение читерства

Существует две основные техники предотвращения читерства.

Первая: усложнение отправки читерами вредоносных пакетов. Как сказано выше, хорошим способом её реализации является шифрование.

Вторая: авторитарный сервер должен получать только команды/ввод/действия. Клиент не должен иметь возможности изменять состояние на сервере, кроме как отправкой ввода. Тогда сервер каждый раз при получении ввода должен перед его применением проверять его на допустимость.

Логика приложения: заключение

Рекомендую вам реализовать способ симуляции больших задержек и низких частот обновления, чтобы иметь возможность протестировать поведение своей игры в плохих условиях, даже когда клиент и сервер запущены на одном компьютере. Это сильно упростит реализацию методик сглаживания задержек.
Если вы хотите изучить другие ресурсы, посвящённые сетевым моделям, то их можно найти здесь:

  • Блог Гленна Фидлера — стоит прочитать весь его блог, в нём есть множество отличных статей. Здесь собраны все статьи по сетевым технологиям.
  • Awesome Game Networking автора M. Fatih MAR — это подробный список статей и видео по сетевым движкам видеоигр.
  • В wiki сабреддита r/gamedev тоже есть множество полезных ссылок.

СЕТЕВАЯ МОДЕЛЬ — это… Что такое СЕТЕВАЯ МОДЕЛЬ?



СЕТЕВАЯ МОДЕЛЬ

информац. модель комплекса взаимосвязанных работ, представленная в виде схемы (сети), таблицы, цифрового кода или в к.-л. ином виде и отображающая распределение этих работ во времени. Наиболее распространённой формой С. м. является сетевой график. С. м. может также отображать стоимость работ, требуемые для их выполнения матер. и энергетич. ресурсы, транспорт и т. д. С. м. позволяет решать задачи оптимизации при планировании работ, расчётах их материально-технич. обеспечения и распределения ресурсов

Большой энциклопедический политехнический словарь.
2004.

  • СЕРЫЙ ЧУГУН
  • СЕТЕВОЕ ПЛАНИРОВАНИЕ И УПРАВЛЕНИЕ

Смотреть что такое «СЕТЕВАЯ МОДЕЛЬ» в других словарях:

  • Сетевая модель — У этого термина существуют и другие значения, см. Модель. Сетевая модель теоретическое описание принципов работы набора сетевых протоколов, взаимодействующих друг с другом. Модель обычно делится на уровни, так, чтобы протоколы вышестоящего уровня …   Википедия

  • СЕТЕВАЯ МОДЕЛЬ — интерпретация программы (плана) реализации нек рого комплекса взаимосвязанных работ в виде графа ориентированного без контуров, отражающего естественный порядок выполнения работ во времени с нек рыми дополнительными данными комплекса (стоимость,… …   Математическая энциклопедия

  • Сетевая модель данных — логическая модель данных в виде произвольного графа. См. также: Структуры баз данных Финансовый словарь Финам …   Финансовый словарь

  • СЕТЕВАЯ МОДЕЛЬ OSI — Open Systems Interconnection Basic Reference Model базовая эталонная модель взаимодействия открытых систем абстрактная сетевая модель для коммуникаций и разработки сетевых протоколов. Представляет уровневый подход к сети. Каждый уровень… …   Словарь бизнес-терминов

  • сетевая модель данных — Модель данных, предназначенная для представления данных сетевой структуры и манипулирования ими. [ГОСТ 20886 85] Тематики организация данных в сист. обраб. данных …   Справочник технического переводчика

  • Сетевая модель данных — Необходимо перенести в эту статью содержимое статьи Сетевая СУБД и поставить оттуда перенаправление. Вы можете помочь проекту, объединив статьи (cм. инструкцию по объединению). В случае необходимости обсуждения целесообразности объединения,… …   Википедия

  • Сетевая модель OSI — В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете …   Википедия

  • Сетевая модель данных — 60. Сетевая модель данных Модель данных, предназначенная для представления данных сетевой структуры и манипулирования ими Источник: ГОСТ 20886 85: Организация данных в системах обработки данных. Термины и определения …   Словарь-справочник терминов нормативно-технической документации

  • Сетевая модель ВОС — …   Википедия

  • СЕТЕВАЯ МОДЕЛЬ ДЕЯТЕЛЬНОСТИ ОПЕРАТОРА — представление деятельности оператора решению той или иной задачи управления в виде сетевой модели. Для ее построения деятельность оператора разбивается на ряд отдельных действий, имеющих вполне определенный смысл. Такими действиями могут быть… …   Энциклопедический словарь по психологии и педагогике

Сетевая модель данных — Национальная библиотека им. Н. Э. Баумана

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 20:28, 12 июня 2017.

Сетевая модель данных — логическая модель данных, являющаяся расширением иерархического подхода, строгая математическая теория, описывающая структурный аспект, аспект целостности и аспект обработки данных в сетевых базах данных[1].
Сетевая модель представляет собой структуру, у которой любой элемент может быть связан с любым другим элементом.Сетевая база данных состоит из наборов записей, которые связаны между собой так, что записи могут содержать явные ссылки на другие наборы записей. Тем самым наборы записей образуют сеть. Связи между записями могут быть произвольными, и эти связи явно присутствуют и хранятся в базе данных.

Наиболее известными сетевыми СУБД являются IDMS, DBMS и db_VISTA III.

История

Сетевая модель была одним из первых подходов, использовавшимся при создании баз данных в конце 50-х — начале 60-х годов. Исторически на разработку этого стандарта большое влияние оказал американский ученый Ч.Бахман. Идеи Бахмана послужили основой для разработки стандартной сетевой модели под эгидой организации CODASYL. После публикации отчетов рабочей группы этой организации в 1969, 1971 и 1973 годах многие компании привели свои сетевые базы данных более-менее в соответствие со стандартами CODASYL. До середины 70-х годов главным конкурентом сетевых баз данных была иерархическая модель данных, представленная ведущим продуктом компании IBM в области баз данных — IBM IMS.

В конце 60-х годов Эдгаром Коддом была предложена реляционная модель данных и после долгих и упорных споров с Бахманом реляционная модель приобрела большую популярность и теперь является доминирующей на рынке СУБД.

Основные понятия используемые в сетевой модели данных

Элемент данных – минимальная информационная единица доступная пользователю.

Агрегат данных – это именованная совокупность данных внутри одной записи. Имя агрегата используется для его идентификации в схеме структуры данного более высокого уровня. Агрегат данных может быть простым, если состоит только из элементов данных, и составным, если включает в свой состав другие агрегаты.

Запись — это конечный уровень обобщения данных. Иными словами, запись — это агрегат, который не входит в состав никакого другого агрегата и может иметь сложную иерархическую структуру, поскольку допускается многократное применение агрегации. Имя записи используется для идентификации типа записи в схемах типов структур более высокого уровня.

Тип записей – это совокупность логически связанных экземпляров записей. Тип записей представляет некоторый класс реального мира.

Набор — именованная двухуровневая иерархическая структура, которая содержит запись владельца и запись (или записи) членов. Наборы отражают связи «один ко многим» и «один к одному» между двумя типами записей.

Особенности сетевой модели данных

  • Связи в сетевой модели данных осуществляются наборами, которые реализуются с помощью указателей. Сетевая модель данных являются особым витком в развитии иерархической модели данных, их основным отличием является то, что в сетевых моделях данных имеются указатели в обоих направлениях, которые соединяют родственную информацию.
  • Сетевая модель данных предпологает наличие в ней произвольного количества записей и наборов в том числе их различных типов.
  • Связь между двумя записями может выражаться произвольным количеством наборов.
  • В любом наборе может быть только один владелец.
  • Тип записи может быть владельцем в одних типах наборов и членом в других типах наборов, а также не входить ни в какой тип наборов.
  • Допускается добавление новой записи в качестве экземпляра владельца, если экземпляр-член отсутствует.
  • При удалении записи-владельца удаляются соответствующие указатели на экземпляры-члены, но сами записи-члены не уничтожаются (сингулярный набор).

Управление сетевыми данными

Операции с сетевыми данными можно разделить на две группы: навигационные операции с данными и операции модификации данных.

Навигационные операции с данными

Навигационные операции сетевых баз данных осуществляют переход по связям, определенных в схеме баз данных, в результате таких переходов определяется запись, которую называют текущей.

  • Найти конкретную запись в наборе однотипных записей и сделать ее текущей;
  • Перейти от записи-владельца к записи-члену в некотором наборе;
  • Перейти к следующей записи в некоторой связи;
  • Перейти от записи-члена к владельцу по некоторой связи.

Операции модификации данных

Операций модификации сетевых баз данных осуществляют добавление новых записей данных, добавление новых наборов данных, удаление записей данных и наборов записей, модификация агрегатов и элементов данных.

  • извлечь текущую запись в буфер прикладной программы для обработки;
  • заменить в извлеченной записи значения указанных элементов данных на заданные новые их значения;
  • запомнить запись из буфера в БД;
  • создать новую запись;
  • уничтожить запись;
  • включить текущую запись в текущий экземпляр набора;
  • исключить текущую запись из текущего экземпляра набора.

См. также

Источники

Ссылки

  1. http://wiki.mvtom.ru/index.php/%D0%A1%D0%B5%D1%82%D0%B5%D0%B2%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
  2. http://zametkinapolyah.ru/zametki-o-mysql/setevaya-baza-dannyx-setevaya-model-dannyx.html#i-4
  3. http://www.bseu.by/it/tohod/lekcii2_2.htm

1. Сетевая модель и ее основные элементы.

Сетевая
модель
представляет
собой план выполнения некоторого
комплекса взаимосвязанных работ
(операций), заданного в специфической
форме сети, графическое изображение
которой называется сетевым
графиком.
Отличительной
особенностью сетевой модели является
четкое определение всех временных
взаимосвязей предстоящих работ.

Главными
элементами сетевой модели являются
событиями
и
работы

Термин
работа
используется
в СПУ в широком смысле.Во-первых,
это действительная
работа —
протяженный
во временипроцесс,
требующий затрат ресурсов (например,
сборка изделия, испытание прибора и
т.п.). Каждая действительная работа,
должна быть конкретной, четко описанной
и иметь ответст­венного исполнителя.

Во-вторых,
это ожидание
протяженный
во времени процесс,не
требующий затрат труда (например, процесс
сушки после окраски,
старения металла, твердения бетона и
т.п.).

В-третьих,
это зависимость,
или
фиктивная
работа —
логическая
связь между двумя или несколькими
работами (события), не
требующими затрат труда, материальных
ресурсов или времени.
Она указывает, что возможность одной
работы непосредственно
зависит от результатов другой. Естественно,
что продолжительность фиктивной работы
принимается равной нулю.

Событие

это
момент завершения какого-либо процесса,
отражающий отдельный этап выполнения
проекта.
Событие
может являться
частным результатом отдельной работы
или суммарным результатом
нескольких работ. Событие может свершиться
только тогда,
когда закончатся все работы, ему
предшествующие. Последующие работы
могут начаться только тогда, когда
событие свершится. Отсюда двойственный
характер
события: для всех непо­средственно
предшествующих ему работ оно является
конечным,
а для всех непосредст­венно следующих
за ним — начальным.
При этом предполагается,
что событие не имеет про
должительности
и свершается как бы мгновенно
.
Поэтому каждое событие, включаемое в
сетевую модель, должно быть полно, точно
и всесторонне определено, его формулировка
должна включать в себя результат всех
непосредственно предшествующих ему
работ.

Среди
событий сетевой модели выделяют исходное
и завершающее события. Исходное собы­тие
не имеет предшествующих работ и событий,
относящихся к представленному в модели
комплексу работ. Завершающее событие
не имеет последующих работ и событий.

События
на сетевом графике (или, как еще говорят,
на графе)изображаются
кружками (вершинами графа), а работы —
стрелками(ориентированными
дугами), показывающими связь между
работами. Пример фрагмента сетевого
графика представлен на рис 1:

Рис.
2
Рис.
1

На
рис. 2, а
приведен
сетевой график задачи моделирования и
построения оптималь­ного
плана некоторого экономического объекта.
Чтобы решить эту задачу, необходимо
провести следующие работы: А –
сформулировать проблему
исследования; В5
матема­тическую
модель изучаемого объекта; В
собрать
информацию; Г

выбрать метод решения задачи; Д
построить
и
отладить программу для ЭВМ; Е
рассчитать
опти­мальный план;
Ж
передать
результаты расчета заказчику. Цифрами
на графике обозначены номера событий,
к которым приводит
выполнение соответствующих работ.

Из
графика, например, следует, что работы
В
и
Г
можно
начать выполнять
независимо одна от другой только после
свершения события
3, т.е. когда выполнены работы А
и
Б;
работу
Д
после
свершения
события 4,
когда
выполнены работы А,
Б
и
Г;
а
работу
Е
можно
выполнить только после наступления
события 5,
т.е.
при выполнении
всех предшествующих ему работ А,
Б, В, Г и Д.

В
сетевой модели, представленной на рис.
2 а,
нет
числовых оценок.
Такая сеть называется структурной.
Однако
на практике чаще всего используются
сети, в которых заданы оценки
про­должительности
работ (указываемые в часах, неделях,
декадах, месяцах
и т.д. над соответствую­щими стрелками),
а также оценки других
параметров, например трудоемкости,
стоимости и т.п. Именно
такие сети мы будем рассматривать в
дальнейшем.

Но
прежде сделаем следующее замечание. В
рассмотренных примерах
сетевые графики со­стояли из работ и
событий. Однако может
быть и иной принцип построения сетей —
без событий. В такой
сети вершины графа (например, изображенные
прямоугольниками)
означают определен­ные работы, а
стрелки — зависимости
между этими работами, определяющие
порядок их выполнения.
В качестве примера сетевой график
«события — работы»
задачи моделирования и построе­ния
оптимального плана некоторого
экономического объекта, приведенный
на рис. 2 а,
пред­ставлен
в виде сети «работы — связи» на
рис. 2 б.
А
сетевой
график «события — работы» той же
задачи, но с неудачно составленным
перечнем работ, представлен на рис. 2 в
(см.
правило
3 в разд. 3).

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

Сетевая база данных. Сетевая модель данных. Концептуальная модель и структура сетевой БД.

Здравствуйте, уважаемые посетители моего скромного блога для начинающих вебразработчиков и web мастеров ZametkiNaPolyah.ru. Продолжаем рубрику Заметки о MySQL, в которой уже были публикации: Нормальные формы и транзитивная зависимость, избыточность данных в базе данных, типы и виды баз данных, настройка MySQL сервера и файл my.ini, MySQL сервер, установка и настройка, Архитектура СУБД и архитектура баз данных. Сегодня я бы хотел более подробно остановиться на сетевых базах данных, в общем-то, в одной из прошлых публикация я практически вскользь упоминал о них, но особой ясности не вносил. Следует сказать, что сетевая база данных относится к теоретико-графовым моделям, про то, что такое графы я постараюсь объяснить в другой публикации, сейчас этот момент не столь важен, но если хотите, то почитайте учебник математики. В этой публикации я постараюсь доступным и понятным языком рассказать о сетевых базах данных и принципе их работы, как обычно всю математику я сведу к минимуму и все умные термины оставлю за пределами данной публикации. Там, где я не смогу что-то объяснить без специфической терминологии, а такие моменты могут появиться, я все обязательно поясню.

Так вот, сетевые базы данных относятся к теоретико-графовым моделям баз данных, помимо сетевых баз данных сюда еще входят иерархические базы данных. Кстати, на основе математики сетевых баз данных существуют различные СУБД, это в основном коммерческие версии. У сетевых баз данных существуют характерные операции навигации, манипуляции и управления данными, с которыми мы и постараемся разобраться в данной публикации. Стоит сказать, что помимо теоретико-графовой модели баз данных существует еще и теоретико-множественная модель, к которой относятся реляционные базы данных, математика которых заложена в MySQL сервере, но до них мы еще обязательно дойдем. А теперь приступим к рассмотрению сетевой модели данных.

Не забываем подписываться на RSS-ленту и на публичную страницу Вконтакте.

Сетевая модель данных

Содержание статьи:

Прежде чем перейти к описанию процессов, которые происходят внутри сетевой модели данных, давайте ознакомимся со структурой сетевой базы данных, чтобы иметь представление о том, с чем предстоит иметь нам дело. Прежде всего, следует разобраться со словом сети, которое присутствует в название: «сетевая модель». Сети – это естественный способ представления отношений между объектами базы данных и связей между этими объектами. Под словом объекты следует понимать таблицы баз данных или сущности. В общем, как вам удобно, так и называйте, вас везде поймут правильно.

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

Структура сетевой базы данных, пример

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

Структура сетевых баз данных

Сетевые базы данных имеют достаточно простую структуру, во всяком случае, сетевая модель имеет более простую структуру, нежели реляционная модель. Структура сетевых баз данных состоит из четырех компонентов, то есть в сетевой модели используют четыре типа структур данных. Два из которых являются главными и два, если можно так сказать, не главными. Главные типы структур сетевых данных – это запись и набор. Вспомогательные типы структур сетевой модели данных, которые используются для построения главных структур – это элемент данных и агрегат данных. Сама структура сетевой базы данных выглядит так:

Сетевая модель данных, пример

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

Элемент данных – это наименьшая информационная именованная единица данных, доступная пользователю, если провести аналогию с файловой системой, то это поле в файловой системе, если проводит аналогию с реляционной базой данных, то элемент данных – один столбец таблицы реляционной БД. Если говорить точнее, то это подстолбец. Не знаю, как правильно выразиться, вообще, я косноязычен.

Агрегат данных – это следующий уровень обобщения данных сетевой модели. Агрегат данных – это именованная совокупность данных внутри одной записи. Аналогию с реляционными БД тут не проведешь, поскольку агрегат данных – это столбец над столбцами, который объединяет элементы данных по логике их содержимого, следующий рисунок внесет ясность во все выше написанное:

Агрегат данных сетевой модели данных

На данном рисунке видно, что дата – это агрегат данных структуры сетевой модели, а день, месяц и год – это элемент данных сетевой БД.

Запись в сетевой модели данных – это конечный уровень обобщения данных, что-то наподобие таблицы в реляционной базе данных. Каждая запись в сетевой базе данных должна обладать или содержать в себе, как минимум один именованный элемент данных, если элементов внутри записи более одного, то каждый элемент данных должен обладать уникальным форматом.

Давайте разбираться со структурой сетевых баз данных на примере, поскольку так будет более понятно и доступно. Представим, что мы хотим создать запись в сетевую базу данных, назовем ее скажем «Сотрудник», в которую обязательно должен входить агрегат данных, который представлен на рисунке выше, его мы назовем «Дата». В эту запись нам необходимо будет добавить: табельный номер, ФИО и адрес сотрудника. Выглядеть такая запись в сетеовой модели данных будет следующим образом:

Записей сетевой базы данных

Прежде, чем переходить к набору записей, нужно разобраться с тем, что такое тип записи и для чего нужен тип записи в сетевой базе данных. И так, тип записей – это совокупность логически связанных экземпляров записей. Проще сказать – это все записи, которые связаны между собой по смыслу и, которые дополняют друг друга. Если переложить термин тип записей на реальный мир, то это информационная модель (иначе, полное описание) какого-либо объекта из реального мира, например сотрудника фирмы.

Как видно из рисунка выше: в качестве элементов данных сетевой модели могут быть использованы только простые типы, если хотите данных, но это не совсем так. Потому что в качестве агрегатов данных можно использовать сложные типы. Сложные типы в структуре сетевых баз данных бывают двух видов: вектор и повторяющаяся группа. Агрегат типа вектор соответствует линейному набору элементов данных, такой агрегат вы уже видели, он называется у нас «Дата», ну это чтобы вы представляли себе, что такое линейный набор элементов данных.

Агрегат типа повторяющаяся группа – это совокупность векторов данных (то есть несколько векторов). Для большей ясности давайте представим новый агрегат данных, который назовем, ну скажем «Товар»:

Агрегат типа повторяющаяся группа

Товары обычно хранятся на складе или их продают, зачастую по нескольку штук. Я хочу подвести к тому, что агрегат типа повторяющаяся группа – это несколько агрегатов типа вектор, объединенных вместе, допустим, у нас покупают 5 товаров, значит, если наш агрегат «Товар» будет иметь тип повторяющаяся группа, то он будет состоять из 5 агрегатов типа вектор, примерно так.

Перейдем к дальнейшему рассмотрению структуры сетевой модели данных. Набор записей – это именованная двухуровневая иерархическая структура, которая содержит управляемую и управляющую записи. При помощи наборов указывается тип связи между записями. Что это означает? Проще говоря, набор это две записи, между которыми есть связь: один ко многим или один к одному. Представим, что у нас имеется две записи в сетевой базе данных: запись «Сотрудник», структуру которой я привел выше и запись «Отдел», структура которой в данном контексте нам не важна.

Перед нами стоит задача: осуществить логическую связь между двумя этими записями, то есть определить какая запись будет управляемой, а какая управляющей. Логично предположить, что запись «Отдел» должна быть управляющей, поскольку сотрудник работает в отделе, а не отдел в сотруднике. И понятно, что связь между этими записями должна быть один ко многим, потому что отдел один, а сотрудников много, назовем эту связь «Работает». И так, мы приходим к выводу, что набор записей сетевой модели данных определяет: управляющую запись, в нашем случае это «Отдел», подчиненную запись, которую мы назвали «Сотрудник», а так же тип связи между этими записями, которую мы обозвали «Работает». «Работает» — это не только имя связи, но еще и метка, которая именует сам набор данных сетевой модели. Впрочем, рисунок должны внести ясность в мои несколько путаные пояснения:

Набор записей сетевой модели данных

В данном случае связь один ко многим говорит нам о том, что с одним экземпляром записи «Отдел» может быть связано ноль, один или несколько экземпляров записи «Сотрудник». Экземпляр записи – это что-то наподобие кортежа (строки таблицы) из реляционной БД. Использую понятия сетевой модели данных, приведенные выше, можно нарисовать набор записей по-другому. На рисунке можно отобразить логические типы данных для обеих записей, структуру записей сетевой модели данных и указать связь между записями, которую мы обозвали «Работает»:

Теперь обобщим все то, что было написано выше про структуру сетевой базы данных, собственно обобщает все база данных. База данных сетевой модели данных – это  именованная совокупность экземпляров записей различного типа и экземпляров наборов, хранящих в себе типы связей между записями. Проще говоря, это все записи и все связи между записями. Что же, мы познакомились со структурой сетевой модели данных, рассмотрели несколько примеров и заодно ознакомились с самыми простыми основами проектирования сетевых баз данных. Жаль, что я ничего не писал про концептуальное проектирование баз данных и концептуальную модель данных. В дальнейшем постараюсь исправить этот недостаток, потому что следующий раздел будет связан с концептуальной моделью.

Преобразование концептуальной модели в сетевую модель данных

На детальное рассмотрение концептуальное модели данных и концептуального проектирования баз данных может потребоваться пара публикаций, а ограничиваться общими словами я не хочу, поэтому сейчас, уважаемые посетители, я буду считать, что вы имеете представление о том, что такое концептуальная модель, если не знаете, то тут два выхода: либо вы ждете соответствующую публикацию на моем блоге, либо пользуетесь поисковыми системами. Думаю, на других сайтах люди пишут не хуже меня, а может быть и лучше. Если вы ничего не знаете про концептуальную модель данных, то смело пропускайте данный раздел.

Сетевую модель данных можно легко получить из концептуальной модели, причем нужно соблюсти всего лишь одно условие: в концептуальной модели данных должны использоваться только бинарные связи, которые принадлежат к типам: «один к одному» или «один ко многим». При этом вместо сущностей концептуальной модели данных следует использовать типы записей сетевой базы данных, собственно, имена сущностей из одной будут являться именами типов записей другой модели данных. Атрибуты, которые есть у сущностей (иначе столбцы таблицы) превращаются в поля записей сетевой модели данных, а связи между сущностями становятся связями между типами записей.

Бинарные связи концептуальной модели данных без затруднений переносятся на сетевую модель данных. Связь один ко многим переносится следующим образом: тип записи со стороны один становится управляющей записью, а тип записи со стороны многим становится подчиненной записью. Для связи один к одному запись владелец и подчиненная запись определяется произвольно.

Управление сетевыми данными

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

Навигационные операции сетевых баз данных осуществляют переход по связям, определенных в схеме баз данных, в результате таких переходов определяется запись, которую называют текущей (запись сетевой модели, с которой мы будем работать). К навигационным операциям можно отнести:

  • найти конкретную запись в наборе однотипных записей и сделать ее текущей;
  •  перейти от записи-владельца к записи-члену в некотором наборе;
  •  перейти к следующей записи в некоторой связи;
  • перейти от записи-члена к владельцу по некоторой связи.

При помощи операций модификации сетевых баз данных осуществляется добавление новых записей данных, добавление новых наборов данных, удаление записей данных и наборов записей, модификация агрегатов и элементов данных. Для реализации этих операций в системе текущее состояние детализируется путем запоминания трех его составляющих: текущего набора, текущего типа записи, текущего экземпляра типа записи. В такой ситуации возможны следующие операции:

  • извлечь текущую запись в буфер прикладной программы для обработки;
  • заменить в извлеченной записи значения указанных элементов данных на заданные новые их значения;
  • запомнить запись из буфера в БД;
  • создать новую запись;
  • уничтожить запись;
  • включить текущую запись в текущий экземпляр набора;
  • исключить текущую запись из текущего экземпляра набора.

Поддержание ограничений целостности в сетевых моделях в принципе не требуется. На этом всё, спасибо за внимание, надеюсь, что был хоть чем-то полезен и до скорых встреч на страницах блога для начинающих вебразработчиков и вебмастеров ZametkiNaPolyah.ru. Не забываем комментировать и делиться с друзьями;)

Сверточная сеть

для классификации и обнаружения

VGG16 — это модель сверточной нейронной сети, предложенная К. Симоняном и А. Зиссерманом из Оксфордского университета в статье «Очень глубокие сверточные сети для распознавания крупномасштабных изображений». Модель достигает 92,7% точности тестов из топ-5 в ImageNet, который представляет собой набор данных из более чем 14 миллионов изображений, принадлежащих к 1000 классам. Это была одна из самых известных моделей, представленных на ILSVRC-2014. Он обеспечивает улучшение по сравнению с AlexNet за счет замены фильтров большого размера ядра (11 и 5 в первом и втором сверточном слое соответственно) несколькими фильтрами размера ядра 3 × 3 один за другим.VGG16 обучалась неделями и использовала графические процессоры NVIDIA Titan Black.

DataSet

ImageNet — это набор данных из более чем 15 миллионов помеченных изображений с высоким разрешением, принадлежащих примерно к 22 000 категориям. Изображения были собраны из Интернета и маркированы людьми, использующими краудсорсинговый инструмент Amazon Mechanical Turk. Начиная с 2010 года, в рамках Pascal Visual Object Challenge проводится ежегодный конкурс ImageNet Large-Scale Visual Recognition Challenge (ILSVRC).ILSVRC использует подмножество ImageNet с примерно 1000 изображений в каждой из 1000 категорий. Всего существует примерно 1,2 миллиона обучающих изображений, 50 000 изображений для проверки и 150 000 изображений для тестирования. ImageNet состоит из изображений с переменным разрешением. Поэтому изображения были уменьшены до фиксированного разрешения 256 × 256. Для прямоугольного изображения изображение масштабируется и вырезается центральный фрагмент 256 × 256 из полученного изображения.

Архитектура

Архитектура, изображенная ниже, — VGG16.

Архитектура VGG16

Вход на слой cov1 представляет собой изображение RGB фиксированного размера 224 x 224. Изображение проходит через стопку сверточных (сверточных) слоев, в которых использовались фильтры с очень маленьким принимающим полем: 3 × 3 (что является наименьшим размером, чтобы уловить понятие левого / правого, верхнего / нижнего, центрального ). В одной из конфигураций он также использует фильтры свертки 1 × 1, которые можно рассматривать как линейное преобразование входных каналов (с последующей нелинейностью). Шаг свертки равен 1 пикселю; пространственный отступ конв.входной слой таков, что пространственное разрешение сохраняется после свертки, то есть заполнение составляет 1 пиксель для свертки 3 × 3. слои. Пространственное объединение выполняется пятью слоями максимального объединения, которые следуют за некоторыми конвенциями. слои (не для всех конв. слоев следует max-pooling). Максимальное объединение выполняется в окне 2 × 2 пикселя с шагом 2.

Три полностью соединенных (FC) уровня следуют за стеком сверточных слоев (который имеет разную глубину в разных архитектурах): первые два имеют 4096 каналов каждый, третий выполняет 1000-позиционную классификацию ILSVRC и, таким образом, содержит 1000 каналов (один для каждый класс).Последний слой — это слой soft-max. Конфигурация полносвязных слоев одинакова во всех сетях.

Все скрытые слои снабжены функцией выпрямления (ReLU) нелинейности. Также следует отметить, что ни одна из сетей (кроме одной) не содержит Local Response Normalization (LRN), такая нормализация не улучшает производительность набора данных ILSVRC, но приводит к увеличению потребления памяти и времени вычислений.

Конфигурации

Конфигурации ConvNet показаны на рисунке 02.Сети называются своими именами (A-E). Все конфигурации соответствуют общему дизайну, присутствующему в архитектуре, и различаются только глубиной: от 11 весовых уровней в сети A (8 конвенционных и 3 FC уровня) до 19 весовых уровней в сети E (16 конвенционных и 3 уровня FC) . Ширина конв. слоев (количество каналов) довольно мало, начиная с 64 в первом слое и затем увеличиваясь в 2 раза после каждого уровня максимального объединения, пока не достигнет 512.

Рис. 2

Примеры использования и реализация

К сожалению, у VGGNet есть два основных недостатка:

  1. Это мучительно медленно, тренироваться.
  2. Сами веса сетевой архитектуры довольно велики (относительно диска / пропускной способности).

Из-за своей глубины и количества полностью подключенных узлов размер VGG16 превышает 533 МБ. Это делает развертывание VGG утомительной задачей. VGG16 используется во многих задачах классификации изображений с глубоким обучением; однако часто более предпочтительны меньшие сетевые архитектуры (такие как SqueezeNet, GoogLeNet и т. д.). Но это отличный строительный блок для целей обучения, поскольку его легко реализовать.

[Pytorch]

[Tensorflow]

[Керас]

Результат

VGG16 значительно превосходит модели предыдущего поколения в соревнованиях ILSVRC-2012 и ILSVRC-2013.Результат VGG16 также конкурирует за победителя задачи классификации (GoogLeNet с ошибкой 6,7%) и существенно превосходит победившую заявку ILSVRC-2013 Clarifai, которая достигла 11,2% с данными внешнего обучения и 11,7% без них. Что касается производительности одной сети, архитектура VGG16 дает лучший результат (ошибка теста 7,0%), превосходя одну сеть GoogLeNet на 0,9%.

Было продемонстрировано, что глубина представления благоприятна для точности классификации, и что современная производительность набора данных задачи ImageNet может быть достигнута с использованием традиционной архитектуры ConvNet с существенно увеличенной глубиной.

.

Глава 1: Что такое сеть?

Что такое сеть?

Сеть состоит из двух или более компьютеров, связанных между собой для совместного использования ресурсов (например, принтеров и компакт-дисков), обмена файлами или обеспечения электронной связи. Компьютеры в сети могут быть связаны с помощью кабелей, телефонных линий, радиоволн, спутников или инфракрасных лучей.

Два очень распространенных типа сетей включают:

Вы также можете увидеть ссылки на городские сети (MAN), беспроводную локальную сеть (WLAN) или беспроводную глобальную сеть (WWAN).

Локальная сеть (LAN) — это сеть, ограниченная относительно небольшой площадью. Обычно он ограничен географической областью, такой как письменная лаборатория, школа или здание.

Компьютеры, подключенные к сети, в широком смысле классифицируются как серверы или рабочие станции. Серверы обычно не используются людьми напрямую, а работают непрерывно, чтобы предоставлять «услуги» другим компьютерам (и их пользователям-людям) в сети.Предоставляемые услуги могут включать печать и отправку факсов, размещение программного обеспечения, хранение и совместное использование файлов, обмен сообщениями, хранение и поиск данных, полный контроль доступа (безопасность) к ресурсам сети и многое другое.

Рабочие станции называются таковыми, потому что обычно у них есть человек, который через них взаимодействует с сетью. Рабочие станции традиционно считались настольными компьютерами, состоящими из компьютера, клавиатуры, дисплея и мыши, или ноутбуком со встроенной клавиатурой, дисплеем и тачпадом.С появлением планшетных компьютеров и устройств с сенсорным экраном, таких как iPad и iPhone, наше определение рабочих станций быстро расширяется и включает в себя эти устройства из-за их способности взаимодействовать с сетью и использовать сетевые службы.

Серверы, как правило, более мощные, чем рабочие станции, хотя конфигурации зависят от потребностей. Например, группа серверов может быть расположена в безопасном месте, вдали от людей, и доступ к ним возможен только через сеть.В таких случаях серверы обычно работают без специального дисплея или клавиатуры. Однако размер и скорость процессора (ов) сервера, жесткого диска и основной памяти могут значительно увеличить стоимость системы. С другой стороны, рабочей станции может не потребоваться столько хранилища или рабочей памяти, но для удовлетворения потребностей пользователя может потребоваться дорогой дисплей. Каждый компьютер в сети должен быть соответствующим образом настроен для его использования.

В одной локальной сети компьютеры и серверы могут быть соединены кабелями или по беспроводной сети.Беспроводной доступ к проводной сети стал возможным благодаря точкам беспроводного доступа (WAP). Эти устройства WAP обеспечивают мост между компьютерами и сетями. Типичный WAP может иметь теоретическую емкость для подключения сотен или даже тысяч пользователей беспроводной сети к сети, хотя практическая емкость может быть намного меньше.

.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *