Реинициализация узла при ошибке

7. В процессе работы в тегах иногда появляются недостоверные значения.

Такая ситуация может возникать при работе по радио и GSM каналам по протоколу Modbus RTU и ASCII (при работе по Modbus TCP такая ситуация не возможна). Это происходит из-за «наслоения» ответов. В Modbus RTU нет специального поля, по которому можно было бы определить соответствие ответа определенному запросу (в Modbus TCP такое поле есть – Transaction ID). Представим ситуацию, ОРС сервер послал запрос в устройство, устройство ответило, но возникла задержка в сети (в GSM сетях это обычное явление), ОРС сервер не получил ответ и отправил запрос повторно, ему пришел ответ на предыдущий запрос – он корректен, ОРС сервер разобрал его и послал следующий запрос (следующего регистра), ему приходит ответ от предыдущего запрос – но в нем содержаться данные совершенно от других регистров! ОРС сервер производит анализ полученного ответа, например, если ОРС сервер запросил 2 регистра, а пришло 4, то такой запрос он отбросит. Если запрос пришел не от запрошенного устройства или с другой функцией, то этот запрос будет также отброшен. Но если запрос по структуре совпадает с предыдущим, сервер его примет и запишет значения в теги, которые будут некорректными. Избежать данной ситуации можно установив несколько настроек – включите реинициализацию узла при ошибке, а количество попыток установите равным 1. В этом случае, при первом же неудачном опросе сервер закроет порт, тем самым очистив буфер, а затем откроет его снова.

Предмет описываемой проблемы

При работе с базой данных в PostgreSQL необходимо не забывать, в какой локали (locale) был инициализирован кластер БД — так в постгре называется директория (обычно /var/lib/pgsql/data), в которой хранятся данные всех баз этой установки PostgreSQL.

Проблема

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

Первая попытка решить проблему

Гугло-поиск по полвине Интернета дал информацию о том, что неплохо было бы, если бы искомая база данных была в кодировке UTF-8 (в моем случае, по недосмотру, она была в дефолтной SQL_ASCII).

Ок. Сказано — сделано! Относительно быстро нашлась инструкция о том, как пересоздать базу данных в новой кодировке без потери данных.

[bash]
# su - postgres
~ vacuumdb --full --analyze --username postgres --dbname mydatabase
~ pg_dump mydatabase -Ft -v -U postgres -f /tmp/mydatabase.tar
~ dropdb mydatabase --username postgres
~ createdb --encoding UNICODE mydatabase --username postgres
~ pg_restore /tmp/mydatabase.tar | psql --dbname mydatabase --username postgres
~ vacuumdb --full --analyze --username postgres --dbname mydatabase

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

Решение проблемы становится интересным

Вместе с продолженным гугло-чтением пришло понимание того, что кластер баз данных этого PostgreSQL сервера был инициализирован в локали «C», а для функий lower() и upper() это значит очень многое!

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

«Окно» в 60 минут и полчаса на подготовку

До конца рабочего дня оставалось 1,5 часа и одно свободное «окошко» продолжительностью в 60 минут.

Начинать я решил с разминки на локальном ноуте. Здесь стоит упомянуть о разнице в операционных системах: ноут — Ubuntu 8.10, сервер — CentOS 5. Подготовив три окна терминала и ещё окно текстового редактора, приступил к подготовительным работам.

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

Дамп баз состоялся без сильных нареканий, только пару раз pg_drop ругнулся на подключенных пользователей к тем же базам (решилось закрытием pgAdmin’а).

Затем была найдена (в случае с Убунтой) спрятанная в достаточно необычном месте (/usr/lib/postgresql/8.3/bin) команда (initdb) и выполнена в нужными параметрами.

[bash]
# su - postgres
~ vacuumdb --full --analyze --username postgres --dbname mydatabase
~ pg_dump mydatabase -Ft -v -U postgres -f /tmp/mydatabase.tar
~ dropdb mydatabase --username postgres
~ initdb --locale=ru_RU.utf8 data/

Damn! Error…

Мда, оказалось, что нужно вручную удалить содержимое директории кластера баз данных.

Предупреждение! Не делайте сразу rm -rf data/*. Это я понял после того, как сделал это на ноуте, а после восстановления, у меня сбились права доступа пользователей к серверу (которые хранятся в pg_hba.conf).

Необходимо сделать копию файла pg_hba.conf куда-нибудь на время перемен.

[bash]
~ cp data/pg_hba.conf /home/cr0t/pg_hba.2009.03.24_1654.conf

После удаления содержимого директории и остановки демона PostgreSQL без ошибки прошла ре-инициализация кластера.

[bash]
~ exit
# /etc/init.d/postgresql stop
# su - postgres
~ rm -rf data/*
~ initdb --locale=ru_RU.utf8 data/

Оставалось только запустить заново сервер и восстановить из дампов старые базы в уже новый кластер, инициализированный в «правильной» локали.

[bash]
~ exit
# /etc/init.d/postgresql start
# su - postgres
~ createdb --encoding UNICODE mydatabase --username postgres
~ pg_restore /tmp/mydatabase.tar | psql --dbname mydatabase --username postgres
~ vacuumdb --full --analyze --username postgres --dbname mydatabase

Успех. Итоги

После этих успешных действий функция lower() стала правильно «прижимать» кириллические символы. Все рады. Но я даже не подумал о пользовательских ролях PostgreSQL (так в 8.х версии стали называться пользователи). Их не стало. Хорошо, что мне требовалось создать их всего парочку. Но у кого их много, будьте бдительны, не повторите моей ошибки!

P.S. Шаги для ре-инициализации, если есть несколько баз данных

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

[bash]
# su - postgres
~ vacuumdb --full --analyze --username postgres --dbname mydb1
~ pg_dump mydb1 -Ft -v -U postgres -f /tmp/mydb1.tar
~ dropdb mydb1 --username postgres
~ vacuumdb --full --analyze --username postgres --dbname mydb2
~ pg_dump mydb2 -Ft -v -U postgres -f /tmp/mydb2.tar
~ dropdb mydb2 --username postgres
~ vacuumdb --full --analyze --username postgres --dbname mydb3
~ pg_dump mydb3 -Ft -v -U postgres -f /tmp/mydb3.tar
~ dropdb mydb3 --username postgres
~ cp data/pg_hba.conf ./
~ exit
# /etc/init.d/postgresql stop
# su - postgres
~ rm -rf data/*
~ initdb --locale=ru_RU.utf8 data/
~ cp pg_hba.conf data/
~ exit
# /etc/init.d/postgresql start
# su - postgres
~ createdb --encoding UNICODE mydb1 --username postgres
~ pg_restore /tmp/mydb1.tar | psql --dbname mydb1 --username postgres
~ vacuumdb --full --analyze --username postgres --dbname mydb1
~ createdb --encoding UNICODE mydb2 --username postgres
~ pg_restore /tmp/mydb2.tar | psql --dbname mydb2 --username postgres
~ vacuumdb --full --analyze --username postgres --dbname mydb2
~ createdb --encoding UNICODE mydb3 --username postgres
~ pg_restore /tmp/mydb3.tar | psql --dbname mydb3 --username postgres
~ vacuumdb --full --analyze --username postgres --dbname mydb3

Кросс-пост с моего блога Summer code

Пост похож на уже опубликованный недавно Патчим UTF-8 Collation под FreeBSD, но мне кажется, что там описано решение проблемы специфичное для FreeBSD, я же привожу для Ubuntu’ы. Когда я решал свою проблему этой информацией даже не пользовался — только гугло-чтение.

Спасибо за карму!, перенёс в блог PostgreSQL.

Инициировать изменение портов, отличных от установленных по умолчанию, может только PI клиента. (команда PORT).

2.3.2. Процедура разрыва соединения.

Закрытие соединения, как правило, инициирует сервер.

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

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

2. сервер получил команду ABORT от клиента

3. спецификация порта изменена командой от клиента

4. управляющее соединение закрыто

5. произошла невосстановимая ошибка

В остальных случаях сервер инициирует закрытие соединения данных посылкой процессу клиента ответов 250 или 226.

2.3.3. Управление соединением данных

2.3.3.1.На стороне сервера номер порта соединения данных по умолчанию должен быть на 1 меньше номера порта управляющего соединения.

2.3.3.2. Процедура согласования портов данных, отличных от установленных по умолчанию (нестандартных)

PI клиента определяет нестандартный порт на стороне клиента командой PORT либо запрашивает о нестандартном порте на стороне сервера командой PASV. Эти команды могут использоваться вместе или по отдельности.

2.3.3.3. Переустановка соединения данных

При использовании режима передачи данных stream mode конец файла определяется закрытием соединения. Проблема передачи нескольких файлов может иметь два решения:

1. установка нестандартного порта.

2. использование другого режима передачи данных

2.3.4. Режимы передачи данных

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

Обязательно должны быть реализованы stream mode и block mode.

2.3.4.1. Stream mode (режим потока).

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

Если файл имеет структуру записей (структурирован по записям), символы EOR и EOF индицируются двухбайтовым кодом. Причем первым байтом должен быть escape-символ, а второй байт должен быть 1 (единица в менее значащем бите) для EOR и 2 (единица во втором бите) для EOF. Последовательность из escape-символа и символа 3 (два младших бита равны 1) означает одновременное присутствие EOR и EOF.

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

Данный тип передачи устанавливается по умолчанию.

2.3.4.2. Block mode — поблочный режим

Файл передается как серия блоков данных с заголовками.

Длина заголовка — 3 байта — 16 младших бит занимает поле counter, 8 старших бит — descriptor.

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

1. Поле счета (counter) — показывает общую длину блока в байтах (без учета заголовка), тем самым определяя начало следующего блока (блоки передаются один за другим без пауз и разрывов)

2. Поле описателя (дескриптора) (descriptor):

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

Данными маркера рестарта может быть набор печатных символов используемого алфавита (NVT-ASCII например), в который не должен входить пробел (Space).

2.3.4.3. Compressed mode — режим сжатия

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

2.3.4.3.1. Блок несжатых данных

2.3.4.3.2. Блок репликатора

Для сжатия строки из n репликаций (копий) байта данных d посылаются два байта:

2.3.4.3.3. Блок заполнителя

Строка из n байтов заполнителя может быть сжата в один байт. Байт заполнителя зависит от типа представления данных (для ASCII и EBCDIC — это (Space, 32 — ASCII, 64-EBCDIC), для типов Image и Local — 0).

Escape — последовательность — это сдвоенные байты, первый из которых — это escape-символ — 0, а второй содержит код дескриптора, определенный в Block Mode. Код дескриптора имеет то же значение, что и в Block Mode и применяется к строке байтов.

3. Требования к типам данных

При передаче информации по соединению данных могут использоваться следующие типы данных как: ASCII, EBCDIC, IMAGE и LOCAL, а также могут поддерживаться структуры данных: file, record, page. Обязательными для реализации являются типы данных ASCII и IMAGE, а также структуры данных file и record. Должен поддерживаться режим управления форматом Nonprint.

3.1. Типы данных

Тип данных определяет размер логических байтов и кодировку передаваемых байтов. Длина передаваемых байтов всегда составляет 8 бит. Размер логических байтов в типах ASCII, EBCDIC и IMAGE составляет 8 бит, а в типе LOCAL определяется параметром команды TYPE.

Могут поддерживаться следующие типы данных:

1. тип ASCII (NVT-ASCII). Этот тип должен использоваться по умолчанию.

2. тип EBCDIC.

3. тип IMAGE.

4. тип LOCAL.

3.2. Управление форматом

При использовании типов данных ASCII и EBCDIC для управления вертикальным форматированием при выдаче на печать (на экран) могут использоваться управляющие символы.

При использовании типов данных ASCII и EBCDIC могут быть реализованы следующие режимы форматирования:

3.2.1. Nonprint

3.2.2. Telnet CONTROLS

3.2.3. CARRIAGE CONTROLS ASA

По умолчанию устанавливается тип Nonprint.

3.3. Структуры данных.

Определены три типа структуры файлов.

3.3.1. Cтруктура file. Файл считается непрерывной последовательностью байтов данных. Устанавливается по умолчанию.

3.3.2. Структура record. Файл состоит из последовательных записей. Данная структура применима для типов данных ASCII и EBCDIC.

3.3.3. Структура page. Файл состоит из независимых индексированных страниц. Каждая страница должна иметь заголовок, состоящий из следующих полей:

— длина заголовка (в логических байтах) минимум 4.

— индекс страницы (идентификатор страницы в файле)

— длина данных (количество логических байт данных)

— тип страницы

0 — последняя, при этом длина заголовка должна быть 4, длина данных — 0

1 — простая (длина заголовка должна быть 4)

2 — страница описателя (служит для передачи информации о файле в целом)

3 — страница контроля доступа (включает дополнительное поле заголовка для информации управления доступом. Длина заголовка — 5.

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

4. Требования к восстановлению от ошибок и рестарту

В ТС FTP может быть реализована функция рестарта.

4.1. Процедура рестарта

Процедура рестарта предоставляется для защиты клиентов от грубых ошибок системы (включая ошибки узла, процесса FTP и сети передачи данных). Процедура определена только для режимов передачи Block mode и Compressed mode. Отправитель данных периодически вставляет в поток передаваемых данных маркер рестарта с данными маркера рестарта. Принимающий узел выделяет из потока данных маркеры рестарта и отправляет их клиенту. Для выдачи клиенту сообщения о рестарте на удаленном узле должен использоваться ответ 110. В случае системной ошибки клиент может начать заново передачу данных, идентифицируя контрольную точку с помощью процедуры рестарта. Для этого посылается команда рестарта с кодом маркера в качестве аргумента.

4.2. Формат маркера рестарта

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

5. Требования к структуре и составу сообщений сервера FTP и клиента FTP

5.1. Команды FTP

От клиента FTP к серверу FTP по управляющему соединению информация передается в форме команды клиента FTP.

5.1.1. Формат команд FTP

Команды FTP являются строками символов алфавита NVT-ASCII. Возможно использование другого языка. Аргументы отделяются символом . Конец определяется символом . Не должно делаться различия между прописными и строчными буквами как в команде, так и в аргументе.

5.1.2. Перечень команд FTP приведен в табл. 1.

Таблица 1

Перечень команд FTP

5.1.3. Синтаксис команд приведен в п.7.

Восстановление УРИБа, спасение периферии после обновления из центра

30.06.2019

Реинициализация

Прототип:

void rewind(FILE
*_stream);

Описание:

Помещает
указатель позиции файла на начало файла
и сбрасывает индикаторы ошибок и конца
файла. rewind(stream)
эквивалентно fseek(stream,
0L, SEEK_SET) (см.
далее),
за исключением того, что rewind()
обнуляет признаки конца файла и
ошибки, в то время как fseek()
обнуляет только признак конца файла.

Функции для ввода-вывода по символам

Чтение
символов из потока

Чтение
символов осуществляют функции
getc()
и fgetc()

Прототипы:

int getc(FILE
*_fp);

int fgetc(FILE
*_fp);

Описание:

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

Возвращаемое
значение:

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

Пример
1:

#include<stdio.h>

int
main(void)

{

char
ch;

printf(«Введите
символ :»);

/*
ввести символ из стандартного входного
потока stdin */

ch
= getc(stdin);

printf(«Был
введен символ ‘%c’n»,ch);

return
0;

}

Пример
2:

#include
<conio.h>

#include
<iostream>

using
namespace
std;

//
Обработка текстового файла, созданного

// обычным
текстовым редактором

int
main()

{

char
namein[15]; char
ch; FILE *fp;

system(«chcp
1251»);

printf(«Введите
путь и имя вводного файла,например,test1n»);

gets(namein);

if((fp=fopen(namein,
«r»))==NULL)

{

perror(»
Не могу открыть вводной файл… «);

//
perror(namein );

getch();exit(1);

}

do

{

/*
ввести символ из файла */

ch = fgetc(fp);

/*
вывести символ на экран */

printf(«%c»,ch);

}
while(ch!=EOF);

getch();fclose(fp);

return0;

}

Для
ввода символов со стандартного вводного
потока (с клавиатуры) используется
функцияgetchar().

Прототип:

int getchar(void);

Описание:

getchar()
— это макрокоманда, вводящая символ из
потока stdin.
Она определена следующим образом:
getc(stdin).

Возвращаемое
значение:

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

Пример:

#include<stdio.h>

int
main(void)

{

char
c;

/*
Замечание. getchar читает символы с stdin,
который имеет

буфер
на одну строку. Поэтому она ничего не
возвращает до

тех
пор, пока вы не нажмете Enter */

while((c=getchar())!=’n’)

printf(«%c»,c);

return
0;

}

Запись
символов
в поток

Запись
символов осуществляют функции
putc()
и
fputc().

Прототипы:

int putc(int
_c, FILE *_fp);

int fputc(int
_c, FILE *_fp);

Описание:

Обе
функции (функция putc()
представляет собой макрокоманду)
выводят символ _c
в указанный выходной поток _fp.

Возвращаемое
значение:

При
успешном завершении функции putc()
и
fputc()
возвращают символ _c.
При возникновении ошибки обе функции
возвращают значение EOF.

Пример:

#include
<stdio.h>

int
main(void)

{

char
msg[] = «Здравствуй
мир»;

int
i=0;

while(msg[i])

{

fputc(msg[i],stdout);

i++;

}

return
0;

}

Для
вывода символов в стандартный выводной
поток (дисплей) используется функция
putchar().

Прототип:

int putchar(int
_c);

Описание:

putchar()
– это макрокоманда, определенная как
putc(_c,
stdout);

Возвращаемое
значение:

При
успешном завершении putchar()
возвращает выведенный символ _c.
При ошибке она возвращает EOF.

Пример:

#include<stdio.h>

int
main(void)

{

char
msg[] = «Тестовый
пример»;

int
i=0;

while(msg[i])

{

putchar(msg[i]);

i++;

}

return
0;

}

Задача
163.Программа
создает программным путем текстовый
файл (посимвольно) на диске, затем
переносит из этого файла в другой файл
каждый третий (0, 3, 6, …) символ исходного
файла. Попутно результат обработки
выводится на экран.

#include
<conio.h>

#include
<stdio.h>

#include
<iostream>

using
namespace
std;

int
main()

{

//
программа печатает каждый 3-й символ
текстового файла, созданного

//
программным путем с возможным добавлением
текста (режим а+)

system(«chcp
1251»);//переключаем
консоль в кодировку win1251

char
nameout[15]; FILE *out, *in; char
ch;

//для
русских int ch не обязательно для норм
работы EOF !

cout<< «Введите
имя cоздаваемого файла,например,D:\eddy.txtn»;

gets(nameout);

if((out
= fopen(nameout, «a+»))==NULL)
//для
чтения
и
записи

{
cout<<«Не могу создать
файл …!»;//perror(nameout);

getch(); exit(1);

}

cout<< «Введите
последовательность символов, в конце
– Ctrl+Zn»;

while
((ch=getchar())!=EOF)

fputc (ch, out );

cout<< «nфайл
создан»;//getch();

// в
случае a+ файл можно не закрывать, а
сделать так:

rewind(out); //возврат
к началу файла

in=out; //просто
переустановим указатель

cout<< «nВведите
имя преобразованного файла «;
gets(nameout);

out=fopen(nameout,
«w»);

if(out==NULL)

{

cout<< «n
Не могу открыть выводной файл… «;

exit(2);

}

//
Обработка созданного файла, содержащего
фразы:

// Даже
Эдди нас опередил с детским хором

// So even
Eddy came oven ready

int
k=0;

//while((ch=getc(in))!=EOF)

while(!feof(in))

{ ch=fgetc(in);

if(ch==’n’)

{ putc(‘n’,out);putchar(‘n’);}

if(k++%3==0)

{ putc(ch, out);putchar(ch);}

}

fclose(in); fclose(out);

cout<<
«конец
работы»;

getch(); return0;

}

Для
проверки программы мы ввели следующий
текст:

Даже
Эдди нас опередил с детским хором

So
even Eddy came oven ready

И
вот результат:

Дед спел тихо

Send money

Функции
для ввода-вывода по строкам

Чтение
строки
из потока

Чтение
по
строкам осуществляет функция
fgets()

Прототип:

char
* fgets(char
*_s, int
_size, FILE *_fp);

Описание:

fgets()
считывает из потока _fp
строку символов и помещает ее в _s.
Ввод завершается после считывания
_size-1
символов или при вводе символа перехода
на следующую строку, смотря, что произойдет
раньше. fgets()
прекращает ввод строки при получении
символа перехода на следующую строку.
Нулевой байт добавляется в конец строки
для индикации ее конца. Символ конца
строки не отбрасывается и располагается
непосредственно перед нуль-символом.

Возвращаемое
значение:

При
успешном завершении возвращает указатель
на _s,
при ошибке или конце файла возвращает
указатель NULL.

Для
ввода строки со стандартного вводного
потока (с клавиатуры) используется
функция gets().

Прототип:

char
* gets(char
*_s);

Описание:

Функция
gets()
читает строку символов, оканчивающуюся
символом перевода строки , в
переменную *_s
из стандартного входного потока
stdin.
Данная символьная строка оканчивается
символом перехода на новую строку,
который при записи в *_s
заменяется на нулевое окончание ().

В
отличие от scanf(),
gets()
позволяет вводить строки, содержащие
символы пробела и табуляции. Все, что
было введено до перевода каретки,
помещается в _s.

Возвращаемое
значение:

При
успешном завершении, функция gets()
возвращает строку _s;
при достижении конца файла (EOF)
или ошибке возвращается NULL.

Пример:

#include
<stdio.h>

int
main(void)

{

char
string[133];

printf(«Введите
строку:»);

gets(string);

printf(«Cтрока
= ‘%s’n,string);

}

Запись
строки
в поток

Запись
в поток по строкам
осуществляет функция
fputs()

Прототип:

int fputs(char
*_s, FILE *_fp);

Описание:

Функция
fputs()
копирует строку
_s
, ограниченную нулевым байтом, в поток
_fp.
Она добавляет в конец строки символ
перехода на новую строку. Нулевой символ
в файл не переносится.

Возвращаемое
значение:

При
успешном завершении fputs()
возвращает последний выведенный символ.
В противном случае возвращает EOF.

Пример:

#include<stdio.h>

int
main(void)

{

/*
вывести строку в поток */

fputs(«Тестовый
пример»,stdout);

return
0;

}

Для
вывода строки в стандартный выводной
поток (на экран) используется функция
puts().

Прототип:

int puts(char
*_s);

Описание:

Функция
puts()
копирует строку символов с нулевым
окончанием в стандартный выходной
поток stdout,
причем добавляет в конец символ перехода
на новую строку.

Возвращаемое
значение:

При
успешном завершении, функция puts()
возвращает

ненулевое значение. В противном случае
возвращается EOF.

Пример:

#include<stdio.h>

int
main(void)

{

/*
вывести строку в поток */

puts(«Тестовый
пример»);

return
0;

}

Задача
164.Программа
создает программным путем (по строкам)
текстовый файл на диске. Ввод строк с
клавиатуры осуществляет функция fgets(),
вывод на диск построчно – функция
fputs().

//
fget_fput3_rus.cpp : 14.05.2012г

// Ввод
строк с клавиатуры(fgets) и создание
текстового файла(fputs)

//
Использование fgets и fputs для обычного в/ы
(stdin / stdout)

#include<conio.h>

#include<stdio.h>

#include
<stdlib.h>

#include
<iostream>

using
namespace
std;

const
int
size=120;

int
main()

{

char
line[size]; char
nameout[15]; FILE *out;

system(«chcp
1251»);//переключаем
консоль в кодировку win1251

//
ОБЯЗАТЕЛЬНО ПЕРЕКЛЮЧИТЬ ШРИФТЫ С
ТОЧЕЧНЫХ НА Lucida console

// после
запуска программы щелчком мыши в левом
верхнем углу

cout<< «Введите
имя создаваемого файла,например,D:omar.txtn»;

gets(nameout);

if((out=fopen(nameout,
«a+»))==NULL)

{

cout<< »
Не могу открыть выводной файл… «;

getch(); exit(1);

}

cout<< «Введите
несколько строк текста, потом Ctrl+Z n»;

while(fgets(line,size,stdin)
!=NULL && line[0] !=’n’)

{

fputs(line,out);

fputs(line,
stdout); //
puts(line);

}

cout<<
«Файл
создан»;

fclose(out);
getch(); return
0;

}

Задача
165.
В
программе решается следующая задача.
На основе файла, созданного предыдущей
программой (см.Задачу 164), строится новый
файл, в котором каждая строка:

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Планирование перехвата IP-адреса

Перехват IP-адреса (IP Address Takeover, IPAT) представляет собой механизм, используемый HACMP для перемещения сервисных адресов между коммуникационными
интерфейсами.

Существует два метода: перехват IP-адреса посредством замены (IPAT via replacement)
и перехват IP-адреса посредством синонимов (IPAT via aliases). Конфигурация
вашей сети зависит от применяемого метода управления интерфейсами.

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

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

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

Перехват IP-адреса посредством замены

Этот способ конфигурирования сетей HACMP является более традиционным. HACMP
при запуске осуществляет замену загрузочного адреса на сервисный адрес.

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

• базовый и сервисный адреса основного коммуникационного интерфейса должны
  относиться к одной подсети;
• базовые IP-адреса всех дополнительных коммуникационных интерфейсов должны относиться к различным подсетям (относительно друг друга и относительно
  основного интерфейса).

Преимущество перехвата IP-адреса посредством замены состоит в том, что оно разрешает выполнять перехват аппаратного адреса (Hardware Address Takeover, HWAT) вместе с перехватом IP-адреса посредством замены. Эта возможность позволяет осуществлять
перемещение (локально администрируемого) MAC-адреса адаптера, соответствующего
сервисному IP-адресу, вместе с IP-адресом на дежурный адаптер. Это устраняет необходимость обновления ARP-кеша на стороне клиента в случае переноса IP-адресов.

На рис. 3.9 показано состояние сетевых адаптеров до и после запуска HACMP на
узлах. Обратите внимание на то, что HACMP при запуске заменяет загрузочный/базовый адрес сервисным адресом. Перемещение при сбое выполняется на дополнительный (дежурный) адаптер(ы), где, опять же, базовый (дежурный) адрес заменяется
сервисным адресом. Количество сервисных адресов ограничено количеством резервных адаптеров, определенных в той же сети HACMP.

Перехват IP-адреса посредством синонимов

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

HACMP позволяет использовать перехват IP-адреса посредством IP-синонимов
для следующих типов сетей, поддерживающих gratuious ARP-запросы (в AIX):

• Ethernet;
• Token Ring;
• FDDI;
• SP Switch1 и SP Switch2.

Примечание. Перехват IP-адреса посредством IP-синонимов не поддерживается
в сетях ATM.

При запуске HACMP выполняется конфигурирование сервисного синонима поверх существующего базового IP-адреса доступного адаптера.

При использовании перехвата IP-адреса посредством синонимов следует учитывать следующие требования:

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

    Примечание. Это ограничение снимается при использовании мониторинга пульса
    через синонимы.

  • Сервисные адреса должны относиться к отдельной подсети относительно любой из базовых подсетей. Можно использовать несколько сервисных адресов,
    и все они могут относиться как к одной подсети, так и к различным подсетям.
  • Постоянный синоним может относиться либо к той же подсети, либо к другой
    подсети относительно сервисного адреса.
  • Все маски подсети должны быть одинаковыми.
• Несколько сервисных меток могут совместно существовать как синонимы для заданного интерфейса.
• Нельзя сконфигурировать перехват аппаратного адреса (Hardware Address Takeover,
  HWAT).

Мы рекомендуем использовать постоянный синоним и включить его в одну подсеть с маршрутом по умолчанию. Это обычно означает, что постоянный адрес должен быть включен в одну подсеть с сервисными адресами. Постоянный синоним
можно использовать для доступа к узлу при отключенном HACMP, а также для преодоления проблем с маршрутом по умолчанию.

Можно выполнить настройку параметров размещения сервисных IP-меток, сконфигурированных в HACMP V5.3. Можно настроить размещение синонимов через
меню SMIT с использованием следующих вариантов:

• Без совместного размещения (Anti-Collocation). Используется по умолчанию. HACMP распределяет сервисные IP-метки по всем доступным коммуникационным интерфейсам с использованием выбора по принципу наименьшей загруженности.
• С совместным размещением (Collocation). HACMP размещает все сервисные
  IP-метки на одном коммуникационном интерфейсе (NIC).
• Без совместного размещения и с постоянной меткой (Anti-Collocation
  with persistent label). HACMP размещает все сервисные IP-метки по всем активным коммуникационным интерфейсам, не содержащим постоянную IP-метку синонима. HACMP размещает сервисную IP-метку на интерфейсе, содержащем постоянную метку только в том случае, если другие сетевые интерфейсы недоступны.
  Если постоянные IP-метки не были сконфигурированы, HACMP позволяет выбрать
  метод размещения Anti-Collocation with Persistent (Без совместного размещения и
  с постоянной меткой), однако при этом выдается предупреждение и по умолчанию используется обычный метод без совместного размещения.

  

  Рис.
  3.10.
  Перехват IP-адреса посредством синонимов

• С совместным размещением и с постоянной меткой (Collocation with
  persistent label). Все сервисные IP-метки располагаются на одной сетевой карте,
  содержащей постоянную IP-метку. Этот вариант может быть полезен при конфигурациях виртуальной частной сети (VPN) с брандмауэром, где только один интерфейс имеет внешний выход и все IP-адреса (постоянные и сервисные) должны
  располагаться на одном коммуникационном интерфейсе. Если постоянные IP-метки не были сконфигурированы, HACMP позволяет выбрать метод размещения
  Collocation with Persistent (С совместным размещением и с постоянной меткой),
  однако при этом выдается предупреждение и по умолчанию используется обычный метод с совместным размещением.

На рис. 3.10 показано состояние сетевых адаптеров до и после запуска HACMP на
узлах. Обратите внимание на то, базовые адреса не изменяются. HACMP добавляет на
базовые адаптеры сервисные и постоянные синонимы. Постоянные адреса всегда
доступны, тогда как сервисные метки добавляются и удаляются при запуске и остановке HACMP. Перемещение при сбое выполняется путем переноса сервисной метки
на другой доступный коммуникационный интерфейс. В нашем примере только сеть
192.168.100/24 является маршрутизируемой вне кластера.

Мониторинг пульса через синонимы

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

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

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

Чтобы установить мониторинг пульса через IP-синонимы, следует настроить параметр «IP Address Offset for Heartbeating over IP Aliases» («Смещение IP-адреса для
мониторинга пульса через IP-синонимы») как часть конфигурирования сетей HACMP.
IP-адреса, используемые для мониторинга пульса, определяются и назначаются системой HACMP с применением этого значения смещения. Маска подсети совпадает с
той, которая используется для сервисных и несервисных адресов.

Например, можно в качестве параметра смещения IP-адреса употреблять значение
1.1.1.1. При использовании сети с двумя NIC на каждом узле следует добавить маску подсети 255.255.255.0; в результате получим следующие IP-синонимы мониторинга пульса:

• node01:
  • en0 1.1.1.1;
  • en1 1.1.2.1.
• node02:
  • en0 1.1.1.2;
  • en1 1.1.2.2.

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

На рис. 3.11 показано состояние сетевых адаптеров до и после запуска HACMP на
узлах. Обратите внимание на то, базовые адреса не изменяются. Помимо сервисных
и постоянных синонимов, добавляемых HACMP на базовые адаптеры, также добавляются синонимы пульса. Последние удаляются при остановке HACMP вместе с сервисными синонимами. В нашем примере только сеть 192.168.100/24 является маршрутизируемой вне кластера.

Команда netstat -i выводит три IP-адреса для каждого адаптера при запущенном HACMP.

Планирование сети, отличной от IP

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

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

Разделение кластера

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

Наилучшая защита от возникновения подобных ситуаций состоит в том, чтобы использовать несколько сетей, как TCP/IP-сетей, так и сетей типа «точка-точка»,
чтобы обеспечить правильность оценки серьезности проблемы. Помните о том, что
HACMP (в частности, RSCT) отправляет и получает пакеты пульса по всем доступным
сетям, поэтому чем больше сетей, тем точнее HACMP сможет определить, имеет ли
место отказ узла или отказ сети.

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

На рис. 3.12 показан кластер из четырех узлов с одним Ethernet-подключением к
каждому серверу. Так как используется только одна сеть, то при потере любой связи
часть кластера будет разделена. В примере показан разрыв связи между двумя Ethernetкоммутаторами, вызывающий отделение двух узлов слева от двух узлов справа. В
данном случае могут возникнуть проблемы в результате попыток выполнить перехват ресурсов с активного узла.

Рис. 3.13 несколько более реалистичен; на нем представлены двойные Ethernetподключения с каждого узла. Каждый Ethernet-адаптер подключен к отдельному коммутатору. В этом случае для разделения кластера необходимо, чтобы произошел отказ двух коммутаторов или же обоих Ethernet-подключений на узле. Однако сама по
себе сеть TCP/IP остается единой точкой отказа.

На рис. 3.14 представлена рекомендованная конфигурация. Имеются двойные
Ethernet-подключения к нескольким Ethernet-коммутаторам, а также добавлена кольцевая сеть типа «точка-точка». В кольцевой сети каждый узел подключен к своим
непосредственным соседям. При потере одного подключения RSCT все еще сможет
подключиться ко всем оставшимся узлам. Для разделения кластера потребуется возникновение двойного отказа на узле и отказа сети TCP/IP.

Для построения надежной конфигурации рассмотрим реализацию звездной топологии. При такой конфигурации, помимо сети TCP/IP, каждый узел подключен
ко всем другим узлам кластера сетями типа «точка-точка». Это позволяет обеспечить
связь RSCT с работающими узлами при отказе нескольких узлов. Эта конфигурация
представлена на рис. 3.15.