Документационное обеспечение управления

Контрольная

Вариант 4

1. Протокол, виды протоколов, особенности оформления 4

2. Обработка отправляемой корреспонденции 9

3. Оформить акт списания имущества 11

4. Составить докладную записку 12

Библиографический список 14

1. Протокол, виды протоколов, особенности оформления

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

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

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

Основные виды протокола:

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

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

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

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

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

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

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

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

Рассмотренные на совещании вопросы перечисляются в разделе ПОВЕСТКА ДНЯ. Слова ПОВЕСТКА ДНЯ печатают от нулевого положения печатающего устройства, после них ставится двоеточие. Вопросы повестки дня нумеруются. Каждый новый вопрос печатают от 1-го положения табулятора. Последовательность расположения вопросов определяется степенью их важности. Формулировка вопросов повестки дня должна начинаться с предлогов о (об), наименование должности и фамилию докладчика дают в родительном падеже. Основная часть текста протокола строится в соответствии с вопросами повестки дня. Построение записи обсуждения каждого вопроса повестки дня осуществляется по схеме: СЛУШАЛИ ВЫСТУПИЛИ ПОСТАНОВИЛИ (РЕШИЛИ). Эти слова печатают прописными буквами. Перед словом СЛУШАЛИ ставят номер вопроса повестки дня, после двоеточие. Фамилию докладчика печатают в именительном падеже от 1-го положения печатающего устройства; после фамилии ставят инициалы, затем тире и с прописной буквы пишут содержание доклада в форме прямой речи. Если текст доклада (выступления) застенографирован или представлен докладчиком в письменной форме, то после тире также с прописной буквы пишут «Доклад прилагается» (в протоколе без кавычек).

Обсуждению доклада могут предшествовать вопросы к докладчику, которые вместе с ответами включаются в раздел СЛУШАЛИ. Перед записью каждого вопроса указываются инициалы, фамилия и должность его автора и ставится тире. Содержание вопроса записывается с прописной буквы в форме прямой речи. Перед формулировкой ответа пишется слово «Ответ» (в протоколе без кавычек), ставится тире и записывается ответ в форме прямой речи. Ход обсуждения доклада отражается в разделе ВЫСТУПИЛИ. После слова ВЫСТУПИЛИ ставится двоеточие. Фамилию выступающего пишут в именительном падеже от 1го положения печатающего устройства, затем указывают инициалы и должность выступающего, ставят тире и с прописной буквы печатают содержание выступления в форме косвенной речи.

Принятые решения содержатся в разделе ПОСТАНОВИЛИ (РЕШИЛИ). Если решений несколько, они нумеруются арабскими цифрами с точкой. Как правило, каждое решение сопровождается указанием должности, фамилии и инициалов ответственного за его выполнение и содержит срок исполнения. Принимаемые коллегиально решения нередко требуют голосования. В этом случае после раздела ПОСТАНОВИЛИ указывается: «Голосование» или «Голосовали» (в протоколе без кавычек) и приводятся результаты голосования: единогласно или за..., против..., воздержались...

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

все реквизиты заголовочной части протокола: наименование организации, наименование вида документа (ВЫПИСКА ИЗ ПРОТОКОЛА), дату (дата заседания), номер протокола (порядковый номер заседания), место составления (место проведения заседания);

заголовок к тексту;

все реквизиты вводной части текста протокола: «Председатель», «Секретарь», «Присутствовали», «Приглашенные», «ПОВЕСТКА ДНЯ»;

отдельные реквизиты основной части текста протокола: «СЛУШАЛИ», «ПОСТАНОВИЛИ», «Голосование»;

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

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

HTTP - это протокол передачи гипертекста между распределёнными системами. По сути, http является фундаментальным элементом современного Web-а. Как уважающие себя веб разработчики, мы должны знать о нём как можно больше.

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

Также в этой статье я буду, в основном, ссылаться на стандарт RFC 2616 : Hypertext Transfer Protocol -- HTTP/1.1.

Основы HTTP

HTTP обеспечивает общение между множеством хостов и клиентов, а также поддерживает целый ряд сетевых настроек.

В основном, для общения используется TCP/IP, но это не единственный возможный вариант. По умолчанию, TCP/IP использует порт 80, но можно заюзать и другие.

Общение между хостом и клиентом происходит в два этапа: запрос и ответ. Клиент формирует HTTP запрос, в ответ на который сервер даёт ответ (сообщение). Чуть позже, мы более подробно рассмотрим эту схему работы.

Текущая версия протокола HTTP - 1.1, в которой были введены некоторые новые фишки. На мой взгляд, самые важные из них это: поддержка постоянно открытого соединения, новый механизм передачи данных chunked transfer encoding, новые заголовки для кэширования. Что-то из этого мы рассмотрим во второй части данной статьи.

URL

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

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

Методы

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

Существующие методы:

GET : получить доступ к существующему ресурсу. В URL перечислена вся необходимая информация, чтобы сервер смог найти и вернуть в качестве ответа искомый ресурс.

POST : используется для создания нового ресурса. POST запрос обычно содержит в себе всю нужную информацию для создания нового ресурса.

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

DELETE : служит для удаления существующего ресурса.

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

Также HTTP поддерживает и другие методы:

HEAD : аналогичен GET. Разница в том, что при данном виде запроса не передаётся сообщение. Сервер получает только заголовки. Используется, к примеру, для того чтобы определить, был ли изменён ресурс.

TRACE : во время передачи запрос проходит через множество точек доступа и прокси серверов, каждый из которых вносит свою информацию: IP, DNS. С помощью данного метода, можно увидеть всю промежуточную информацию.

OPTIONS : используется для определения возможностей сервера, его параметров и конфигурации для конкретного ресурса.

Коды состояния

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

1xx: Информационные сообщения

Набор этих кодов был введён в HTTP/1.1. Сервер может отправить запрос вида: Expect: 100-continue, что означает, что клиент ещё отправляет оставшуюся часть запроса. Клиенты, работающие с HTTP/1.0 игнорируют данные заголовки.

2xx: Сообщения об успехе

Если клиент получил код из серии 2xx, то запрос ушёл успешно. Самый распространённый вариант - это 200 OK. При GET запросе, сервер отправляет ответ в теле сообщения. Также существуют и другие возможные ответы:

202 Accepted : запрос принят, но может не содержать ресурс в ответе. Это полезно для асинхронных запросов на стороне сервера. Сервер определяет, отправить ресурс или нет.
204 No Content : в теле ответа нет сообщения.
205 Reset Content : указание серверу о сбросе представления документа.
206 Partial Content : ответ содержит только часть контента. В дополнительных заголовках определяется общая длина контента и другая инфа.

3xx: Перенаправление

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

301 Moved Permanently : ресурс теперь можно найти по другому URL адресу.
303 See Other : ресурс временно можно найти по другому URL адресу. Заголовок Location содержит временный URL.
304 Not Modified : сервер определяет, что ресурс не был изменён и клиенту нужно задействовать закэшированную версию ответа. Для проверки идентичности информации используется ETag (хэш Сущности - Enttity Tag);

4xx: Клиентские ошибки

Данный класс сообщений используется сервером, если он решил, что запрос был отправлен с ошибкой. Наиболее распространённый код: 404 Not Found. Это означает, что ресурс не найден на сервере. Другие возможные коды:

400 Bad Request : вопрос был сформирован неверно.
401 Unauthorized : для совершения запроса нужна аутентификация. Информация передаётся через заголовок Authorization.
403 Forbidden : сервер не открыл доступ к ресурсу.
405 Method Not Allowed : неверный HTTP метод был задействован для того, чтобы получить доступ к ресурсу.
409 Conflict : сервер не может до конца обработать запрос, т.к. пытается изменить более новую версию ресурса. Это часто происходит при PUT запросах.

5xx: Ошибки сервера

Ряд кодов, которые используются для определения ошибки сервера при обработке запроса. Самый распространённый: 500 Internal Server Error. Другие варианты:

501 Not Implemented : сервер не поддерживает запрашиваемую функциональность.
503 Service Unavailable : это может случиться, если на сервере произошла ошибка или он перегружен. Обычно в этом случае, сервер не отвечает, а время, данное на ответ, истекает.

Форматы сообщений запроса/ответа

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

Давайте посмотрим на структуру передаваемого сообщения через HTTP:

Message = *() CRLF [] = Request-Line | Status-Line = Field-Name ":" Field-Value

Между заголовком и телом сообщения должна обязательно присутствовать пустая строка. Заголовков может быть несколько:

Тело ответа может содержать полную информацию или её часть, если активирована соответствующая возможность (Transfer-Encoding: chunked). HTTP/1.1 также поддерживает заголовок Transfer-Encoding.

Общие заголовки

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

Что-то мы уже рассмотрели в этой статье, что-то подробней затронем во второй части.

Заголовок via используется в запросе типа TRACE, и обновляется всеми прокси-серверами.

Заголовок Pragma используется для перечисления собственных заголовков. К примеру, Pragma: no-cache - это то же самое, что Cache-Control: no-cache. Подробнее об этом поговорим во второй части.

Заголовок Date используется для хранения даты и времени запроса/ответа.

Заголовок Upgrade используется для изменения протокола.

Transfer-Encoding предназначается для разделения ответа на несколько фрагментов с помощью Transfer-Encoding: chunked. Это нововведение версии HTTP/1.1.

Заголовки сущностей

В заголовках сущностей передаётся мета-информация контента:

Все заголовки с префиксом Content- предоставляют информацию о структуре, кодировке и размере тела сообщения.

Заголовок Expires содержит время и дату истечения сущности. Значение “never expires” означает время + 1 код с текущего момента. Last-Modified содержит время и дату последнего изменения сущности.

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

Формат запроса

Запрос выглядит примерно так:

SP - это разделитель между токенами. Версия HTTP указывается в HTTP-Version. Реальный запрос выглядит так:

GET /articles/http-basics HTTP/1.1 Host: www.articles.com Connection: keep-alive Cache-Control: no-cache Pragma: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Список возможных заголовков запроса:

В заголовке Accept определяется поддерживаемые mime типы, язык, кодировку символов. Заголовки From, Host, Referer и User-Agent содержат информацию о клиенте. Префиксы If- предназначены для создания условий. Если условие не прошло, то возникнет ошибка 304 Not Modified.

Формат ответа

Формат ответа отличается только статусом и рядом заголовков. Статус выглядит так:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

HTTP версия
Код статуса
Сообщение статуса, понятное для человека

Обычный статус выглядит примерно так:

HTTP/1.1 200 OK

Заголовки ответа могут быть следующими:

Age время в секундах, когда сообщение было создано на сервере.
ETag MD5 сущности для проверки изменений и модификаций ответа.
Location используется для перенаправления и содержит новый URL адрес.
Server определяет сервер, где было сформирован ответ.

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

Инструменты для определения HTTP трафика

Существует множество инструментов для мониторинга HTTP трафика. Вот несколько из них:

Наиболее часто используемый - это Chrome Developers Tools:

Если говорить об отладчике, можно воспользоваться Fiddler :

Для отслеживания HTTP трафика вам потребуется curl, tcpdump и tshark.

Библиотеки для работы с HTTP - jQuery AJAX

Поскольку jQuery очень популярен, в нём также есть инструментарий для обработки HTTP ответов при AJAX запросах. Информацию о jQuery.ajax(settings) можете найти на официальном сайте .

Передав объект настроек (settings), а также воспользовавшись функцией обратного вызова beforeSend, мы можем задать заголовки запроса, с помощью метода setRequestHeader().

$.ajax({ url: "http://www.articles.com/latest", type: "GET", beforeSend: function (jqXHR) { jqXHR.setRequestHeader("Accepts-Language", "en-US,en"); } });

Если хотите обработать статус запроса, то это можно сделать так:

$.ajax({ statusCode: { 404: function() { alert("page not found"); } } });

Итог

Вот такой вот он, тур по основам протокола HTTP. Во второй части будет ещё больше интересных фактов и примеров.

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

Какими свойствами и особенностями обладает хороший, годный грамотный, качественный протокол?

В идеале, протокол должен быть абстрагирован от более нижнего уровня взаимодействия, будь то передача по TCP, UDP, по serial порту, USB, Bluetooth, через цифровой радиосигнал, или даже по голубиной почте . И надо учитывать, что далеко не все из них гарантируют доставку и\или достоверность передающихся данных.

Небольшой дисклеймер: говоря о достоверности данных, я имею ввиду их неискаженность вследствие помех и иных ошибок в среде передачи. В статье я не буду затрагивать темы пласта технологий, связанных с безопасностью в ИТ. Допустим что наши Алиса и Боб могут друг другу доверять, и никакая Ева им помешать не может . (Например у коллег вопрос безопасности решается включением всех территориально разделенных участников взаимодействия в хорошо защищенный VPN, не имеющий в свою очередь доступа наружу)

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

Все протоколы можно разделить на две группы, (по представлению данных): символьные и бинарные .
Символьные протоколы, с которыми мне приходилось встречаться, базировались либо на XML, либо на JSON-строках. Из их достоинств можно упомянуть о более простой отладке взаимодействия (вследствие их читаемости), о простоте реализации (наличия готовых парсеров), и пресловутой универсальности.
Теперь о недостатках. Очевидно, что такие протоколы являются крайне избыточными, мизерная доля полезной информации плавает в массивной, неэффективной обёртке. При передаче любой числовой информации приходиться заниматься их конвертацией в строковое представление и обратно. Больным местом является передача бинарных данных (и хорошо, что без них бывает можно обойтись, но в ряде случаев это невозможно). Составители протоколов обычно выкручиваются применением Base64 , или даже просто передачей бинарной строки в её hex-овом представлении, по два символа на байт.
Также хочется отметить, что полная спецификация того же XML крайне обширна, и стандартные парсеры, при всей их полноте возможностей, достаточно громоздки и медлительны, поэтому распространена практика, когда отдел или контора в итоге пишет и пользуется собственным парсером.

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

Теперь бинарные протоколы. Сразу же надо вспомнить о Гулливерских войнах тупоконечников и остроконечников . Лично я симпатизирую big-endian, т.к. не считаю неявную типизацию little-endian «чем-то хорошим», да и в моей среде разработки big-endian является нативным.
Бинарные протоколы (не все, но те, которые я отношу к грамотным) можно разделить на два уровня: уровень контейнера и уровень данных. На плечи первого уровня ложится ответственность за целостность и достоверность передачи данных, а так же за доступность обнаружения сообщения в байтовом потоке, и, само собой, за хранение в себе сообщения уровня данных. Второй уровень должен содержать информацию, ради которой всё сетевое взаимодействие и затевалось, в удобном для обработки формате. Его структура в основном зависит от решаемых задач, но и по нему есть общие рекомендации (о которых ниже).

Размеры сообщений (дискретных пакетов байт, которые можно обрабатывать независимо от предыдущих и последующих принимаемых данных) бывают фиксированными и переменными . Понятно, что с фиксированным размером сообщений всё проще - вычитается, начиная с заголовка (о нём позже), определенное количество байт и отправляется на обработку. Зачастую, для обеспечения гибкости, составители таких протоколов включают в сообщение область фиксированного размера (иногда до 80% от общего объема), зарезервированное под модификации нынешнего протокола. На мой взгляд, это не самый эффективный путь обеспечения гибкости, зато избыточность появляется еще какая.
Рассмотрим сообщения переменной длины.
Тут уже можно подробней поговорить о непременном атрибуте бинарного сообщения в любом протоколе - о заголовке (Это вышеупомянутый уровень контейнера).
Обычно заголовки начинаются с константной части, позволяющей, с определенной вероятностью обнаружить начало сообщения в непрерывном байтовом потоке. Очевидно, что имеется риск появления такой константы в произвольном потоке байт, и, хотя увеличение объема этот риск снижает (я встречал константы вида 0123456789VASIA9876543210), целесообразней использовать проверки на основе подсчета контрольной суммы .
За константой обычно следует номер версии протокола, который дает нам понять, в каком формате должно происходить дальнейшее считывание (и имеем ли мы вообще возможность обработать это сообщение - вдруг такая версия нам неизвестна). Следующая важная часть заголовка: информация о самом содержимом контейнера. Указывается тип содержимого (по факту, тот же номер версии протокола для уровня данных), его длина и контрольная сумма. Имея эту информацию, можно уже без проблем и опасений считать содержимое и приступить к его разбору.
Но не прямо сразу! Заголовок должна заключать контрольная сумма его самого (исключая из расчета конечно саму контрольную сумму) - только так мы можем быть уверены в том, что считали только что не белиберду, а валидный заголовок, за которым следуют предназначенные нам данные. Не совпала контрольная сумма? Придётся искать следующее начало нового заголовка дальше по потоку…

Представим, что мы дошли до этапа, что получили наконец неискаженное сообщение уровня данных. Его структура зависит от той области задач той системы, в которой реализован ваш сетевой обмен, однако в общем виде у сообщения тоже бывает быть свой заголовочек , содержащий информацию о типе сообщения. Можно различить как общую специфику сообщения, (например «Запрос Set», «Утвердительный Ответ на Set», «Отрицательный Ответ на Set», «Запрос Get», «Ответ Get», «Потоковое сообщение»), так и конкретную область применение сообщения. Попробую привести пример с потолка:
Тип запроса: Запрос Set (0x01)
Идентификатор модуля-адресата сообщения: PowerSupplyModule (0x0A)
Идентификатор группы сообщений: UPS Management (0x02)
Идентификатор типа сообщения: Reboot (0x01)
Дальше тело сообщения может содержать информацию об адресе ИБП, который Модуль управления энергообеспечением должен перезагрузить, через сколько секунд это сделать и т.п.
На это сообщение мы рассчитываем получить ответное сообщение с типом запроса «Утвердительный Ответ» и последующими 0x0A0201 в заголовке.
Конечно, такое подробное описание типа сообщения может быть избыточным когда межсетевое взаимодействие не предусматривает большого числа команд, так что формировать структуру сообщения надо исходя из требований ТЗ.
Так же будет полезно, если сообщение с «Отрицательным Ответом» будет содержать код ошибки, из-за которой не удалось ответить на команду утвердительно.

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

upd.
Имел удовольствие пообщаться с критиком своей статьи, и теперь прихожу к осознанию, что я осветил вопрос со своей если можно так выразиться, «байтолюбской», точки зрения. Конечно, раз идет курс на универсальность обработки хранения и передачи данных, то в таком ключе символьные протоколы (в первую очередь говорю об XML) могут дать фору любым другим решениям. Но относительно попытки повсеместного их применения позволю себе процитировать Вирта:
Инструмент должен соответствовать задаче. Если инструмент не соответствует задаче, нужно придумать новый, который бы ей соответствовал, а не пытаться приспособить уже имеющийся.

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

Терминология

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

Сетевая иерархия

Канальный уровень совпадает с Ethernet. В пакете содержится набор определенных параметров, задающих его тип. Данные находятся в прямой зависимости от этого типа, а их содержание относится к сетевому уровню. Существует два самых распространенных протокола: ARP, который отвечает за преобразование IP-адресов в MAC, и сам IP-протокол. Можно привести структуру IP-пакета. Все данные, которые переносятся с его помощью, уже отправляются на конкретный сетевой адрес. В пакете имеется число в установленном формате, обозначающее тип протокола.

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

Особенности доставки пакетов

В пакете обязательно указан номер порта, куда осуществляется отправка. Обычно этот параметр определяется типом протокола на прикладном уровне - в зависимости от приложения, которому направлена информация. Можно использовать и нестандартные порты сервисов, никто этого не запрещает. Самыми известными сетевыми протоколами в данном случае являются HTTP и POP3. Получает определенная иерархия вложенности пакетов. В Ethernet-пакет вложен IP, далее TCP или UDP, а потом данные, ориентированные на конкретное приложение.

Отличительные характеристики

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

IP и TCP/IP

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

Локальные и коммутируемые сети

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

Протокол IPX

Данный комплект был разработан компанией Novell с целью использования для собственной ОС NetWare. IPX частично схож с TCP/IP, то есть в него включены некоторые протоколы из данного пакета, но компания защитила его авторскими правами. Однако корпорация Microsoft создала свой протокол, совместимый с этим, предназначенный для операционных систем из семейства Windows. IPX представляет собой сетевой протокол, который в плане функционала аналогичен IP. SPX - это инструмент дл транспортного уровня, который предназначен для обеспечения обмена пакетными данными между отдельными машинами.

На данный момент этот протокол применяют только в сетях с серверами, где установлены старые версии операционной системы NetWare. Часто его используют в комплекте с какими-то другими наборами сетевых протоколов. Теперь компания Nowell полностью перешла на новый универсальный протокол TCP/IP.

NetBEUI

Данный сетевой протокол применяется в сетях малых размеров. Его впервые представили в Windows NT 3.1, а также в нескольких последующих версиях этой системы, где он использовался по умолчанию. В последних версиях систем его место занял уже известный нам TCP/IP. Этот протокол довольно прост, ему не хватает многих функций, используемых в более продвинутых вариантах. Он не подходит для межсетевого обмена данными. Он может пригодиться для простой однако теперь он даже не представлен в качестве стандартного компонента ОС, его требуется устанавливать самостоятельно с диска.

NetBEUI - это удобное средство для создания прямого кабельного подключения, и в этом смысле это минимальный протокол, который требуется для формирования одноранговой сети в версиях Windows 9x.

Выводы

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